[flyingernst]

Error is gone...but now (as it did sometimes before) hd audio bitstream stutters sometimes, especially DTS:x... Also with a brand new live Libreelec. I think that is an error of the lspcon, I have fw 1.66. DVI works fine. Picture of hdmi fine too, but audio starts popping... I think it has no relation to the screen error.

Perhaps I will just use the 4205 for a server and get a j5005 or 4105 for Kodi....starts getting on my nervs.

But thank you so much for your personal help! So at the end the aspect error on HDMI was a configuration error, wherever it was from.

[fritsch]

You are welcome.

[blackride]

I'm not the only one with this problem.

Pretty sure you are - I'm not aware of any "freezes" in the GUI being reported in the LE9/x86_64 testing thread (which would be the right place to report them).

Please provide corroborating links if there are any. 

Hi, dear Milhouse.

I can not provide the log, because it does not display the micro twitching of the interface. But I can record video on the camera.

[blackride]

I'm not the only one with this problem.

Pretty sure you are - I'm not aware of any "freezes" in the GUI being reported in the LE9/x86_64 testing thread (which would be the right place to report them).

Please provide corroborating links if there are any.    

I do not have a video camera with 60 frames per second. I shot the video in full hd 30 frames a second. Without a camera i can see more strong twitching. You will see how the list is scrolled with a slight twitch and a stronger jerking in the interface when switching from the radio section to the addons and back.

The first video without a xorg.conf - twitching.
https://www.youtube.com/watch?v=xzDPHQ4CWdI

The second video from the xorg.conf - not twitch. But I will not say that it is perfect. But much better.
https://www.youtube.com/watch?v=32cfzCzcqZQ

UPD. Now i added new video.

My friend has a motherboard asrock j4105-itx (gemini lake). He has the same problems. And also in windows 10 and kde neon - everything works smoothly.

[fritsch]

Try this xorg.conf

Code:

Section "Device"
  Identifier "Device0"
  Driver "intel"
  VendorName "INTEL Corporation"
  Option "DRI" "3"
  Option "TearFree" "true"
  Option "TripleBuffer" "true"
EndSection

And tell me what it improves. (For others reading this, that config is not good, but does what e.g. kwin and every other compisitor does). In kodi set renderbuffers to 3

[noggin]

Thought I'd try a Milhouse nightly build on my UP Squared N3350 Celeron board (until recently serving pfSense firewall/VPN duties).  

I'm running it via a Displayport 1.2->HDMI 2.0 3D Club converter which handles proper 2160p50 and p59.94 output.  

Watching the BBC iPlayer 36Mbs 2160p50 HEVC Wimbledon stream which is wide colour gamut Rec 2020 with HLG EOTF it's interesting to see what happens with my Apollo Lake.

I'm getting 2160p50 RGB 8 bit output (594MHz) - with what looks like a Rec 2020 to Rec 709 conversion.  It doesn't seem to be Rec 2020 incorrectly output as Rec 709 (as some platforms deliver) - it does look as if Kodi or the Intel drivers are doing some gamut conversion.  No idea how accurate it is - but if I force Rec 2020 colour gamut, it looks very, very wrong.  The SDR backwards compatibility of HLG HDR seems to be pretty effective too.

I'm getting very occasional dropped frames - and initially it takes a while to work - but I'm pretty impressed that a low-end Apollo Lake can do this at all.

(It's a passively cooled Celeron with a chunky heatsink the size of the board area. But goodness does it get hot...)

Also interesting that the 2160p50/59.94p output is 8-bit, but 1080p, 720p and 576p is 12 bit.

[blackride]

Try this xorg.conf


And tell me what it improves. (For others reading this, that config is not good, but does what e.g. kwin and every other compisitor does). In kodi set renderbuffers to 3  

I tried it.

But in my opinion, this bundle works better:
1.

Code:

Section "Device"
  Identifier "Device0"
  Driver "intel"
  VendorName "INTEL Corporation"
  Option "DRI" "3"
  Option "TearFree" "true"
  Option "DoubleBuffer" "true"
EndSection

2.
In kodi set renderbuffers to 2.

Now everything seems to be fine.

But, this does not work in LE 8.2.5. In LE 9 from Milhouse - ok

Thank you fritsch

[fritsch]

Thought I'd try a Milhouse nightly build on my UP Squared N3350 Celeron board (until recently serving pfSense firewall/VPN duties).  

I'm running it via a Displayport 1.2->HDMI 2.0 3D Club converter which handles proper 2160p50 and p59.94 output.  

Watching the BBC iPlayer 36Mbs 2160p50 HEVC Wimbledon stream which is wide colour gamut Rec 2020 with HLG EOTF it's interesting to see what happens with my Apollo Lake.

I'm getting 2160p50 RGB 8 bit output (594MHz) - with what looks like a Rec 2020 to Rec 709 conversion.  It doesn't seem to be Rec 2020 incorrectly output as Rec 709 (as some platforms deliver) - it does look as if Kodi or the Intel drivers are doing some gamut conversion.  No idea how accurate it is - but if I force Rec 2020 colour gamut, it looks very, very wrong.  The SDR backwards compatibility of HLG HDR seems to be pretty effective too.

I'm getting very occasional dropped frames - and initially it takes a while to work - but I'm pretty impressed that a low-end Apollo Lake can do this at all.

(It's a passively cooled Celeron with a chunky heatsink the size of the board area. But goodness does it get hot...)

Also interesting that the 2160p50/59.94p output is 8-bit, but 1080p, 720p and 576p is 12 bit.

Wenn render to 8 bit visuals srgb. Whatever you change behind that will make everything worse.

[noggin]

Thought I'd try a Milhouse nightly build on my UP Squared N3350 Celeron board (until recently serving pfSense firewall/VPN duties).  

I'm running it via a Displayport 1.2->HDMI 2.0 3D Club converter which handles proper 2160p50 and p59.94 output.  

Watching the BBC iPlayer 36Mbs 2160p50 HEVC Wimbledon stream which is wide colour gamut Rec 2020 with HLG EOTF it's interesting to see what happens with my Apollo Lake.

I'm getting 2160p50 RGB 8 bit output (594MHz) - with what looks like a Rec 2020 to Rec 709 conversion.  It doesn't seem to be Rec 2020 incorrectly output as Rec 709 (as some platforms deliver) - it does look as if Kodi or the Intel drivers are doing some gamut conversion.  No idea how accurate it is - but if I force Rec 2020 colour gamut, it looks very, very wrong.  The SDR backwards compatibility of HLG HDR seems to be pretty effective too.

I'm getting very occasional dropped frames - and initially it takes a while to work - but I'm pretty impressed that a low-end Apollo Lake can do this at all.

(It's a passively cooled Celeron with a chunky heatsink the size of the board area. But goodness does it get hot...)

Also interesting that the 2160p50/59.94p output is 8-bit, but 1080p, 720p and 576p is 12 bit.

Wenn render to 8 bit visuals srgb. Whatever you change behind that will make everything worse.   

But what colour gamut RGB? Rec 2020 or Rec 709 primaries?  

When fed YCbCr Rec 2020 does the content get converted to RGB (Rec 2020 primaries) following the Rec 2020 YCbCr->RGB matrix?  And is there an assumption that RGB output will be Rec2020?  Or do the drivers get Rec 2020 flagged and do a tone map to Rec 709 RGB primaries?

[wesk05]

When fed YCbCr Rec 2020 does the content get converted to RGB (Rec 2020 primaries) following the Rec 2020 YCbCr->RGB matrix?  And is there an assumption that RGB output will be Rec2020?  Or do the drivers get Rec 2020 flagged and do a tone map to Rec 709 RGB primaries? 

For HDR to SDR, it does Reinhard tonemapping (probably the same code as in FFmpeg). Reinhard is not really a filmic tone mapping operator. It is more suitable for static images than video, at least that is what I consider it to be. I haven't seen anything in the code that is doing Rec.2020 to sRGB mapping. May be I am not looking at the right place.  Intel graphics drivers on Windows can set the colorimetry to Rec.2020 for RGB, not sure whether that's the case with Linux drivers.

[fritsch]

It was easy to implement it and to create an infrastructure. It was meant to set a basis so that you freaks :-) with the good knowledge can jump in and implement better suited operators :-). Btw. check the code again - you should see the handling of BT2020 and how we produce sRGB.

[fritsch]

Try this xorg.conf


And tell me what it improves. (For others reading this, that config is not good, but does what e.g. kwin and every other compisitor does). In kodi set renderbuffers to 3  

I tried it.

But in my opinion, this bundle works better:
1.

Code:

Section "Device"
  Identifier "Device0"
  Driver "intel"
  VendorName "INTEL Corporation"
  Option "DRI" "3"
  Option "TearFree" "true"
  Option "DoubleBuffer" "true"
EndSection

2.
In kodi set renderbuffers to 2.

Now everything seems to be fine.

But, this does not work in LE 8.2.5. In LE 9 from Milhouse - ok

Thank you fritsch  

 8.2.5 is way too old for that generation. Basically with most new intels - latest and greatest is just good enough.

[noggin]

When fed YCbCr Rec 2020 does the content get converted to RGB (Rec 2020 primaries) following the Rec 2020 YCbCr->RGB matrix?  And is there an assumption that RGB output will be Rec2020?  Or do the drivers get Rec 2020 flagged and do a tone map to Rec 709 RGB primaries? 

For HDR to SDR, it does Reinhard tonemapping (probably the same code as in FFmpeg). Reinhard is not really a filmic tone mapping operator. It is more suitable for static images than video, at least that is what I consider it to be. I haven't seen anything in the code that is doing Rec.2020 to sRGB mapping. May be I am not looking at the right place.  Intel graphics drivers on Windows can set the colorimetry to Rec.2020 for RGB, not sure whether that's the case with Linux drivers. 

 Right - so sRGB = Rec 709 primaries RGB.  So a Rec 2020 YCbCr source (ignoring HDR vs SDR) is converted to sRGB Rec 709 primaries ?  My Apollo Lake DP 1.2->HDMI 2.0 path is not flagging Rec 2020 primaries and if I force Rec 2020 primaries it's 'wrong'. So It appears some Rec 2020 to Rec 709 conversion is taking place somewhere.

[fritsch]

When fed YCbCr Rec 2020 does the content get converted to RGB (Rec 2020 primaries) following the Rec 2020 YCbCr->RGB matrix?  And is there an assumption that RGB output will be Rec2020?  Or do the drivers get Rec 2020 flagged and do a tone map to Rec 709 RGB primaries? 

For HDR to SDR, it does Reinhard tonemapping (probably the same code as in FFmpeg). Reinhard is not really a filmic tone mapping operator. It is more suitable for static images than video, at least that is what I consider it to be. I haven't seen anything in the code that is doing Rec.2020 to sRGB mapping. May be I am not looking at the right place.  Intel graphics drivers on Windows can set the colorimetry to Rec.2020 for RGB, not sure whether that's the case with Linux drivers.  

 Right - so sRGB = Rec 709 primaries RGB.  So a Rec 2020 YCbCr source (ignoring HDR vs SDR) is converted to sRGB Rec 709 primaries ?  My Apollo Lake DP 1.2->HDMI 2.0 path is not flagging Rec 2020 primaries and if I force Rec 2020 primaries it's 'wrong'. So It appears some Rec 2020 to Rec 709 conversion is taking place somewhere. 

 We do this.

[wesk05]

We do this. 

Is it to sRGB or SMPTE240M (Adobe RGB)?
https://github.com/xbmc/xbmc/blob/c3884a...x.cpp#L586