Dolby Vision now possible through MP4 Mux.

[RESET_9999]

Yeah, when I did the video, I was using tuning 1.
After more tests/comparisons, I now prefer tuning 3 because it's a bit brighter without clipping. Both tunings are good though and tuning 3(balanced) is Resolve default.

[dkangel]

ok thank you

[powdeau]

Does Chroma Weight makes a big difference if it is used only in 100 nits trim?

[RESET_9999]

Does Chroma Weight makes a big difference if it is used only in 100 nits trim?

yes and it doesn't matter if it's only a 100nits trim because whatever they did in the SDR trim gets extrapolated to any brightness.
thankfully CW is not used very often.

[darrrkmanxxx]

Does Chroma Weight makes a big difference if it is used only in 100 nits trim?

yes and it doesn't matter if it's only a 100nits trim because whatever they did in the SDR trim gets extrapolated to any brightness.
thankfully CW is not used very often.

so if there are no CW trims (flat line) at 1000nits and my device has 1000nits peak brightness, will it still be tone mapped because of the 100nit trim?

[RESET_9999]

so if there are no CW trims (flat line) at 1000nits and my device has 1000nits peak brightness, will it still be tone mapped because of the 100nit trim?

If there's a blank 1000nits trim, the 100nits trim gets ignored if your target brightness is 1000+
If there's a blank 600nits trim, the 100nits trim gets ignored if your target brightness is 600+

if there's just a 100-nits trim, yes the metadata gets extrapolated to any brightness but the higher your TV target is the less effect the trims have.
if you're using LLDV, and if you use an edid of 1000+ then the trims are 100% ignored if the RPU MDL is 1000nits (tested on shield, ATV, ugoos, x800m2 x700).

@powdeau confirmed to me that the trims are not ignored in TV-LED on the LG G4 with 1000nits RPU, so the behavior is different than LLDV because that TV must have a target higher than 1000nits.
I see the same behavior with my 2000nits Hisense TV, the trims always work regardless of the RPU MDL. So the trims not working in LLDV with 1000nits edid might be another DV bug.

He also confirmed that Chroma Weight doesn't work in cmv2.9 on the G4, same as my C2 and hisense TV. So dolby cmv4.0 fixed the Chroma Weight bug in LLDV and broke it in TV-LED for cmv2.9... typical Dolby...

[powdeau]

@RESET_9999 I have tried your metadata comparison for Kill Bill 1 and Smile 2 on my G4 and I don't see any changes with Kill Bill but I do se them with Smile.
Is it because Kill Bill has almost no trims in 1000nits or because Smile is mastered for 4000 nits?

[RESET_9999]

By the look of the L2 trims and the content brightness, it sounds normal.

Smile 2 is graded at SDR level but in some shot, the trims have very strong brightening values. So you probably see no change with L1, but a brighter image with L1+L2
kill bill is a bit brighter but still only 400nits and the trims don't brighten as much as Smile 2.

And yes, the RPU also has more effect when it's 4000nits MDL.

[powfu]

anyway the problem is the EL and german discs

I wonder if all the French UHD-BD should be verified now. It looks like Blade 1998 FEL FRA BD has the same issue

https://slow.pics/c/YzYgHn4x

Hi, I'm just curious. I checked the FraMeSToR version which used the FRA UHD BD and MakeMKV. ffmpeg counts 172,927 frames and dovi_tool also counts 172,927 in the RPU as well. I've attached the plot. Is this release unaffected?

Parsing RPU file...

Summary:
Frames: 172927
Profile: 7 (FEL)
DM version: 1 (CM v2.9)
Scene/shot count: 2533
RPU mastering display: 0.0001/1000 nits
RPU content light level (L1): MaxCLL: 996.13 nits, MaxFALL: 427.95 nits
L6 metadata: Mastering display: 0.0001/1000 nits. MaxCLL: 1217 nits, MaxFALL: 884 nits
L2 trims: 100 nits, 600 nits, 1000 nits

[skull88]

AFAIK, it might matter which version of makeMKV is used, no? Could be how their encode wasn't affected. It does seem that it is worth verifying all EUR discs if using current version though.

[RESET_9999]

Hi, I'm just curious. I checked the FraMeSToR version which used the FRA UHD BD and MakeMKV. ffmpeg counts 172,927 frames and dovi_tool also counts 172,927 in the RPU as well. I've attached the plot. Is this release unaffected?

I don't know, I'll check it out.

[powfu]

Hi, I'm just curious. I checked the FraMeSToR version which used the FRA UHD BD and MakeMKV. ffmpeg counts 172,927 frames and dovi_tool also counts 172,927 in the RPU as well. I've attached the plot. Is this release unaffected?

I don't know, I'll check it out.

Using the Zapax FRA UHD BD and MakeMKV 1.17.8, I get the same results.

Code: Select all

Parsing RPU file...

Summary:
  Frames: 172927
  Profile: 7 (FEL)
  DM version: 1 (CM v2.9)
  Scene/shot count: 2533
  RPU mastering display: 0.0001/1000 nits
  RPU content light level (L1): MaxCLL: 996.13 nits, MaxFALL: 427.95 nits
  L6 metadata: Mastering display: 0.0001/1000 nits. MaxCLL: 1217 nits, MaxFALL: 884 nits
  L2 trims: 100 nits, 600 nits, 1000 nits

Code: Select all

Disc Title:     Blade.1998.2160p.FRA.UHD.Blu-ray.HEVC.TrueHD.Atmos.7.1-Zapax
Disc Size:      90,487,440,940 bytes
Protection:     AACS2
Extras:         Ultra HD
BDInfo:         0.7.5.9 (compatible layout created by DVDFab 12.0.7.0)

PLAYLIST REPORT:

Name:                   00006.MPLS  
Length:                 2:00:12.496 (h:m:s.ms)
Size:                   88,383,080,448 bytes
Total Bitrate:          98.03 Mbps

(*) Indicates included stream hidden by this playlist.

VIDEO:

Codec                   Bitrate             Description    
-----                   -------             -----------    
MPEG-H HEVC Video       77400 kbps          2160p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / HDR10 / BT.2020
* MPEG-H HEVC Video     8644 kbps (10.05%)  1080p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / Dolby Vision FEL / BT.2020

AUDIO:

Codec                           Language        Bitrate         Description    
-----                           --------        -------         -----------    
DTS-HD Master Audio             French          2576 kbps       5.1 / 48 kHz / 2576 kbps / 24-bit (DTS Core: 5.1 / 48 kHz / 1509 kbps / 24-bit)
Dolby TrueHD/Atmos Audio        English         4024 kbps       7.1+11 objects / 48 kHz / 3576 kbps / 24-bit (AC3 Core: 5.1-EX / 48 kHz / 448 kbps)

SUBTITLES:

Codec                           Language        Bitrate         Description    
-----                           --------        -------         -----------    
Presentation Graphics           French          0.272 kbps                      
Presentation Graphics           French          14.43 kbps

[RESET_9999]

I dont know, I had an old rip so I assumed it was muxed with makemkv. Maybe not after all.
Some of my ST P7 rips were muxed with mkvtoolnix from DT P7 TS so that might be the reason.

[powfu]

Alright, thank you. I guess this disc does not suffer from those issues then.

Just for posterity and completeness, using the Zapax FRA UHD BD and mkvmerge v89.0, the result is the same as above.

[nekno]

Yes, I tested hevc decoding not a long time ago and it still drops frames.
Try the Spears and Munsil demo clip, it drops frames almost instantly with the mkv container. If you remux it to mp4, the SM clip will work but it is still not 100% reliable.

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

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.

Is Media Offline what you're looking for?

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.