Dolby Vision now possible through MP4 Mux.

[RESET_9999]

I made a patch to ENCODERS_PRORES_GUI.bat in DoVi_Scripts to use DGIndexNV instead of FFMS2 when an NVIDIA GPU is detected and saw accurate results, but then I wondered if indexing is really needed if no other transforms are needed on the video.

Yes, encoding to prores without indexing is probably fine(at least in the tests I did) and it is faster, indeed but I still prefer indexing for peace of mind.
In the non-gui version of dovi_scripts(latest beta only), you can disable indexing for the prores encoding workflow 8-2-3
line 251
::choose if you want to index your input before the prores encoding in 3-1 and 8-2-3 default=NO
set disable_indexing=NO

https://github.com/R3S3t9999/DoVi_Scrip ... ussions/57

[nekno]

I made a patch to ENCODERS_PRORES_GUI.bat in DoVi_Scripts to use DGIndexNV instead of FFMS2 when an NVIDIA GPU is detected and saw accurate results, but then I wondered if indexing is really needed if no other transforms are needed on the video.

Yes, encoding to prores without indexing is probably fine(at least in the tests I did) and it is faster, indeed but I still prefer indexing for peace of mind.

https://github.com/R3S3t9999/DoVi_Scrip ... ussions/57

Sounds good, thanks. I'll check it out. I might want to keep indexing, too. I'll waste a lot of time worrying and doing quality control to ensure the decoding is accurate without indexing.

Per the discussion thread on your repo, using ffmpeg -hwaccel cuda won't work with AviSynth input, but the second-fastest option would still be to use DGIndexNV.

So you can get the benefits of both indexing and HW acceleration.

I'm happy to share my changes to ENCODERS_PRORES_GUI.bat and/or could help add support for it to CLI versions of DoVi_Scripts if you'd like the help.

[darrrkmanxxx]

ther's an app called kdenlive, which handles hevc in mkv pretty well and has this:
https://userbase.kde.org/Kdenlive/Manua ... SceneSplit
https://kdenlive.org/en/
Is it possible to utilize it for cm_analyzer?

[nekno]

ther's an app called kdenlive, which handles hevc in mkv pretty well and has this:
https://userbase.kde.org/Kdenlive/Manua ... SceneSplit
https://kdenlive.org/en/
Is it possible to utilize it for cm_analyzer?

Looks like 10-bit/12-bit color is on the midterm roadmap but not currently supported.

[Peterduke]

Are there any one click programs that’s don’t involve command line to compress 4k Dolby vision mkv files and preserve the Dolby vision? Handbreak claims to support it but will only convert it to hdr 10bit.

If not is there a way to drink them down to db50 or bd25 blank media for backup without losing the Dolby version?

[darrrkmanxxx]

ther's an app called kdenlive, which handles hevc in mkv pretty well and has this:
https://userbase.kde.org/Kdenlive/Manua ... SceneSplit
https://kdenlive.org/en/
Is it possible to utilize it for cm_analyzer?

Looks like 10-bit/12-bit color is on the midterm roadmap but not currently supported.

bummer, but maybe someday.
I actually use kdenlive all the time to find out frame times and sync sound, since I'm most of the time on macos

[paul8]

How can I know if a FEL has been properly baked into the BL?

I have two DV 8.1 files of the movie Wind River. Both encoders team are supposed to perform FEL Baking, but there's a difference between these two files that makes me doubt it.

The difference lies in the BL MDL value: 1000 nits for one, 4000 nits for the other. If a FEL is baked into the BL with an MDL RPU of 4000 nits, the BL MDL should also become 4000 nits, right? Or am I wrong ?





Thanks for your help !

[coopzr]

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]

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

1. No and AFAIK, HDR10plus is fully automated and not editable.
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.
3. I leave L5 active on my C2 since the semi-transparent mask doesn't bother me as well. So I use ''1''

[coopzr]

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.

I think I understand what you are saying. However, can you please elaborate on my question? Is mediainfo simply wrong sometimes or is there a technical reason that 'mastering display color primaries' and 'mastering display luminance' should be ignored?

[RESET_9999]

Is mediainfo simply wrong sometimes

mediainfo is ok and there's nothing wrong in grading 200nits (for example) on a 4000 monitor. You can use the original MDL if you doubt my reason, it's fine.

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

No other reason than the one I already told you.

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

[darrrkmanxxx]

Hey guys,

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

Scene detection or the analyzing itself?

[RESET_9999]

both

[nekno]

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]

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

got it. I really appreciate your explanation.
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.
I have radeon 6900 xt 16gb vram as gpu.
Resolve only does it's job when I leave the computer completely untouched. So resolve is very unreliable in that way.