www.makemkv.com

Posted: **Fri Jan 31, 2025 12:02 pm**

unless those spikes are just small detail-less specular, this movie will clip highlights on the bluray players or ugoos + old CE.

Posted: **Fri Jan 31, 2025 3:34 pm**

RESET_9999 wrote: Fri Jan 31, 2025 12:02 pm unless those spikes are just small detail-less specular, this movie will clip highlights on the bluray players or ugoos + old CE.

because of cmv2.9?

Posted: **Fri Jan 31, 2025 3:43 pm**

darrrkmanxxx wrote: Fri Jan 31, 2025 3:34 pm because of cmv2.9?

No, because the bluray players and non-cpm CE builds are altering the RPU. They limit the metadata values to the mastering display which causes clipping.

Posted: **Fri Jan 31, 2025 4:55 pm**

RESET_9999 wrote: Fri Jan 31, 2025 3:43 pm
darrrkmanxxx wrote: Fri Jan 31, 2025 3:34 pm because of cmv2.9?
No, because the bluray players and non-cpm CE builds are altering the RPU. They limit the metadata values to the mastering display which causes clipping.

ah yes, sorry. You've mentioned that before.

Posted: **Sun Feb 02, 2025 2:51 pm**

ragico wrote: Thu Jan 11, 2024 11:52 pm RESET_9999
In your opinion which gives the best quality nearest the creator's intent on X800m2, via Serviio in ts containers, between STDL and DTDL?

How can I get MKV_Patcher.py ,I can't find it in this article,could you share it with me.Thanks you!
@ragico

Posted: **Mon Feb 03, 2025 2:23 am**

@RESET_9999 -- I did a bit of testing of scene cuts in Resolve and re-confirmed what you found --- that Resolve is decoding HEVC inaccurately and the source needs to be transcoded to ProRes first.

So, when transcoding to ProRes with FFMPEG, should we be concerned about HW decoding accuracy?

And if one doesn't need any other AviSynth filters for a workflow, do you think there's an accuracy advantage to indexing (with either FFMS2 or DGIndexNV)?

TL;DR ---

Since ProRes is a fast and efficient codec that can benefit from a fast decoder, HW decoding can speed up the transcoding by ~2x overall. I get 60-80 fps with SW decoding and 140-160 fps with HW decoding using prores_ks, profile 3, qscale 11.

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.

So, I started testing using NVDec directly with FFMPEG (-hwaccel cuda) without indexing the file and I saw another 1-2x speed improvement (25-50 fps) without AviSynth and DGIndexNV indexing.

So there's a pretty big benefit to HW decoding in general, and to cutting out additional processing steps and software, if the process can be trusted without those steps.

Testing ---

HEVC in mkv container, to use as the source for FFMPEG
HEVC remuxed to mp4 container, to use as the source for Resolve
ProRes 422 HQ transcode with prores_ks SW encode and SW decode on Windows (using FFMPEG, FFMS2 indexing)
ProRes 422 HQ transcode with prores_ks SW encode and NVDec HW decode on Windows (using FFMPEG, L-SMASH-Works indexing, LWLibavVideoSource(..., prefer_hw=1))
ProRes 422 HQ transcode with prores_ks SW encode and NVDec HW decode on Windows (using FFMPEG, DGIndexNV indexing)
ProRes 422 HQ transcode with prores_ks SW encode and NVDec HW decode on Windows (using FFMPEG, -hwaccel cuda)
ProRes 422 HQ transcode with Apple silicon (M1 Max) HW decode+encode (using Resolve)
ProRes 422 HQ transcode with Apple silicon (M1 Max) HW decode+encode (using FFMPEG)
Resolve 19.1 on Windows
Resolve 19.1 on macOS

I found the L1 and L2 trims will always be slightly different, and in reading the Dolby docs, it is expected to get slightly different output every time you analyze shots, so I guess that is not a surprise due to the nature of the algo.

To compare, I used StaxRip to index and preview the source mkv file, remuxed mp4 file, and ProRes output files using FFMS2. I also indexed and compared to the source files using DGIndexNV.

With the mkv files, Resolve would show clips with Media Offline. With the mp4 files, Resolve wouldn't show Media Offline, but viewing the frames using its decoding/indexing would be inaccurate compared to FFMS2/DGIndexNV.

When I indexed the transcoded ProRes files with FFMS2, the encodes using FFMPEG were frame-accurate to the source, while the encodes using Resolve showed the frame inaccuracies that Reslove showed in its decoding/indexing.

All of the indexing/decoding methods using FFMPEG were frame-accurate.

Code: Select all

+---------------+--------------+-------+--------------+-------+-------------------+
|   Indexing    |   Decoding   | HW/SW |   Encoding   | HW/SW | Speed vs realtime |
+---------------+--------------+-------+--------------+-------+-------------------+
| FFMS2         | libavcodec   | SW    | prores_ks    | SW    | 2-3x              |
| L-SMASH-Works | NVDec        | HW    | prores_ks    | SW    | 3-4x              |
| DGIndexNV     | NVDec        | HW    | prores_ks    | SW    | 5-6x              |
| None          | NVDec        | HW    | prores_ks    | SW    | 6-7x              |
| None          | VideoToolbox | HW    | VideoToolbox | HW    | 7-8x              |
+---------------+--------------+-------+--------------+-------+-------------------+

Posted: **Mon Feb 03, 2025 3:11 am**

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

Posted: **Mon Feb 03, 2025 7:14 am**

RESET_9999 wrote: Mon Feb 03, 2025 3:11 am
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.

Posted: **Mon Feb 03, 2025 8:14 am**

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?

Posted: **Mon Feb 03, 2025 10:11 pm**

darrrkmanxxx wrote: Mon Feb 03, 2025 8:14 am 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.

Posted: **Wed Feb 05, 2025 2:26 am**

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?

Posted: **Wed Feb 05, 2025 9:35 am**

nekno wrote: Mon Feb 03, 2025 10:11 pm
darrrkmanxxx wrote: Mon Feb 03, 2025 8:14 am 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

Posted: **Wed Feb 05, 2025 5:24 pm**

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 !

Posted: **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

Posted: **Fri Feb 07, 2025 3:11 pm**

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

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''

www.makemkv.com

Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.