Dolby Vision now possible through MP4 Mux.

[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

[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