xMaurycyx wrote:I still think the codec is not well supported here. GPU is in fact being used but when I apply some magic mask and animations it turns to a super laggy slide show. (I know I can cache it)
It's important to differentiate between a decoding bottleneck and a GPU bottleneck. In your case even though the video decode acceleration is located on the GPU, it is a totally separate "IP block." That logic is simply bundled on the GPU.
You can test decoding overhead vs GPU overhead by turning off all color Fx, including timeline effects such as stabilization, retiming, optical flow, etc, and test timeline playback and forward/reverse scrubbing performance. Then turn off decode acceleration in Resolve Settings, relaunch Resolve and try it again.
If it became fast with all Fx off, it's an Fx issue not a decoding issue. With all Fx off if timeline performance is fast with hardware decoding enabled but laggy with it disabled, that indicates hardware decode acceleration is working, at least to some degree. However you should also inspect decode acceleration activity as listed in Task Manager. Is that graph different when decode acceleration is enabled vs disabled?
You could also try generating optimized media using a DNx codec. That would save doing external transcoding.
xMaurycyx wrote:...I rendered the clip to AV1 and applied the same effects = 90% smoother. For the next project I'll render to AV1 in advance.
AV1 is a complex, compute-intensive Long GOP format roughly similar to HEVC. It should be difficult to play smoothly unless it's hardware accelerated. If you think that is smooth, do the above test and turn off decode acceleration. Is it still smooth?
Is it possible when you rendered the clip to AV1 it did not have the same timeline effects, such as optical flow or other compute-intensive effects applied in the timeline, not on the color page? Or is it possible rendering to AV1 "baked in" some compute-intensive effects that Resolve subsequently did not have to process?
There is no such thing as "It works or doesn't work for AV1 or H.264." Each codec has many different encoding options such as "open GOP" vs "closed GOP", number of B-frames, number of P-frames, M and N values (GOP Structure), etc. So you can have two H.264 codecs with the same resolution, same bitrate, same bit depth, and same chroma sampling, yet they can be radically different internally, and that can affect playback smoothness and compatibility for hardware decoding. The Puget Systems hardware acceleration tables are greatly simplified depictions. So it's possible on your specific system that for some reason the nVidia video decode acceleration doesn't handle Sony 8-bit 4:2:0 H264, but for some reason it handles AV1 better.
Historically it was necessary to edit using a transcoded "mezzanine" codec. When Long GOP codecs came along, they were first considered consumer items. The initial versions of hardware acceleration did not work that well and often had a negative impact on image quality. Later, Long GOP codecs proliferated into even professional cameras at higher bit depth and chroma sampling. Also more advanced hardware acceleration became available.
It's now generally possible to get good image results and (on proper hardware and software) get good editing performance on some 10-bit 4:2:2 Long GOP codecs. However it remains a tricky area. You cannot choose a camera, NLE, and hardware platform independently and expect it to just work. Those items must be meticulously researched and carefully selected.
In this area you cannot trust the vast majority of reviews. It is time-consuming and difficult to test video decode performance, plus requires lots of knowledge. Most reviewers don't have a deep understanding of video processing. They use simplified canned procedures such as timed export tests, and they don't differentiate between decode vs encode performance. Those tests are not informative about the overall video acceleration behavior.
Tue Apr 09, 2024 9:44 am
