Kdenlive: 25.12.2
Kdenlive: 25.12.2 - rev. 5db6066
MLT: 7.37.0
FFmpeg
KDE Frameworks: 6.22.0
Qt: Using 6.10.1 and built against 6.10.1
Windows 10 Version 22H2
Build ABI: x86_64-little_endian-llp64
Rendering to .mp4
I’ve used both Akaso and older GoPro footage with kdenlive for a year or two. It’s been fine, the rendering takes an average of 20-40 minutes at its worst, less than 10 minutes at best. 2.7k resolution with motion smoothing on. Neither camera can do 4k with motion stabilization on.
I bought a new camera, DJI Osmo 6. I’ve rendered twice. First one took 3hrs and 47min to render 17minutes of footage. The one currently in progress is projecting 2hrs and 37 minutes for 14 minutes of footage. Osmo 6 can handle 4k resolution with motion stabilization on.
Same laptop. I’m not changing much of anything here in terms of vid formatting or content type from within kdenlive. Multiple video clips, 1 audio track, some text overlays with an occasional photo insert. Same “pattern” of vid for the last year or so. The big difference is the camera and the capacity to bump it up to 4k. There is additional detail with the Osmo 6 camera due to its capacity to “see” in shadow/low light, something GoPro is god awful at doing, so that may be impacting the rendering speed as well.
My question is, is the significant rendering time increase to be expected when going from 2.7k to 4k, or can steps be taken to reduce rendering time without sacrificing resolution? I expected rendering to take more time with better vid, just not a +800% increase at the cost of half the night. It feels a bit like Napster is back and I’m trying to burn a CD.
Do you somehow find that surprising? The number of pixels to process increases with the square of the resolution, and that’s before you start on the probable increase in bitrate (and therefore detail) in the new source material.
If I put four times as much food on your dinner plate as you usually have, do you think you’ll be able to eat it in the same amount of time?
NVIDIA NVENC is pretty darn good, quality loss should be negligible, but it should offer a nice speed bump over doing everything on the CPU. So I would say its worth it.
Dedicated hardware transcoding is more efficient and therefore faster. In fact, software H.264 transcoding (CPU) currently offers better quality. So use hardware-NVENC H.265, quality/compression you can adjust
Yes, that’s the mythos which sells the sausages. What goes on in the factory is considerably more nuanced. and trade-offs are not the same as ‘efficiency’.
Speed, Quality, Compression is always going to be a pick any two thing.
The trick is knowing when to care about which the least.
And you have to keep in mind that NVENC and VAAPI only help during the encoding step of the rendering and not during the compositing step where all the effects/filters are applied. That is done only by the CPU, so the beefier your CPU the faster the rendering.
Yes. There is an incompatibility between MLT using the movit library for HW acceleration and how Kdenlive is handling clips and effects. Work is underway to implement HW support for playback, effect application, and compositing. No ETA yet, sorry.
Just to throw in my two cents here, but you can also render to AV1 with hardware encoding on most modern GPUs, which offers better compression (but will likely be slower to encode than H264/H265).
Render > Hardware Accelerated > NVENC AV1 VBR
If you’re using an AMD/Intel GPU or your GPU isn’t being detected properly, you can go to Settings > Run Config Wizard… to see if Kdenlive is detecting your GPU. It will then attempt to enable whatever hardware acceleration profiles it can based on the GPU you have installed.
Changing the format, for example from .MOV to MP4, compression, and other tasks you mentioned are handled by the CPU. Hardware transcoding significantly reduces the load on the CPU and lowers rendering time.
You’re confusing things. Video transcoding is similar to encryption, but it’s faster to do with dedicated hardware. Modern CPUs have a separate module for SHA512 encryption.
Modern CPUs have a separate module for SHA512 encryption
There aren’t many video codecs where SHA512 or AES is the bottleneck on coding speed.
Video transcoding is similar to encryption
Call me a Doubting Thomas, but I don’t think either of lossy encryption or a video encoding that increases its source size is really going to catch on.
Unless you mean the sort of similar where triangles are similar to squares.
But even in that universe, faster != smaller or higher quality.
OP has an RTX 2080 with only H.264/265 transcoding.
AV1 will still give them better compression for the same or better quality.
<Fade to chorus>
There are no one-size-fits-all answers. There are no magic bullets.
Which if you actually read in its entirety, also clearly shows that it’s a pick any two relationship. If you blindly optimise for speed, it comes at the cost of quality and/or compression. And hardware encoders are, kind of by definition, optimising for speed because that’s their entire sales pitch. So they don’t/can’t do things which software encoders do to very effectively maximise quality per bit spent which would be very expensive or slow to do in their hardware.