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