Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
RPi 4 and LibreELEC 9.1.002 ALPHA Video levels issue
#1
Hi, I've made a similar thread on LibreELEC forums (https://forum.libreelec.tv/thread/20187-...els-issue/) but it hasn't got any traction, so I'm hoping to get some answers here.

The issue is simple: in order to setup the video levels in the most ideal way (according to this: https://kodi.wiki/view/Video_levels_and_color_space), the GPU needs to be set to FULL, the TV must be set to LIMITED and Kodi must be set to LIMITED. When it comes to setting up the RPI 4 GPU (hdmi_pixel_encoding = 2 option in the config.txt file) and the TV correctly - there are no issues. The problem is that while Kodi (on LibreELEC 9.1.002) does allow you to set RGB levels to LIMITED via the "use limited color range (16-235)" option, it only has an effect on the Kodi GUI, not on the video playback itself which remains the in FULL mode regardless of the setting. I know this behavior is wrong because on my different system (Windows based HTPC with Radeon RX550 video card) this option does affect the video itself and thus I'm able to set up everything correctly to avoid scaling and clipping.

So the question is - how do I override the video player setting on LibreELEC 9.1.002 ALPHA to force it to output RGB limited as required?
Reply
#2
(2019-08-22, 12:25)krobolbus Wrote: Hi, I've made a similar thread on LibreELEC forums (https://forum.libreelec.tv/thread/20187-...els-issue/) but it hasn't got any traction, so I'm hoping to get some answers here.

The issue is simple: in order to setup the video levels in the most ideal way (according to this: https://kodi.wiki/view/Video_levels_and_color_space), the GPU needs to be set to FULL, the TV must be set to LIMITED and Kodi must be set to LIMITED. When it comes to setting up the RPI 4 GPU (hdmi_pixel_encoding = 2 option in the config.txt file) and the TV correctly - there are no issues. The problem is that while Kodi (on LibreELEC 9.1.002) does allow you to set RGB levels to LIMITED via the "use limited color range (16-235)" option, it only has an effect on the Kodi GUI, not on the video playback itself which remains the in FULL mode regardless of the setting. I know this behavior is wrong because on my different system (Windows based HTPC with Radeon RX550 video card) this option does affect the video itself and thus I'm able to set up everything correctly to avoid scaling and clipping.

So the question is - how do I override the video player setting on LibreELEC 9.1.002 ALPHA to force it to output RGB limited as required?

I believe the advice you are following is really only valid for PCs with GPUs (because PC GPUs were traditionally optimised for 0-255 Full range output and content and 16-235 video levels were historically added as an afterthought and not handled correctly - with clipped BTB and WTW in Limited output mode. The advice you were following was a workaround to stop this. For a while there was an Intel GPU option that also worked around this). ARM SoCs which handle the video decoding and display rendering differently can, I believe, pass through BTB and WTW levels correctly without these tweaks.

I'll have a look with a decent BTB and WTW test file when I get a chance to see if <16 and >235 content is clipped.
Reply
#3
Thanks!
I personally use the 2-APL Clipping.mp4 video file from https://drive.google.com/file/d/0B9FgjTt...VnTG8/edit to check if the levels are correct and unclipped, it originates from this thread on AVS: https://www.avsforum.com/forum/139-displ...ation.html .
Reply
#4
I'm pretty sure it "just works" and you shouldn't manually change anything.

We respect the flags in the video saying whether the video encoding is full/limIted and the colourspace and compose video/gui to RGB in either limited or full range RGB.
We signal to display the whether it is full range or limited range output (full for DMT modes, limited for CEA modes).

We have on occasion captured test cards with a hdmi capture card in different modes and the levels have been correct.

The only situation I've found where it isn't is where the TV doesn't respect the limit/full range flags signalled in AV infoframe.
That's not something we can know about, but the hdmi_pixel_encoding setting allows you to force the limited/full range flag your tv is expecting.
Reply
#5
(2019-08-23, 15:27)popcornmix Wrote: I'm pretty sure it "just works" and you shouldn't manually change anything.

We respect the flags in the video saying whether the video encoding is full/limIted and the colourspace and compose video/gui to RGB in either limited or full range RGB.
We signal to display the whether it is full range or limited range output (full for DMT modes, limited for CEA modes).

We have on occasion captured test cards with a hdmi capture card in different modes and the levels have been correct.

The only situation I've found where it isn't is where the TV doesn't respect the limit/full range flags signalled in AV infoframe.
That's not something we can know about, but the hdmi_pixel_encoding setting allows you to force the limited/full range flag your tv is expecting.
Yep, it does work well on default settings and everything looks right with regards to black levels and with no visible banding, but the WTW and BTB are clipped (unless I'm misunderstanding something), so I just wonder whether this can be prevented.
Reply
#6
(2019-08-23, 18:40)krobolbus Wrote: Yep, it does work well on default settings and everything looks right with regards to black levels and with no visible banding, but the WTW and BTB are clipped (unless I'm misunderstanding something), so I just wonder whether this can be prevented. 

If the issue you are describing is to do with values 0-15 and 236-255 with a limited range file then those values are illegal (although can be encoded) and behaviour is undefined.

Note: BTB and WTW don't make sense. It's like the volume control that goes up to 11.
If the TV could really display a blacker black and a whiter white than the maximum legal values, wouldn't it?
Reply
#7
(2019-08-23, 19:12)popcornmix Wrote:
(2019-08-23, 18:40)krobolbus Wrote: Yep, it does work well on default settings and everything looks right with regards to black levels and with no visible banding, but the WTW and BTB are clipped (unless I'm misunderstanding something), so I just wonder whether this can be prevented. 

If the issue you are describing is to do with values 0-15 and 236-255 with a limited range file then those values are illegal (although can be encoded) and behaviour is undefined.

Note: BTB and WTW don't make sense. It's like the volume control that goes up to 11.
If the TV could really display a blacker black and a whiter white than the maximum legal values, wouldn't it? 
As explained in that wiki I mentioned in the first post, there is a usage for BTB and WTW when calibrating your TV.
Reply
#8
(2019-08-23, 19:12)popcornmix Wrote:
(2019-08-23, 18:40)krobolbus Wrote: Yep, it does work well on default settings and everything looks right with regards to black levels and with no visible banding, but the WTW and BTB are clipped (unless I'm misunderstanding something), so I just wonder whether this can be prevented. 

If the issue you are describing is to do with values 0-15 and 236-255 with a limited range file then those values are illegal (although can be encoded) and behaviour is undefined.      

Sorry @popcornmix that's not the case.

In broadcast video terms the <16 and >235 can be present, and if they exist they shouldn't be clipped, as they are there to allow for a number of cases. One of the main ones is transients - particularly in imperfect legacy analogue content, where high-frequency transitions can undershoot or overshoot. If you clip these <16 undershoot and >235 overshoot transients you can introduce ringing when processing the video downstream. Most broadcast specs also allow for >100% luminance levels too. They are there for a very good reason, and if present, they should be preserved.

Bottom line - illegal levels aren't always illegal... (And in broadcast specs terms not all levels <16 and >235 are deemed out-of-gamut in the first place - 5-246 is the range that is within gamut)
Quote:Note: BTB and WTW don't make sense. It's like the volume control that goes up to 11. 

They make very good sense in certain situations, which is why the specs include support for them. There are good reasons that broadcast video isn't based around 0-255 (or 1-254) level space.

The UK Broadcast technical standards delivery specs (aka DPP) state this :
 
Quote:1.2. Signal Parameters
In a video signal, each primary component should lie between 0 and 100% of the video range between black level and the peak level (R, G and B). Ideally, video levels should lie within the specified limits so that programmes can be distributed without adjustment.
When television signals are manipulated in YUV form, it is possible to produce "illegal" combinations that, when de-matrixed, would produce R, G or B signals outside the range 0% to 100%.
1.2.1.Video Level Tolerance
In practice, it is difficult to avoid generating signals slightly out of range, and it is considered reasonable to allow a small tolerance:
• the RGB components and the corresponding Luminance (Y) signal, should not normally exceed the “Preferred Minimum/Maximum” range of digital sample levels in the table below,
• measuring equipment should indicate an “Out-of-Gamut” occurrence only after the error exceeds 1% of an integrated area of the active image.
For further details see the EBU Recommendation, EBU R103.
Any signals outside the “Preferred Minimum/Maximum” range are described as having a gamut error (or as being out of gamut). Signals cannot exceed the “Total Video Signal Range” and will therefore be clipped.

8-bit video - Expected range = 16-235, preferred Min/Max range = 5-246, Total video signal range = 1-254
10-but video - Expected range = 64-940, preferred Min/Max range = 20-984, Total video signal range = 4-1019

Full range video levels must not be used for delivered television programmes.

Colour gamut "legalisers" should be used with caution as they may create artefacts in the picture that are more disturbing than the gamut errors they are attempting to correct. It is advisable not to “legalise” video signals before all signal processing has been carried out.

Even 'out of gamut' warnings allow 1% out-of-gamut content to pass through (transients particularly) without alarming usually (as per spec above)
 
Quote:If the TV could really display a blacker black and a whiter white than the maximum legal values, wouldn't it?

Yes - but video signals aren't just there to feed tellies - they pass through a number of points in the processing chain before then. If <16 and >235 levels are clipped in the chain - you can introduce artefacts. The display can clip <16 and >235 levels (or it can display them if required to cope with slightly out of spec signals) but a device upstream of the display shouldn't.

One very significant use of <16 and >235 levels is the standard PLUGE picture line-up signal used to calibrate displays, where sub-black is used to ensure black level is correctly adjusted on a display. If you clip <16 you destroy one of the useful bits of the PLUGE signal.

The <16 and >235 issue is a bit like the 702 vs 720 line width issue.  Many think 720x576 is a 4:3 or 16:9 picture format, but actually (in 50Hz land) the central 702x576 area is 4:3 or 16:9. The 9 samples either side are 'wider' than 4:3 or 16:9. Just as with <16 and >235 the 9 samples each side should be preserved through the SD chain, but on a 16:9 or 4:3 display only the central 702x576 image should fill the frame (and you should not see the 9 samples either side), and if downconverting 1920x1080 or 1280x720 16:9 to SD the 1920x1080 or 1280x720 image should be scaled to 702x576 not 720x576.

https://tech.ebu.ch/docs/r/r103.pdf is very similar to the UK DPP spec in this regard, and UK DPP is based on it.
Reply

Logout Mark Read Team Forum Stats Members Help
RPi 4 and LibreELEC 9.1.002 ALPHA Video levels issue0