www.makemkv.com

coopzr wrote: Fri Feb 07, 2025 12:55 pm Hey @RESET_9999, some questions for you.

1. Does HDR10+ have manual artistic trim capabilities equivalent to DV? For example, I understand that cmv2.9 L2 trims and cmv4.0 L8 trims are 100% manually generated. Do colourists even have this capability in HDR10+? If yes, are these manual artistic trims lost when converting HDR10+ to DV?

2. In the case of generating dynamic DV from a static source, why is it that we should ignore the 'mastering display color primaries' and 'mastering display luminance' from the mediainfo and instead measure the hdr brightness to determine if maxcll is >10%? Is it simply the case that the mediainfo is incorrect or is this an artistic decision?

3. I have a very new LG OLED (C4) and the L5 black bars only slightly dim my screen instead of making them black (as is the case with most OLED's I believe). I rarely watch movies with subtitles and even if I did, the slight dimming is fine and doesn't affect my viewing experience. Should I set dolby_vision_keep_source_meta_level_5 to 0, 1 or 2?

I appreciate everything you do for the community and the many hours you have spent sharing your knowledge

RESET_9999 wrote: Fri Feb 07, 2025 3:11 pm 2. static tone mapping is used on top of the dynamic metadata in DV. A 4000nits MDL looks much darker than a 1000nits MDL with the same dynamic metadata. Also, with a 4000nits MDL, Level 1 starts dimming with lower values. It starts at 400nits on my C2 while with the 1000nits MDL, it starts dimming only at 850nits.

Is mediainfo simply wrong sometimes

is there a technical reason that 'mastering display color primaries' and 'mastering display luminance' should be ignored?

A 4000nits MDL looks much darker than a 1000nits MDL with the same dynamic metadata

darrrkmanxxx wrote: Sat Feb 08, 2025 11:31 am Hey guys,

at which step davinci rersolve does a bad job with hevc?

Scene detection or the analyzing itself?

nekno wrote: Sun Feb 09, 2025 9:07 am

darrrkmanxxx wrote: Sat Feb 08, 2025 11:31 am Hey guys,

at which step davinci rersolve does a bad job with hevc?

Scene detection or the analyzing itself?

IME, it isn't the scene detection or CM analysis, per se, it's that the frames are decoded inaccurately from the start, so bad data is fed to both algorithms, making both inaccurate as a result. Garbage in, garbage out.

In my testing, the HEVC decoding in Resolve was inserting additional frames, so as a result the scene starts and durations were all inaccurate, not because the scene detection algo is bad, but because (as you can see when scrubbing through the video) the scenes actually do start and end at inaccurate frames. And the DV CM algo is based on scenes and frames, so if it doesn't get accurate data, it's going to start and stop scenes at inaccurate times.

For example ---

3 actual scenes:
(1) Start frame: 0, Duration: 100; (2) Start frame: 100, Duration: 100; (3) Start frame: 200, Duration: 100

Resolve-decoded HEVC:
(1) Start frame: 0, Duration: 101; (2) Start frame: 101, Duration: 103; (3) Start frame: 204, Duration: 100

So all the scenes in the DV metadata start sliding later by a couple/few frames each time another frame decoding error is introduced (in scenes 1 & 2).

darrrkmanxxx wrote: Sun Feb 09, 2025 3:21 pm Honestly I'm getting exactly the same behavior with Prores422 on macos in resolve when I let it do it the background while working with other apps.
Resolve only does it's job when I leave the computer completely untouched. So resolve is very unreliable in that way.

RESET_9999 wrote: Mon Feb 10, 2025 6:23 pm Baking FEL requires re-encoding so what you're asking is not possible.
An untouched FEL remux can only be played properly on a device that can decode it.

Just get the Ugoos if you want the best quality without compromise.

MODE.B (5) =
BATCH MUXER

Can batch mux any DV source to TS or MP4
MKV/MP4 to TS
MKV/TS to MP4