Dolby Vision now possible through MP4 Mux.

[RESET_9999]

When using an mp4 container to generate my own Balanced content mappings, I will diff them against your T3 generated mappings, and see one-frame differences in the duration of scenes, or differences in trims that match to the tenths or hundredths, but are different by thousandths+.

Are those a result of dropped frames in the HEVC decoding, or perhaps something else?

I could see different versions of Resolve perhaps including changes in the DV algo or tuning that would result in different trims, but the differences in scene duration is a problem that could result in a lot of light/dark flashing between bright/dim scenes.

Yes, I guess the scene cut detection could be less accurate than a lossless codec with only i-frames.

How do you test for dropped frames, what are the telltale signs?

Your L1 plot will show 10 000nits spikes when there are dropped frames

Is Media Offline what you're looking for?

yes

When using an mkv container I see a lot of "Media Offline" scenes when scrubbing through the timeline, and I didn't see that with an mp4 container. So I'm wondering how I know if the mp4 container is indeed dropping frames.

MP4 works a lot better but I've seen 2-3 times ''media offline'' clip in the test I did. So it still can drop frame.

[jayper]

PS, to those who generate DV...

I said a couple of times that I selected the mastering display luminance based on the content's actual brightness(measured in 6-2).
I said to use 1000nits MDL if 90%+ of the shots have highlights under 1000nits.

Well, this is not longer the right thing to do because I recently discovered that some players like the Ugoos, Oppo, x700, X800m2 will clip highlights if the content is brighter than the RPU mastering display luminance, regardless of the metadata. So it may not be a good idea after all to use 1000nits MDL even if there are only a few highlights brighter than 1000nits because they will be clipped if your TV is not capable of displaying this brightness.

Interestingly, the Shield, the AppleTV, C2-C1-C9 internal player and Hisense internal player do not have this behavior and will tone map the image correctly without clipping regardless of the MDL (as long as L1 is right). This finally explains the RPU response differences between TV-LED devices that we noticed a long time ago (years ago?).

I did some test files that clearly show what I'm talking about: https://drive.google.com/drive/u/1/fold ... URFcibN6X-
Specifically: ''Dolby Vision 1000nits RPU Harry 2848nits scene P8.mp4''

*** This is about TV-LED. LLDV seems to work properly. Confirmed on oppo, ugoos, C9 C1 C2 Hisense... I no longer have the x700 x800m2 but it is most likely the same as the oppo, they have the same soc

Apologies if this is a silly question, but is has been a while since I generated DV.

If I am using 3-1 to generate, do I not just select what the source file reports in MediaInfo? Or do we need to run 6-2, before running 3-1?

If there is a good and up-to-date tutorial for this, please feel free to direct me there. Thanks!

[RESET_9999]

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

[nekno]

Your L1 plot will show 10 000nits spikes when there are dropped frames
...
MP4 works a lot better but I've seen 2-3 times ''media offline'' clip in the test I did. So it still can drop frame.

This is great info, as always. Thanks!

I plan to do a little testing with different containers across macOS and Windows.

One downside with the mp4 container is that Resolve keeps incorrectly detecting 23.976 fps content as 24 fps, so I have to be sure to manually set the project fps.

[darrrkmanxxx]

@RESET_9999

I have a weird RPU which look slike this


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

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