I don’t think this is a HDMI TX problem. It is probably in the very first YUV to RGB conversion.
Wait a min… did you change the code to force full range YCbCr? If so, I will have to check on another analzyer. The one that I used yesterday gets confused with full range YCbCr. Even without the analyzer, I could see that even the desktop GUI was “washed out” with this patch.
Hi Sam,
Apologies for the huge delay in responding.
Before I update the kernel, can you provide the requisite commands to reverse the process in case of problems, ideally to my system’s current kernel, which uname -a reports as:
Linux Osmc_Vero_4K 3.14.29-98-osmc #1 SMP Thu Jun 7 11:27:17 UTC 2018 aarch64 GNU/Linux
Many thanks,
RR
Hi RR,
sudo dpkg-reconfigure vero364-image-3.14.29-98-osmc
if required will rollback to the current kernel.
Thanks Tom.
I rechecked. InfoFrame shows YCbCr Full range quantization, but it doesn’t fix anything. The results are exactly the same as first reported.
Levels are correct with limited range flagged content that has super black/white (Test patterns).
Levels are still incorrect with full range flagged content. 0 is 15, 1 is 16, 2 is 18…
I think this shows that it is not the qunatization flag in HDMI TX that is causing the issue.
@retroresolution: how many video clips do you have with this full range issue?
If you wan’t this problem fixed immediately, all you have to do is edit the VUI. Change the full range flag to limited and the video will play with correct black levels on Vero 4K.
I am not sure whether there is any free software that can edit the VUI without reencoding. There used to be some custom FFmpeg builds that could do this for H.264 files. Not sure whether there is one for H.265. There are paid programs that can edit VUI/SEI without reencoding. I use: https://hdr.avtop.com/hdr_software_ff_pictures
My memory tells me that @retroresolution only had problems with 8-bit HEVC.
@wesk05, see:
#if 0
if (v & 0x2000) {
hevc_print(hevc, 0,
"video_signal_type present:\n");
hevc_print(hevc, 0, " %s %s\n",
video_format_names[(v >> 10) & 7],
((v >> 9) & 1) ?
"full_range" : "limited");
if (v & 0x100) {
hevc_print(hevc, 0,
" color_description present:\n");
hevc_print(hevc, 0,
" color_primarie = %s\n",
color_primaries_names
[v & 0xff]);
hevc_print(hevc, 0,
" transfer_characteristic = %s\n",
transfer_characteristics_names
[(c >> 8) & 0xff]);
hevc_print(hevc, 0,
" matrix_coefficient = %s\n",
matrix_coeffs_names[c & 0xff]);
}
}
#endif
Won’t print as AML prefer #ifdef 0 instead of code removal.
So you’re saying we can just change the reported range here to resolve the issue?
There’s already a module param, module_param(video_signal_type, uint, 0664) which is overriden by hevc->video_signal_type = (v << 16) | c;.
During playback, you should be able to override this sysfs parameter and see if it improves things.
See [1] for reference. Might benefit to test on vanilla kernel.
[1] vero3-linux/vh265.c at master · osmc/vero3-linux · GitHub
Yes, if we change the reported range, it will fix the issue. Test patterns with full range signal but flagged as limited play with correct black levels.
I don’t see anything here: https://collab.osmc.tv/s/A5q4UPN128FJZxI
That was the upload link. There’s only one file uploaded there. See https://collab.osmc.tv/s/Gi5tWB3eUUtD6Mu.
Okay. I have some ideas.
Try
echo 0 > /sys/module/amvdec_h265/parameters/video_signal_type when it looks wrong.
And what is the value of /sys/module/amvdec_h265/parameters/video_signal_type when it looks wrong?
Sam
root@osmc:/home/osmc# echo 0 > /sys/module/amvdec_h265/parameters/video_signal_type
root@osmc:/home/osmc# cat /sys/module/amvdec_h265/parameters/video_signal_type
0
Didn’t make any difference.
@retroresolution: I downloaded your clips with incorrect black levels and changed the range to limited. Try them and see whether it makes a difference
Sam: I also uploaded this to that previous link.
Hi @wesk05 ,
In terms of clips (e.g. demonstration snippets extracted from problematic files using handbrake), there were half a dozen or so.
In terms of actual full movies, it could be well over 50. Perhaps many more.
I’ve made custom builds of ffmpeg myself in the past (I introduced native audio/video recording to Retropie’s retroarch-core emulators two years before the official version included this, and documented it all on www.retroresolution.com), however I’m not sure I could manage such a project in my current degraded state!
I’ll take a look at the link, and thank you for this. I’d wondered if every keyframe was flagged, or just the header, but not knowing enough, didn’t know which flag would need changing regardless.
Hi @sam_nazarko,
Your memory serves you well. This issue only manifests on 8-bit hevc files flagged as full range colourspace (and I’ve only ever had issues on films, never on tv shows).
I’ve had no problems at all with 10-bit hevc.
Out of interest, are you coding natively in C, to the metal, or using a framework / dev-kit?
My C is rusty (was a professional C# / javascript coder in most recent work).
Thanks,
RR
Many thanks.
This explains where your name comes from 
Kodi is C++
Kernel is C.
I’m going to compare the clips tomorrow and hope to see the difference in pathway shortly. I would appreciate if you could let us know if @wesk05’s changes to the files help.
Thanks for the information.
I’ve downloaded the modified files. I’m in the process of transferring them over to the Vero at the moment (via tablet, as it’s too late to boot the noisy PC, so things are raking a bit of time due to awkward tools)
If the issue is indeed just a case of flags, we can fix it trivially.
It’s a shame you’ve been a guineau pig and this has dragged on for so long though!
Sam
Hi @sam_nazarko, @wesk05,
Very happy to report that the flag-modified files look fine compared to the original snippets (just completed an A/B comparison on all of them).