yep, that must be the reason but positive lift starts raising black level only after 0.025 (2100 in 12bits) and any value between 2048 and 2100 are ignored in all my tests. Dolby also clearly states to not lift for than 0.025.
Can’t say I tested it in that fine detail to comment what happens in this range. In any case, the L2 data is being sent to the TV exactly as it is from the file - so it should only be dependant on the TV.
I do wonder if this is a recommendation that come out later to accommodate that consumer hdmi devices where not sending L5 data - rather than this being due to the way DV was designed.
Yes, that recommendation is for hdmi devices and they ignore L5 by design. From Dolby docu:
Blockquote “Avoid using positive values over 0.025 on the LIFT trim control for letterboxed content. (Negative Lift values are acceptable on all versions). The
current implementation on Ultra HD Blu-ray devices apply the Trims to the entire image area, including the letterbox blanking area, to allow subtitles to
appear over them. If the scene contains positive Lift values over 0.025, this may cause the letterboxed area to have elevated black levels during playback.
An alternate way to achieve the desired result is to use a combination of GAIN and GAMMA trims more aggressively as these controls are
manipulating the tone curve to achieve a more lifted black effect without using Lift. You can also choose to go back and modify your original HDR
content to lift the blacks slightly and then re-analyze and trim without the need to have a positive value on the Lift trim over 0.025. If the active image
area matches the canvas aspect ratio, (i.e. there is no letterbox), positive Lift can be used.”
“Dolby Vision, by design, has metadata (L0/L5) that describes the active image area and the portion of the image that has a letterbox (or blanking).
Dolby Vision mapping algorithms (and subsequently playback devices) are designed to apply mapping only in the active image area.
This works well for many devices but on HDMI-based devices like set-top boxes and Blu-ray players, this metadata is ignored as the
letterbox or blanking areas of the image are used to present subtitles and other graphics to the end user. Due to this implementation
on these devices, any positive lift applied to Dolby Vision content during the “trim pass,” will raise the black levels in the
letterbox/blanking areas of the image and can become distracting to the end user. Dolby recommends a maximum positive lift
value of 0.025 while doing the trims on letterboxed content during the Dolby Vision content creation process”
2 Likes
That seems to be the difference to what I’ve done. L5 is always sent, but adjusted as below to show the giu
with this unfortunate limitation
1 Like
I just tried your latest build. It triggers DV and I hear the audio but I get a black screen on every file and VRR info says 12bit RGB. Ugoos + C2
Your knowledge never ceases to impress. It seems that rather than being a bug, this is a deliberate filter implemented by Dolby which makes me feel much better. The device is working as intended. Whether or not that filter is necessary is a different story.
Based on the work of doppingkoala, it seems that dovi.ko reads the L2 trims and either rejects anything above 2048 or sets them to 2048. It would be interesting to have a test file with something like a L2 of 1000 - 2048 - 2050 to see what happens to the L2 trim. Is it rejected or reduced? If it’s rejected, it might be more correct to implement a pre-filter that would read the L2 trim and set it to 2048 if it’s greater than 2048.
1 Like
yeah, L5 being ignored is by design and it is not really an issue as long as they don’t lift more than 0.025 but even when they go slightly above that threshold, it’s unnoticeable unless you look very close in a pitch black room. Most movies respect that limitation when they are graded and if you plot L2/L8, my script will tell you the % of positive lift over 0.025. The test files I did use values from 1024 to 3079 and any value over 2048 is ignored unless you use LLDV or your TV internal player. But why would Dolby recommend no more than 0.025 if in the end, ANY positive lift is ignored by HDMI device and only in TV-LED? this seems like a bug to me and this is why this @doppingkoala project is VERY interesting.
so value between 0-2048 = ok
value between 2048-4095 = ignored
Also, when Dolby does the L8 to L2 conversion, even if the colorist did not do any adjustments, it automatically adds a positive lift under 0.025 in the generated L2 600nits trim.
In case you missed it.
Not aware of anyone trying with a DV licenced device before. Probably also need to disable Dolby Vision support in the menu and/or delete the dovi.ko. And then reboot.
I haven’t removed any of the existing DV code, so they are probably interfering with each other.
@R3S3T_9999 Would you have use of being able to send DV metadata over ssh and have it passed exactly as it to the display for testing?
Instead of guessing, or trying to infer it based on the response of the display, a capture would be able to tell exactly what metadata is passed to the display.
Given that positive L2 trims are valid DV metadata, are clearly used by the internal players of TV’s, are used in LLDV mode, and, from my tests, that TV’s also read and apply positive L2 trims over tv-led hdmi - I don’t think prefiltering would be ‘more correct’.
It really does seem like a work-around to account for no L5 trims being sent. Which itself just seems like laziness - it is the simplest way to ensure the a players gui / subtitles show in tv-led mode.
@doppingkoala Oh sorry for misunderstanding your build purpose. I’m here because I received a notification when you mentioned my username so I didn’t read the thread and just thought your build was another custom build for the ugoos like @cpm does.
Hopefully what you did to allow L5 and positive offsets could be implemented in the nightly or cpm builds ?
I suppose that depends where the DV metadata is passed to the hardware. If it is outside of the dovi.ko that should be possible. But someone else would need to look into that, I don’t have a device with a DV licenced SoC to test with.
1 Like
No, it is about make tv-led DV work for all devices, even if they don’t have a DV licence.
Currently, it is working correctly for any content that is playable as profile 8.1 (i.e., no reshaping and no EL layer). Should still work on your ugoos though, but it would only be useful for a test given the limitations.
1 Like
What a fantastic thread here!
Kudos to @doppingkoala, plus everyone who is contributing through testing and other means.
My context: Raspberry Pi 5 user, looking to get Dolby Vision files running on it with a connected Dolby Vision TV.
A couple of questions related to that.
- Can I try doppingkoala’s latest build on a Raspberry Pi? Would be happy to test and post results. Did not succeed in finding any internet article on being able to run CoreELEC on a Raspberry Pi.
- Are you also collaborating/joining force with the FFmpeg team, as I hear they are planning to support Dolby Vision? (source: https://www.phoronix.com/news/FFmpeg-Dolby-Vision-Progress)
Cheers
CoreELEC is ARM only
Raspberry is not supported
Thanks for the input.
Raspberry Pi 5 is based on Arm Cortex-A76 CPU. Did you mean CoreELEC is more focused on AMLogic devices?
Don’t know anything about that.
As I’ve said before though, I can’t see any reason now why full tv-led DV support for all profiles, including FEL, cannot be done on a PC. This work shows how to add the metadata to the video signal, while the reshaping and FEL layers are already supported by other software.
@doppingkoala , what about full Player-led DV support for all profiles, including FEL, done on a PC? Could this be done so folks that do not have a DV display but have a HDR display to also benefit from this approach?
I’ve got Ugoos and could try test it, didn’t know DV metadata can be send over SSH
How FEL can be play on a PC?