Dolby Vision now possible through MP4 Mux.

[RESET_9999]

CMV2.9 and CMV4.0? Only one l2 trim.
Should I go for cm_analyze in such case?

if the trim is not static, remove cmv4.0
All the older MA webdl has this weird 2-frames cmv4.0 data.

[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.

[RESET_9999]

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

[jayper]

The best is to use an MDL based on the measurement from 6-2 but the mediainfo metadata is ok.

So, just to make sure I understand and am coming to the correct conclusions:

I had started to generate DV metadata for the new Seinfeld UHD Set, when you commented about any content that that peaks above 1,000 nits and how that content could clip (on certain devices) if the MDL was set at a 1,000 nits. When initially generating, I selected P3 1000 nits, based on the information presented by MediaInfo, below:



As a test, I ran one episode through the 6-2 workflow this morning and produced the following plot:



Dumb question, but I am all good with my previously generated metadata right? The only thing I would be looking for is any maximum nits peaking over 1,000. Is that correct? Thanks so much!

[RESET_9999]

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.

[jayper]

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.

Wow, that's very interesting and great news!

Is that a change that will get pushed down with a nightly to a Ugoos AMB 6+?

[RESET_9999]

You can use this new build right now if you want:

https://www.avsforum.com/posts/63803626/

[SamuriHL]

Wow, you're mean and didn't tell him about this part?? LOLOL Just kidding but this part is important if you want L5 support as you clearly know.

https://www.avsforum.com/posts/63803659/

[RESET_9999]

haha right.

[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.