Dolby Vision now possible through MP4 Mux.

[RESET_9999]

@RESET_9999

CPM also mentions ''meta level 6'' which defaults to N. Should we also enable this manually (like level 5)??
What do you recommend please?

Also since activating L5 on my LG OLED G1 I have problems viewing content below the picture. Everything seems to get stuck under the lowest black bar now. Part of the buttons when you pause the video are now stuck under the lowest black bar, same for subtitles. Any suggestions how to fix this? Same for the top bar, Dolby logos get partly stuck beneath it also. Only showing part of the Dolby logo that way.
How to fix this? Can you help me?

L6 is useless, N or Y is fine

Next build should have an option to set L5 always to 0 so the black bars wont hide anything and Positive offset lift will still work.

EDIT: actually the private builds already got that option:

levels module params now take number not Y/N

dolby_vision_keep_source_meta_level_5

0 - discard if present
1 - keep with source values or inject with zero values if missing
2 - keep with zero values or inject with zero values if missing [Default]

dolby_vision_keep_source_meta_level_6

0 - discard if present
1 - keep with source values [Default]

[deadchip12]

@RESET_9999

CPM also mentions ''meta level 6'' which defaults to N. Should we also enable this manually (like level 5)??
What do you recommend please?

Also since activating L5 on my LG OLED G1 I have problems viewing content below the picture. Everything seems to get stuck under the lowest black bar now. Part of the buttons when you pause the video are now stuck under the lowest black bar, same for subtitles. Any suggestions how to fix this? Same for the top bar, Dolby logos get partly stuck beneath it also. Only showing part of the Dolby logo that way.
How to fix this? Can you help me?

L6 is useless, N or Y is fine

Next build should have an option to set L5 always to 0 so the black bars wont hide anything and Positive offset lift will still work.

EDIT: actually the private builds already got that option:

levels module params now take number not Y/N

dolby_vision_keep_source_meta_level_5

0 - discard if present
1 - keep with source values or inject with zero values if missing
2 - keep with zero values or inject with zero values if missing [Default]

dolby_vision_keep_source_meta_level_6

0 - discard if present
1 - keep with source values [Default]

Any drawbacks of setting L5 to 0?

[RESET_9999]

No, not if the colorist respects Dolby's best practice not to lift over 0.025 (2100)

[daffie]

No, not if the colorist respects Dolby's best practice not to lift over 0.025 (2100)

And even if the colorist lifts over 0.025 (2100), the only downside is that the black borders get lifted together with the image.
Correct?

[RESET_9999]

And even if the colorist lifts over 0.025 (2100), the only downside is that the black borders get lifted together with the image.
Correct?

yes

[deadchip12]

And even if the colorist lifts over 0.025 (2100), the only downside is that the black borders get lifted together with the image.
Correct?

yes

that would look terrible on the oled

[daffie]

And even if the colorist lifts over 0.025 (2100), the only downside is that the black borders get lifted together with the image.
Correct?

yes

that would look terrible on the oled

That doesn't happen often anyway. You are making a problem about something that really isn't one in everyday use.
The other option is that everything is hidden behind the black bars (unless you have a very new OLED TV).

[darrrkmanxxx]

guys, did you saw the l1 plot from dark fate Fra-Me-STo-R release, looks very weird, right?

[RESET_9999]

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

[darrrkmanxxx]

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?

[RESET_9999]

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.

[darrrkmanxxx]

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.

[Han_Xinchen]

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

[nekno]

@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              |
+---------------+--------------+-------+--------------+-------+-------------------+

[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