Dolby Vision now possible through MP4 Mux.

[SamuriHL]

I just now got around to applying it to mine. I'll get to playing around with it this week but this is very exciting stuff!

[RESET_9999]

indeed!

[Donpoku]

Hi re:clipping fix on cpm build, what is it meant to look like after it's fixed?
I want to test it on my lg-c6 but something tells me it probably won't make a difference on this tv.https://github.com/cpm-code/xbmc/discussions/47
Thanks.

Yes, it will make a difference because this build allows Level 5 and positive lift to work with TV-LED.
As for the clipping fix, try this file and see if there's a difference. It most likely has a big difference, the old CE builds (and oppo/x700/x800m2) are altering the RPU, they limit the metatada to the RPU source_pq(MDL)

https://drive.google.com/file/d/1Oparjy ... sp=sharing

Can you do screen comparisons of before & after fix. I've tested it on ce-nightlies & new test build by cpm build(with this autostart.sh-echo Y > /sys/module/amdolby_vision/parameters/dolby_vision_keep_source_meta_level_5)

but don't see any difference.

[RESET_9999]

L5 alone won't make any visual difference but it allows L2/L8 positive lift to work. You can find many movies that use it in this list...
https://drive.google.com/drive/u/1/fold ... KFJwFxnDt-

Anyway, I already did a couple of positive lift test files and real scenes here: https://drive.google.com/drive/u/1/fold ... r5CiYJ9KKj

[nekno]

When your timeline starts at 1hr @ 24 fps in Resolve (the default), it will output a DV XML where the first shot starts at frame 86400 (60s * 60m * 24fps).

At least, I assume that the frame number of the shot is what's indicated by the <In> value:

Code: Select all

<Shot>
  <UniqueID>9a4c3aa0-9f65-44fa-b8cb-5929e40ba466</UniqueID>
  <Record>
    <In>86400</In>
    <Duration>1166</Duration>
  </Record>
  ...

I see one reference to dovi_tool fixing that issue for HDR10+ in release 2.1.0 but I don't see any reference to a fix for DV.

Is this a problem in generating DV metadata with Resolve, or not a problem?

[RESET_9999]

no its not a problem for DV.

I changed it to start at 0 on mine.

[nekno]

no its not a problem for DV.

Thanks. Yeah, I made a little patch for dovi_tool to verify. The patch corrects the frame indexes, and my patched version generated the same output RPU as dovi_tool 2.1.3, so there must be some normalization of the indexes in a spot of code I didn't check.

Edit: Or maybe, as it appears, there is no frame index in the RPU output. Each frame just has its data, so the index doesn't matter. The data is sequential by nature. So, not clear on why it mattered for HDR10+ -> DV generation.

[deadchip12]

Actually, that clipping behavior with content brighter than the RPU MDL just got patched in cpm's coreelec build so if you use one of the CE devices, you can now do my initial suggestion of using 1000nits MDL if 10% or less is over 1000nits. Either way, 1000nits is the correct selection for that Seinfeld episode plot but I've seen other episode's plots that spiked to 10 000nits..

If your player is the x800m2/x700 or oppo, then you should respect the mediainfo MDL if there's a shot over the RPU MDL. These 3 players (probably all the bluray players) are altering the RPU that is being sent to the TV. They limit the L1 metadata to the RPU MDL causing the clipping when the content is brighter. In other words, the rpu response differences we noticed years ago between devices are finally explained.

The new CE update removed that limitation so now it sends original metadata to the display and processes the metadata identically to the TV internal player(or the shield and appleTV).

If the content is graded within the MDL, then all of this is pretty much meaningless but there's one even better thing that this update brought. It has enabled the Level 5 metadata and the positive offset lift that never worked on any HDMI device so far. Positive Lift metadata are frequently used in most movies. So this update brought an already great device to perfection levels.

I'm using the Ugoos AM6B+ with the latest nightly build 21.2-Omega. Does this update mean anything? How do I get it?

[quietvoid]

So, not clear on why it mattered for HDR10+ -> DV generation.

HDR10+ does have scene length, start indices. See https://github.com/quietvoid/dovi_tool/ ... 87b715344f

[RESET_9999]

I'm using the Ugoos AM6B+ with the latest nightly build 21.2-Omega. Does this update mean anything? How do I get it?

read few post back, I posted a link to the new build

[deadchip12]

I'm using the Ugoos AM6B+ with the latest nightly build 21.2-Omega. Does this update mean anything? How do I get it?

read few post back, I posted a link to the new build

Thanks I saw it. Is this an unofficial build? Will the CoreElec team put this in a future stable build?

And i read that we need to type in some commands in order for this to work? How do I do that?

[RESET_9999]

It's very unlikely. The CE team will hate CPM regardless of how good his builds are. You can't even mention his name on the CE forum; they will censor you.

You have all the info you need to get everything working in the links posted here.

[deadchip12]

It's very unlikely. The CE team will hate CPM regardless of how good his builds are. You can't even mention his name on the CE forum; they will censor you.

You have all the info you need to get everything working in the links posted here.

So after updating to this CPM build, I shouldn't update to future CE build?
And since this update enables L5 on the Ugoos, when transfering DV to HDR10 bluray file, I need to edit L5 when necessary now?

[deadchip12]

Anyway, I already did a couple of positive lift test files and real scenes here: https://drive.google.com/drive/u/1/fold ... r5CiYJ9KKj

Just updated the ugoos to cpm build.

I just tested the 4 files outside the real content folder and saw no change in brightness at all. The one inside the real content folder with the screenshot you posted showed brightness change, but only the 4000 nit file, not the 1000 nit one.

I tested L5 using this file: https://drive.google.com/drive/u/1/fold ... LZEUH69zAV and could see the transparent border change. So L5 is working, no? Why offset above still doesn't work?

[RESET_9999]

So after updating to this CPM build, I shouldn't update to future CE build?
And since this update enables L5 on the Ugoos, when transfering DV to HDR10 bluray file, I need to edit L5 when necessary now?

doing L5 correctly is always part of all my tutorials, so if L5 is not set correctly, it will cause issues...

I just tested the 4 files outside the real content folder

the steps test files? they raise lift gradually, you should see a major change, especially over 2600.

Any file in that folder shows a difference on my C2, but of course, the effect is always more evident with a 4000nits RPU.