I’ve already provided you with an upload link
Sam
Ah, sorry, didn’t remember that (having issues due to medication…)
I’ve uploaded a zip containing 3 folders with extracted sections from 7 test files
Details to follow (i’ll edit this post)
The archive OSMC test extracted sections.zip contains:
Incorrect black levels - h265 8bit/
[on the vero 4k, these files show washed out colours and blacks as grey. On the Raspberry Pi 3 using OSMC they play correctly]
Brz 1080p YUV_4-2-0_Type 1-Type 0 8 bit_BT.709.mkv_
Gdz 1080p YUV_4-2-0_Type 1-Type 0 8 bit_BT.709.mkv_
Spr YUV_4-2-0_Type 1-Type 0 8 bit_BT.709.mkv_
StrTrk YUV_4-2-0_Type 1-Type 0 8 bit_BT.709.mkv_
Trn YUV_4-2-0_Type 1-Type 0 8 bit_BT.709.mkv_
Working on both - h265 8bit/
[This is another h265 8-bit file, however it plays with correct colours and black levels on the Vero 4k]
Jws YUV_4-2-0_8 bit_BT.709.mkv
Working - h265 10bit/
[This is an h265 10bit file, which plays correctly on the Vero 4k]
Eots 1080p YUV_4-2-0_10 bit.mkv
MediaInfo
Regarding one of the h265 8bit files which are not displaying correctly, here is the relevant MediaInfo output for the original full movie, and the section I extracted (to show that the format / file integrity remains unchanged - it has not been transcoded, as file as I can tell)
ORIGINAL
Complete name : Brz 1080p YUV_4-2-0_Type 1-Type 0_ 8 bit_BT.709.mkv [ORGINAL FULL MOVIE]
Format : Matroska
Format version : Version 4 / Version 2
File size : 2.50 GiB
Duration : 2 h 23 min
Overall bit rate : 2 498 kb/s
Movie name :
Encoded date : UTC 2017-08-09 01:59:19
Writing application : mkvmerge v14.0.0 (‘Flow’) 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 23 min
Bit rate : 2 369 kb/s
Width : 1 920 pixels
Height : 1 040 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 1 / Type 0)
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.049
Stream size : 2.37 GiB (95%)
Default : Yes
Forced : No
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
EXTRACTED SECTION USING MKVTOOLNIX
Complete name : Brz 1080p YUV_4-2-0_Type 1-Type 0_ 8 bit_BT.709.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.58 MiB
Duration : 10 s 28 ms
Overall bit rate : 1 323 kb/s
Movie name :
Encoded date : UTC 2018-05-14 19:59:18
Writing application : mkvmerge v21.0.0 (‘Tardigrades Will Inherit The Earth’) 64-bit
Writing library : libebml v1.3.5 + libmatroska v1.4.8
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 10 s 10 ms
Bit rate : 1 189 kb/s
Width : 1 920 pixels
Height : 1 040 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 1 / Type 0)
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.025
Stream size : 1.42 MiB (90%)
Default : Yes
Forced : No
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Thanks for this. I won’t be able to reply for a few days but will give you an update then.
1 Like
Thanks, it’s very much appreciated.
I’ll hold off performing a reset of the Vero 4k for the time being, but will test some different HDMI cables. I’ll leave updates here if I find anything of interest.
With the test patterns, you should clearly be able to see a difference on the Vero 4K. With the Limited range (“normal”) test pattern, you will not see any flashing bars below 17 if the display is calibrated to video standards.
If you are seeing lower bars, adjust the brightness of your display to only see bars 17 and above flash. 17 should be barely visible. You can ignore the white flashing bars. On most displays, you may be able to see all the way up to 248 and even higher.
Now, play the Full range clip, you will notice that you can see all the black bars flashing. This is because of incorrect YCbCr <–> RGB conversions. What is happening here is, the range is being constricted. 2 now becomes 18, 3 - 19 … 253- 233. In other words, the grayscale is being elevated. This is why you see black as gray with a full range video.
1 Like
Hi wesk05,
Thanks for the reply; I’ll take another look at the test patterns as played on the vero 4k and try to describe what I’m seeing more clearly.
Hopefully I’ll get back to you later today (I’m in the UK, but usually awake until at least 3am…)
Hi
Thanks for your patience. I’ve now had a chance to test this locally and look in to this. I need a little more time to see what’s going on here.
Sorry for the delays 
Sam
1 Like
Hi Sam,
Have you had a chance to investigate the issue with 8-bit hevc videos encoded with full range enabled?
[Edit: my apologies, I’m in the UK and didn’t realise it is Memorial weekend in the US. I hope that you and your colleagues have a great holiday.]
Many thanks in advance
UK here too (Bank Holiday)
I had a chance to investigate now. There doesn’t seem to be an issue in the decode pathway; but output needs adjusting.
Force RGB still makes sense as the output of choice for me. Can others try and see if this improves things? You need to reboot after applying the setting.
It was remarked:
I performed one test with the Acer monitor set to force RGB, which caused the UI to output in garish orange and green.
Can this be tried on another display?
Sam
1 Like
RGB output mode is limited range. So, I don’t think it will help.
As it is now, YCbCr output for normal limited range videos does passthrough super black/white (0-15, 236-255). The full range videos can be treated the same way. Full range YCbCr is not really defined in BT.709 standard. Full range YCbCr applies to xvYCC and other YCC color spaces.
1 Like
Hi,
Thanks for the reply wesk05 (apologies for confusing this thread by accidentally using two different accounts - not sure exactly what happened there, but dk.ecom and retroresolution are one and the same).
I’m finding over 90% of all the h265 8-bit files I have (and there are many) exhibit the colourspace problem, yet all of these files play perfectly on a Raspberry Pi 3 running OSMC. I’m really hoping there’s going to be some way to fix this, even if the Vero 4K has to decode the files in software (as the Pi does).
Many thanks
Hi Sam,
Apologies, I didn’t read this reply before posting my previous response to wesko5.
I’ll try setting RGB to forced with the Vero 4K connected to the 1080p generic brand (Sainsbury’s badged ‘e-motion’) tv (model details are earlier in the thread), and report back.
Many thanks
Hi
I’ve performed some further tests, and have some confusing results.
I rerouted the necessary wiring to connect the Vero 4K to the aforementioned 1080p tv via HDMI, booted the system, and confirmed that the colourspace issue was still present with default settings (e.g. Settings | System | Display | Force RGB Output OFF), testing a dozen or so of the problematic h265 8-bit files
I then changed Force RGB Output to ON (screenshot attached for confirmation), rebooted the system, and found that the garish green/orange display wasn’t present - the OS looked normal.
I re-tested the same dozen h265 8-bit files, but found the problem with the colourspace remained.
I took a screengrab using the standard method (kodi-send --action=TakeScreenshot), but found upon viewing the results on the PC a perfectly black screen (when viewed via the Vero 4K the area containing the image is grey, with the letterboxed area a normal black).
I powered off the system, rerouted the cabling to the Acer 1080p monitor (specifications in earlier post), using the same HDMI cable, leaving the Force RGB Output to ON.
I was surprised to see that the OS display looked normal (e.g. the strange orange/green mess previously reported was gone). I rebooted three times, checking that RGB was ON, but it still works okay. (WIth over two decade’s professional experience as sys admin and developer, there’s little more frustrating when trying to resolve a problem than inconsistent test results…)
I then tested a random selection of affected h265 8-bit files, but again found the colourspace issue to be present - areas that should be black are displaying as grey, and colours in general are washed out.
Hopefully these tests will help shed some light on the issue.
I’m more than happy to try out any other tests you’d like me to perform.
Regards,
Hi,
Thanks for testing with Force RGB output enabled and still confirming that this doesn’t resolve the issue you’ve had.
This is indeed what I would expect. It means that the issue isn’t with decoding but rather with the output format.
Handling based on CEA vs DMT is probably correct.
@retroresolution On Pi: when playing back content that looks OK, can you let me know the output of: tvservice -s
I think you can send full range YCbCr with a display supporting quantisation but this is not widely found. Broadcasted content and content on disc is 16-235, but I’d like to see what can be done here.
Sam
1 Like
Hi Sam,
Thanks for the response and investigative efforts.
I’ve only recently woken (my health isn’t exactly stellar at present), but will perform some tests on the Pi in a little while.
As I think I mentioned in previous posts, none of the h265 tv shows I’ve tested have any problems, but (at a guess) 90% of the 8-bit h265 movies, aquired from a very wide range of sources, have a problem.
I’m wondering why so many files are encoded in an unsupported (e.g. not within the hevc specification) format. It’s likely, however, that I may have misunderstood what wesk05 and yourself are saying about the format.
Re-encoding the affected files in handbrake would take more time than I probably have left, and likely burn out a PC or three…!
Many thanks
Hi Sam,
As requested, I’ve performed tests playing various files on the Pi, recording the output of:
tvservice -s
I first tested various H265 8-bit files, which work correctly on the Pi, but have colourspace problems on the Vero 4K. The output is always:
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
I then issued the tvservice -s command when playing a multitude of other files in various formats (avi, wmv, x264, h265 8-bit, h265 10-bit), and also when playback was stopped. Regardless of whether a file is playing or not, the output is always:
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
This is true also when booted to Raspbian without Kodi running.
Raspberry Pi System Configuration
Tests were performed on a Raspberry Pi 3 running Raspbian Stretch, with Kodi 17.6 Krypton installed alongside.
The hardware is overclocked to 1300mhz, installed in an all-aluminium case to avoid the thermal governor underclocking the system.
The HDMI output mode is pre-set in the config, simply to avoid issues if the Pi is booted without the display connected or powered on.
Relevant excerpts from /boot/config.txt are as follows:
arm_freq=1300
core_freq=500
over_voltage=4
gpu_mem_1024=256
gpu_mem=256
start_x=1
hdmi_force_hotplug=1
hdmi_group=1
hdmi_mode=16
disable_overscan=1Thanks for your message. I hope you are feeling a bit better.
This has my interest. It’s what I expected. Pi is outputting a standard limited RGB mode. Vero can also do this, so I think we just have a bug here. In theory, Force RGB should be giving you the same output, which is peculiar.
You don’t seem to have Adjust Refresh Rate enabled on Pi, or we should see playback at 23.976Hz, not 60Hz. Can you confirm this? If so: can you see if disabling Adjust Refresh Rate on the Vero 4K makes any effect? On an old LG TV (LH3200), I remember it having different colour settings depending on the refresh rate, which was quite frustrating.
Tomorrow, I’ll play your sample again with Force RGB and analyse the AV InfoFrames on HDMI to see what we’re getting out, as we may have a bug here.
Sam
Of course, you can do that, but as I mentioned in the other post HDMI/CTA standards define YCbCr full range for the YCC color spaces and not necessarily for BT.709/601.
As for the Pi, I checked it on my Pi2 with Raspbian and Kodi 17.6. While there is no elevation of the grayscale as seen in Vero 4K, the output is clipped to 16-235. In other words, the output of full range source content is still incorrect. I also checked RGB Full, YCbCr Limited and Full output modes. RGB Full scales and remaps the grayscale (16–> 0, 235 -->255). 0-15/236-255 from the source content is ignored. There was no difference between YCbCr Limited/Full.
This works correctly only on x86 Linux (tested with Millhouse LibreELEC 18.0 #529 build on Intel Haswell system) when system driver and Kodi are set to Full.
1 Like
Right – I would expect gamut restriction on Pi too. The question is why is it not visible on Pi but is on Vero 4K.
I’d like some clarification about refresh rate from @retroresolution when he gets an opportunity.
I have an idea for what this may be now. If I’m right, it’s fixed in the next round of video output improvements.
1 Like
Hi Sam,
Thanks for continuing to investigate this.
I can confirm that on the Pi, ‘Settings | Player | Videos > Adjust display refresh rate’ is set to OFF.
On the Vero 4K, ‘Adjust display refresh rate’ was already set to OFF (which is the default setting for the menu), however I tested setting this to ALWAYS, and playing back all of the affected test files which I previously uploaded to you (see earlier in the thread).
On the Acer 1080p monitor, connected via HDMI, there’s no difference in the image - the colourspace is still incorrect. As playback commences the monitor can be seen to switch modes, as the backlight powers off briefly, as it does during a resolution change when connected to the PC. Interestingly when checking the display stats via the monitor’s on-screen menu, it still reports 1080p @ 60hz.
I tested the Vero 4K with ‘Adjust display refresh rate’ to ALWAYS when hooked up via HDMI to the 1080p ‘e-motion’ TV. Again, there’s no improvement regarding the colourspace issue, and again the on-screen-display always reports 1080p @ 60hz
For the record, on the Vero 4K ‘Sync playback to display’ is not enabled (I’ve not previously touched this setting). I tried setting this to enabled, with the ‘Adjust display refresh rate’ set to both ‘Off’ and ‘Always’ - neither combination made a difference. I only performed these latter tests with the Vero 4K connected to the TV.
Thanks
