Dolby Vision now possible through MP4 Mux.

[staknhalo]

No,
static DV metadata for a movie graded in the 1000-4000nits is not good and probably worse than static HDR10 because DV metadata is a lot more aggressive than HDR10 static curves.
For example if you have a 4000nits grade with a static 1000nits DV metadata. All the low-nits scenes will be darker and the brighter scenes will be more clipped than proper HDR10 metadata tone mapping curve. It's practically the same as making a DV P8 hybrid using two sources with different brightness, as shown here: https://www.youtube.com/watch?v=236athosits

Those movies with static DV are not done properly and should be avoided...
Trap is done properly because the content is below the DV 100nits floor (min)

got it - so essentially as long as there's even just 'a little' data/grading in the L1 (as in native Trap and Longlegs) it's 'good' DV data - French Dredd still bad - thanks

Edit - I verify pre-aligned remuxes with the web source or different disc release just by quickly glancing at L1 which is why I wanted to be sure instead of aligning the web data to disc myself to be lazier lol

[LV8HD]

@RESET_9999 in the most recent update you introduced the possibility to measure brightness of an HDR10 video on a frame-by-frame basis, which, to me, seems the most correct approach. Does this mean the MadVR method is less accurate even with excluded letterboxes? does it work on a scene-by-scene basis?

[RESET_9999]

@RESET_9999 in the most recent update you introduced the possibility to measure brightness of an HDR10 video on a frame-by-frame basis, which, to me, seems the most correct approach. Does this mean the MadVR method is less accurate even with excluded letterboxes? does it work on a scene-by-scene basis?

good catch haha. I didn't mention it in the release note because it's soooooo slow that it's unusable. I practically wasted my time on this code but it is indeed a frame by frame analysis / plotting. It uses the same script that generates the maxcll/fall stats in (7-2) (7-1).

Madvr analysis is also frame by frame but because I use Dovi_tool to plot the data, the graph is shot by shot. It's still 100% accurate but the values are rounded shot by shot. MadVR overall should be more accurate too since it measure pixels perceptually while the other script just measures the pixels as they are without any restriction.

[kazuma]

reset_9999, how did you find the PQ of the tenant with cm4.0?

[RESET_9999]

I dont know, never watched it. I dont like old movies.

[LV8HD]

@RESET_9999 in the most recent update you introduced the possibility to measure brightness of an HDR10 video on a frame-by-frame basis, which, to me, seems the most correct approach. Does this mean the MadVR method is less accurate even with excluded letterboxes? does it work on a scene-by-scene basis?

good catch haha. I didn't mention it in the release note because it's soooooo slow that it's unusable. I practically wasted my time on this code but it is indeed a frame by frame analysis / plotting. It uses the same script that generates the maxcll/fall stats in (7-2) (7-1).

Madvr analysis is also frame by frame but because I use Dovi_tool to plot the data, the graph is shot by shot. It's still 100% accurate but the values are rounded shot by shot. MadVR overall should be more accurate too since it measure pixels perceptually while the other script just measures the pixels as they are without any restriction.

I see. Correct me if I'm wrong. MadVR measures pixels using perceptual quantization while the other script the raw data?

[RESET_9999]

right

[LV8HD]

@RESET_9999 pushed by curiosity I decided to check what the fastest method of measuring HDR with excluded letterboxes was on my PC (MKV measurement vs. Cropped ProRes measurement). The winner ended up being MKV although I have a good CPU (AMD Ryzen 7 7700x), but that's not the point.

As soon as both measurements were done (same movie) I took a look at them expecting to see the same results, however, they differed of a couple of nits. Why is that?

MKV measurement


ProRes measurement

[RESET_9999]

prores encode probably change the grain structure a little bit so small variation like that is normal

The winner ended up being MKV although I have a good CPU (AMD Ryzen 7 7700x), but that's not the point.

Thats surprising. On my i9 13900ks it's almost two times faster with prores.

[daffie]

reset_9999, how did you find the PQ of the tenant with cm4.0?

Hi, how do you watch ''with cm4.0'' ?
By using the CPM build with the AM6B+ ?

[TheEqualizer]

maybe, I dont know. You can also demux with tsmuxer

I've done all sorts of tests with this German edition of the movie "Late Night with the Devil". I used mkvtoolnix, dovi_script, DGDemux, MakeMKV, the first three have a similar output, the last one does not output correctly, but if you compare the scene-cuts of all the options, but they do not match the scene-cuts of the EL layer extracted using tsMuxeR, does this mean that technically remux mkv 7Profile is not allowed?

EL_scene-cuts

MKVToolNix_DoVi-Script_DGDemux_scene-cuts

https://i.ibb.co/KrX9cbG/EL-PLOT.png
https://i.ibb.co/VBs1t5h/ST-DL-PLOT.png

[RESET_9999]

I dont know. I watched this one in Profile 8 without EL and everything was fine.

[TheEqualizer]

I dont know. I watched this one in Profile 8 without EL and everything was fine.

I'll tell you more, those who have already watched the remux in mkv 7p also did not see anything suspicious, so in the question I pointed out that technically it is still not correct and it is not allowed to make such remuxs. Perhaps if a British UHD appears, things will be better on it.

[RESET_9999]

i dont know but my p8 remux is perfectly in sync with the BL scene cuts

[RESET_9999]

so in the question I pointed out that technically it is still not correct and it is not allowed to make such remuxs. Perhaps

I had another look at this movie and indeed a P7 mux with dovi_tool or mkvtoolnix is still wrong.
The RPU extracted from tsmuxer demuxed hevc is fine though so a P8 rip works.