interesting result, hdr to dv conversion in tv-led mode is done in the most correct way, the original HDR stream is given to TV, only RPU data is added, hence we have the most accurate and correctly converted DV. as in the process of processing will be used the ability of TV itself, if it has support for CM4.0, then it will be better compression.
Unlike all other players, where the player entirely does the conversion of hdr to dv itself.
But in LLDV mode conversion is already on the player and a little wrong, ie the top of the brightness range is compressed correctly, but DV of the original video with a large range of brightness raises the brightness of dark details, and conversion from HDR, only compresses the top of the range, For Oled TV it is not terrible, but for LED TV especially with a weak system FALD, it will lead to incorrect processing.
Therefore, the option of converting HDR to DV can definitely be recognized as the best of all players
So HDR is played according to TVâs capabilites with this? This HDR conversion alone makes this feature worthy of addition to mainline builds.
Yes. very good option for not bright tv
v7 is great, really happy with it and am using it as my daily driver now 
I am noticing an occasional crash when starting VS10 content (black screen for a few seconds with the Dolby Vision logo on the TV, then the device reboots). I no longer have access to v6 to verify, but Iâm pretty sure it didnât happen on that version. I can trigger the crash with these steps:
- switch on VS10 (Dolby Vision) for SDR/HDR10
- reboot the box
- play a DV P7 MKV (for a few seconds, then stop it)
- play an SDR/HDR10 MKV
It will crash when trying to engage VS10 for the SDR/HDR10 MKV, probably about 30% of the time. If it doesnât crash, I can usually trigger it by switching between the P7 file and the SDR/HDR10 a few more times.
Thanks so much for your work on this awesome feature!
Very cool. If convenient for you, could you please post a waveform and screencap of the original HDR?
From eyeballing, the results are close to the native DV in color, but slightly reduced brightness. Impressive processing.
Makes me want to rewatch Planet Earth III with VS10 turned on.
Has anyone actually tried to use the existing dovi.ko anyway using the force option of modprobe? Would this actually have a chance of working?
I can add back in my original tv-led version min and max luminance override parameters to force the LLDV/Graphics Mode DV conversion to that range if not getting from the VSI e.g TV is not DV capable.
Let me know if you think it will be useful for testing.
It can be done but kinda pointless unless other work is done to not switch in and out of DV playing content as would constantly be reset.
It needs a deeper think and buy in from the CE team.
I recall some conversation elsewhere on this may have been @YadaYada - the version gap is a major release jump so possibility seems super slim at best, maybe can get away with it, if it was a minor revision bump.
I did see the source from Amazon has a dovi.a and corresponding .h file, if that helps any (presuming not) but not been down that rabbit hole.
Only sensible way out of this is AMLogic make available dovi.ko for each arch/release of their open source linux. Need to understand the impediment of that and see if can work on that angle.
Itâs been a couple of months, so I donât remember all the details. I tried loading SC2/T7 dovi.koâs (kernel 5.4) on CE-NG I donât think it was able to even load, I know there was no DV playback. I also tried the s922x/s905x2/sm1 dovi.koâs on CE-NE on a s905x4 box and again donât remember any of those being able to load either. The only thing that even worked a little was using the s905x2 dovi.ko on the s905x4 running CE-NG (after editing the dovi.ko SOC check). I donât remember if DV worked properly, but I know DV FEL didnât because thatâs what I wanted to check specifically.
I donât remember if I tried any of the dovi.koâs on 5.15. If I did it would have only been CE-NO on the s905x4, and there wouldnât have been any positive results, Iâd have remembered that. It wouldnât be a bad idea to double check but Iâm not hopeful.
I doubt Amlogic will help, that would be very out of character for them.
The best chance for getting a 5.15 compiled g12b dovi.ko is to ask one of the companies that are financially benefiting from CE, and maybe they can either do it themselves or influence Amlogic to. Perhaps Ugoos if you convince them the AM6+ would sell even better if itâs EOL wasnât CE-NG. Ugoos is the only one selling a g12b SOC that plausibly benefits from a 5.15 dovi.ko for this device.
If I have a brainwave on what may cause this, then will attempt a fix but realistically I will pass the torch on to others to try altering the code themselves and test if can get a more stable combination, spent probably a solid 8 hours trial and error getting to this point, and no clear path to make it more stable without deep knowledge on actual HW cores probably only an AMLogic dev has that depth.
Thatâs right. HDR to DV does not differ in colors from the dv version, the only difference is lower average brightness, but the brightness peaks are compressed correctly. But in tv-led output mode the result will be better because cm4.0 will be used for conversion.
The difference in color with the original HDR is due to the fact that for DV used EDID CX, so the image is more red.
I tested the upscaling options and it turned out that amlogic already uses the best of the lanzos options. I could not get a better image variant. Still a bit lacking in microcontrast to get the same image as Fire tv stick 4k or shield tv. I even tested on black and white image to remove the influence of color channels and their algorithms, but I didnât get a better result.
But maybe it is necessary to try a combination of different algorithms, for vertical and horizontal, I will try to check.
Letâs try it.
No worries at all, thanks for your reply!
Did you check if the CMv4.0 generated by Resolve is better than the one generated by VS10 on-the-fly?
Was this for image upscaling (i.e. 1080 to 4K) or for chroma upsampling?
Actually vs10 only does rolloff tonemapping, it doesnât touch the bottom of the range. It only compresses what is above the capability of the TV itself. Although you should try how it works on edid where minpq is above 0.05. whether it will lift the bottom of the range.
Davinci resolve is supposed to do better. But I havenât compared it directly.
v8b.
- Rebase on latest CE 21.1.
- Bypass checks for DV capable display when showing CE Settings.
- Add parameters (for testing only)
/sys/module/amdolby_vision/parameters/dolby_vision_force_hdmi_lum/sys/module/amdolby_vision/parameters/dolby_vision_hdmi_lum_min/sys/module/amdolby_vision/parameters/dolby_vision_hdmi_lum_max
To test:
- Enable âUse Player Ledâ i.e. LLDV
- Enable âUse display luminanceâ (this is required because of the code - though counter-intuitive)
- Reboot.
echo 1 > /sys/module/amdolby_vision/parameters/dolby_vision_force_hdmi_lum'- Then change the min and max luminance you want,
- The min value unit is (nits/10000), the max is (nits) e.g.:
echo 1 > /sys/module/amdolby_vision/parameters/dolby_vision_hdmi_lum_minecho 700 > /sys/module/amdolby_vision/parameters/dolby_vision_hdmi_lum_max
You can confirm in the logging that the values are in effect by:
echo 1 > /sys/module/amdolby_vision/parameters/debug_dolby
and follow the journal logging with:
journalctl -kf
You will see entires like:
CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:1-700), g 1: 1920x1080 1->7000000, vpr, flag=7, md=216, frame:1463
(T:1-700) is the video input min and max (min in nits/10000, max in nits)
1->7000000 is the graphics input min and max (min in nits/10000, max in nits/10000) Not sure why they chose to log differently for graphics, all values feed down to the dovi.ko in nits/10000 (i.e. most precision).
Should also be able to also do this for Graphics Mode tv-led (aka fake tv-led), needs another command, but try this out first.
What is the difference between fake tv led and player led?