In VideoPad when I want to do a quick render, I just set the render output to 720p and it runs pretty quickly. In Kdenlive I guess all the effects are processed at the project resolution, so it doesn't matter what resolution you render out to, the speed is almost the same. And unfortunately changing the project's resolution isn't easy.
Do not change the project resolution. Enable rescale in the render window to get a smaller video.
(In reply to emohr from comment #1) > Do not change the project resolution. Enable rescale in the render window to > get a smaller video. Ok I tried 853x480 resolution render output, MP4-H264/AAC, but it's still only rendering at 13 fps. I guess it's still doing all the effects and compositing in 4k so it's still going to be slow no matter what resolution I rescale to?
I did some tests. I made a simple project, just 1 clip, 24 seconds long. Did a preview render in VideoPad (854x480 resolution) and VideoPad rendered it in 4.4 seconds (ran the timer on my phone not trusting the program's own timer). Same thing in Kdenlive with the latest daily build (kdenlive-master-8257-windows-gcc-x86_64.exe), 854x480 resolution, even using proxy clips, it took 40.46 seconds. Without using proxies it took 40.03 seconds (so it's within margin of error). I tried Mpeg2 and it took 40.41 seconds, DIVX took 42.46 seconds, and Nvidia H264 ABR took 40.41 seconds. Here is the test video I used https://drive.google.com/file/d/1MroTkEVVpHHAS5hEnSDjfut5FXjP20gx/view?usp=sharing I will also attach the project files.
Created attachment 169799 [details] kdenlive test project file
Created attachment 169800 [details] VideoPad test project file
Created attachment 169801 [details] kdenlive render settings
Created attachment 169802 [details] kdenlive render results
Rendering just the audio track also takes longer than I would expect. I just rendered a 1h55m 4k 60fps video (video track and audio track) in 10 hours, then I wanted to mess with the audio levels so I figured I would just render audio and then use ffmpeg to merge them. But the audio rendering took 1h22m50s, which is definitely an improvement but I would've expected better than 2x rendering speed compared to playback speed for just audio.
Thank you for all this test. I can confirm that the VideoPad render algorithm is very good, uses CPU&GPU very efficient. Playback is in VideoPad very smooth as well, as some GPU prerendering is always ongoing. In Kdenlive preview rendering leads to a choppy playback. Videopad seems to make all the time timeline preview rendering and maybe use this data for rendering.
I downloaded the daily build yesterday, 24.11.70 kdenlive-master-8737-windows-gcc-x86_64.exe, and it seems improved! I rendered a video with 3 1080p 60fps videos shown at a time and an image proxy clips, preview resolution (what does this do when my monitor is set to 1:1? does it match the output resolution?), 1080p at 42 fps 4k did 13 fps similar to before
Actually my 1080p render (not using proxy clips or preview resolution) slowed down massively in the middle, it started at 32 fps but now it's down to 7 fps
(In reply to die4ever2005 from comment #11) > Actually my 1080p render (not using proxy clips or preview resolution) > slowed down massively in the middle, it started at 32 fps but now it's down > to 7 fps and melt.exe is still using almost 100% CPU power despite only doing 7 fps, nothing changed in the video it's still the same layout just playing 3 1080p videos at once also this really makes me wish I could stop/resume rendering, like to restart the program and then resume rendering and see if that fixes it
Is it doing video decode on the CPU or GPU? I noticed while rendering if I look in Task Manager, my GPU shows 0% for Video Decode load, it does correctly show about 28% Video Encode load.
I just noticed that while generating proxies, Task Manager shows my GPU doing lots of Video Encode AND Video Decode, which explains why it's decently fast. When doing rendering, I only see Video Encode, so my CPU is doing video decoding which could be pretty expensive for 3 videos at once especially if they're x265 videos.
I noticed parrallel processing doesn't let me go beyond 12 threads (what my CPU has), but it's only using about 80% to 85% of my CPU. I wonder if 13 or 14 threads would render a little bit faster? Especially if I close all these program I have open right now like Chrome and VSCode.