Use the same method, but doesn’t actually use the dovi_tool code. Far simpler to just write one small c function rather than to modify that tool to have the right interface. Also avoided need to make the tool available in the kernel.
1 Like
Thanks.
For the RPU have a couple of questions if you have a sec:
- Did you create a fixed L5 or ok to just skip it entirely?
- Did you create an L6 from the mastering display info and content light levels?
I use 22.04 on UTM [4.5.3 - 99] (Apple Silicon) never had an issue.
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
1 Like
I actually always send a L5 - at a minimum I need it to hide the tops rows so the metadata doesn’t show.
But I do add a L5 block with crops to match non 16:9 content for all videos (including hdr10+ converted ones), i.e., for a video that is 3840 x 1600, I add a top and bottom crop of 280. Thought was to match what should be there if it was a 3840 x 2160 video, as the TV won’t know otherwise. The idea with this was to avoid issues with positive lift values brightening the letterbox areas.
For your purpose, adding a L5 block won’t actually help at all for tv-led DV - it is not sent to the display even if it is present. I’d still suggest adding it though, should avoid any issues with positive lift for the LLDV mode at least.
No, the L6 isn’t sent to the display at all in tv-led mode.
Based on the advantage of sending a L5 block though, I might test sending a few L6 blocks with extreme values to see if anything happens. But it seems unlikely - different to the L5 situation I haven’t seen any reports of the internal players of tv’s responding to L6 data and @quietvoid said L6 is pointless.
1 Like
That said, you still need to work out the max_display_mastering_luminance and min_display_mastering_luminance that would go into a L6. They are used to set the source_min_pq and source_max_pq. See dovi_tool/dolby_vision/src/rpu/extension_metadata/blocks/level6.rs at 8ef53f252d56148c3cad9f8cc4ca76d40a9dfb20 · quietvoid/dovi_tool · GitHub
I’ve actually implemented a few more values in that function, taken from the DoVi_Scripts implementation.
1 Like
are cpm’s latest updates (t4a) already inluded on the latest nightly and 21.1 final version or do I have to install it after I installed 21.1?
no they are not and atm there’s not timeline for integration of cpm’s changes
ok thanks. Can I use them with the 21.1 final?
I just put CoreELEC-Amlogic-ng.arm-21.1-Omega_devel_20240810032011.T4A in the update folder via windows share and rebooted the box. The file is no longer in the update folder but im not sure it installed. How can I tell?
Goto - Settings → System → CoreELEC
If you can see this screen with the choices below then it was installed.
Assuming you have a DV TV, these settings are also the best choices if you want to play DV with FEL and every other format in its original format. If you want to convert any other format to DV then change the setting from “off” to “Dolby Vision” with the exception of “HLG HDR” (given an AMLogic bug) and of course “Dolby Vision”. This will convert those formats to DV using the VS10 Engine.
@cpm
Here is how I’ve done it common_drivers/drivers/media/video_sink/dv_injection.c at eb85e7bde788a2b06c4ba808b1c4046f56a00de7 · doppingkoala/common_drivers · GitHub
Only used that oversized lookup table because I couldn’t work out how to get access to the needed maths functions. Shouldn’t be an issue in the kodi side.
2 Likes
I got it install. Will there be an updated version from T4a that includes the final 21.1 Stable code?
@cpm Hi, great work. Just wanted to ask if the code on your github repo is up to date if I wanted to build the T4 image myself. The reason being curl v8.6 in the build (and nightlies also) has a bug and FTPs does not work for me. It is fixed in curl v8.9.1.
It would be great if a generic build would be compiled with latest 21.1 stable and CPM’s code
I kinda made such a build for myself, but I had to use the xbmc package from the cpm’s repo directly. The last commits before cpm’s changes seem the same as in main, but dated as ‘weeks ago’, instead of ‘4 days ago’ (probably main branch was rebased and patches reapplied or smth). Didn’t have time to do it properly, maybe sometime later…
I dont know if some parts of CPM code is redundant with the new 21.1 stable release but it sure would be great to have it merged
The *-delta repo branches will build ok if you have the packages/dependencies downloaded.
These delta contain effective CE branches with my changes applied at the time of doing a build shared with others, i.e. will currently be what was used to build T4A, with an underpinning of the CE branches at the time.
The xbmc repo base is frequently changing (force update) in CE leading to large compare diff with the current head:
I find the best way (for me) is to cut a new branch from the CE head and then cherry-pick my changes and merge again into that new branch, which will later on overwrite the existing delta.
The linux-amlogic repo base I have not seen changing, so easier to get a new branch up:
Note: I cherry-picked in the 3D changes into my branch as wanted to check the specifics and merge that way, so maybe will be a little bit confusing seeing those in the compare.
The media_modules-aml repo base I have not seen changing, so again easier, the changes in my branch are currently stand-alone so an easier one to try if want to start simple and get a build working by just updating this branch (work around “fix” for HDR10 ATEME Titan HEVC):
Below is the process I generally follow is get the latest CE coreelec-21 head built with changes:
Make sure your xbmc, linux-amlogic and media_modules-aml repo align to the versions referenced in the coreelec-21 head, and apply the changes on top.
Then create git diffs from your branches of xbmc, linux-amlogic and media_modules-aml and the ones listed in coreelec-21, putting the patch files into coreelec-21 in the correct places, and do a build!
Note: Likely many better approaches to the above but that is what I have worked out and comfortable with, it is a side project for me, so what works works :).
2 Likes
My HDR movies bright and dark areas seem to be tweaked brighter/darker. My settings are all off for converting to DV so I’m wondering what could be causing it (or is this the norm)? DV movies though look perfect.
@cpm, would it be possible for you to create a patch file for the ATEME fix? Or is that code combined too deeply with your enhancements?
I mentioned on the other thread - Try setting HDR10 to “Dolby Vision” instead of “off” to see if you get better results.