I have a question on seeking delays, when seeking through clips in kdenlive while editing.

I've tried recording both x264 with ultrafast and keyint=1, and HUFFYUV. I playback on a 3.8 GHz six core haswell i7 CPU, RAID 0 array of two 512 GB SSDs and 16 GB of RAM. When I hit play, it plays. However, when I seek, it is incredibly slow. Kdenlive will eat all available RAM and hang for anywhere from a few minutes to 30 minutes before it is finally ready, and sometimes it doesn't load that portion of the video at all. Is there a way to resolve this?

The effect gets worse the more you seek out. Let's say I am at 5 minutes in a video file. If I seek to 5:05, I'm fine. If I seek to 5:30, it is slow with significant lag time. If I seek to 8:00, I will be waiting for five to twenty minutes, maximum CPU usage on all cores, and all 16 GB RAM used. It may load after twenty minutes, or it may never load at all.

If I am seeking through a rawvideo file, this does not exist at all. There is no lag, it is always instant.

I know huffyuv, or x264 with ultrafast preset will be more CPU intensive to decode than plain uncompressed rawvideo. However, if I play back these files with mplayer2 or VLC, it will decode, I can watch it, and I can even seek without using much CPU power. This is with no GPU accelerated decoding. With kdenlive I am stuck waiting 15 to 30 minutes on what is a relatively fast and powerful machine for the same task.

I appreciate the disk space savings I get on the 1 TB array by recording to x264 or huffyuv, so I'd like to continue to do so. I can encode proxy clips but it adds an extra timewasting step to the process, and looks worse. Above all, I feel the CPU, RAM, & disk storage solution I am using should be adequate to seek through these files which is why I have not been using proxy clips. I feel like I am either missing a simple option somewhere or there is some bug that's never been brought up that is causing this.

When I seek to 8:05 from 5:00, is kdenlive trying to decode the entire file to rawvideo from huffyuv from 5:00 to 8:05 and store it in RAM, or disk, or something similar? This is the only thing I can think of that would cause such long hangups or freezing working with huffyuv vs. rawvideo.

I've tried a few other machines with the same issues, but more slightly exaggerated since they lacked the power of my primary workstation. I feel an x264 file encoded with an ultrafast preset using keyint=1 should be fairly easy to seek through on such a powerful machine. What am I missing?

There are some libavcodec & MLT version combinations that cause that memory eating and hence performance killing. Try upgrading MLT from sunab PPA - git branch (if on ubuntu) or build MLT from source & point to that build before launching Kdenlive (set LD_LIBRARY_PATH)...
Need more details ?

Silly question - if I am using the kdenlive nightly build script, would I be using that version of MLT? This is the build-kdenlive.sh file I am using to download & compile new versions of kdenlive.

https://bpaste.net/show/8759b2c55eef

This lagging issue happens with both the portage versions of kdenlive(I use Gentoo distribution) and the nightly. Where would I set the LD_LIBRARY_PATH, assuming that the nightly build does not use this version of MLT by default?

I also don't get when importing a clip why CPU usage spikes for 2 or 5 minutes to unusable levels. I turned off video thumbnails, turned off audio waveforms, turned off proxy clips, turned off normalizing audio for thumbnails. I have no idea what it could possibly be doing, but it uses a lot of CPU and is unable to play anything for the first few minutes after opening.

Also, when this happens, I have a red horizontal bar underneath the clip in the project monitor that says "in point" or "out of point". I am unsure what this means but the red bar ist here anytime it is randomly freezing.

Time to give up. Proxy clips only.

Code: Select all

-acodec libvorbis -vcodec libx264 -qp 28 -preset ultrafast -x264opts keyint=1


Looks much better than default, is fast, and very seekable. Hopefully the memory leak gets fixed someday so no proxy clips are required on higher end hardware.

Silly question - besides rawvideo, what would be the ideal lossless codec to work with inside kdenlive? perhaps if I capture to something better suited for editing, I can have a smoother process with the software that exists.

These issues occurred with huffyuv and x264 with keyint set to 1.

I would suggest transcoding to DNxHD. This is an intermediate format for editing.

thender wrote:Silly question - if I am using the kdenlive nightly build script, would I be using that version of MLT? This is the build-kdenlive.sh file I am using to download & compile new versions of kdenlive.

The build script from http://www.mltframework.org/twiki/bin/v ... s#Kdenlive downloads and compiles many components to kdenlive including melt and ffmpeg. So yes you will be using an uptodate bleeding edge git repostiory version of melt if you have build using the build script.

I got the build script going. Built the nightly with new, fresh everything, but same thing. I wish I knew what it was doing when it ate all the RAM while seeking out of sheer curiosity.

thender,

Did you ever solve this? I have identical problem on a Lenovo W540. 8 core i7, SSD etc.

I have tried Sunab's PPA https://kdenlive.org/download-development with no other versions of Kdenlive, MLT or FFMPEG (or any other dependencies) on my system. Result is the same. No danger of seeking in a hurry lots of CPU fans spinning up, processor usage very high. Probably try building from source next. If that doesn't work I'll downgrade until I find a copy that works or give up.

Best,

James

I have solved this for my own case by following the build script at http://www.mltframework.org/bin/view/MLT/BuildScripts

This has left me with melt 0.9.3 and kdenlive 0.9.10.

Best,

James

I never solved it. I gave up and moved to Windows and bought vegas. Best case scenario, and I do mean best, I could edit at really incredibly slow speed, or at decent speed with ugly proxies that ruined the video. Worst case scenario it crashed randomly driving me completely mad. On the same machine, Vegas can run with tons of tracks and effects with no lag and uses something like 35% CPU. I tried, but the amount of time I was wasting dealing with slow editing and crashing was costing me more than the few hundred bucks I paid for vegas.

I really hope to revisit kdenlive in the future. The interface is amazing, the program looks nice. I just need it to work reliably with higher bitrate clips, and to be able to seek quickly without proxies, but until then, I had to stop punishing myself.

I tried emerging on gentoo, apt-getting on ubuntu, and debian, and building from source on all above distros. I tried the nightly build script as well on all above distros. It always had terrible memory leaks editing high bitrate clips, it'd jump to using all 16 GB of RAM and sit there for minutes. Try to seek from 2:00 to 15:00 in a clip and it would do it again for minutes, and worst case scenario with some builds it would crash all over the place even with proxy clips.

When I saw that multithreaded rendering went away I decided to switch. It now takes 6x as long to do anything because it uses 1 core of a six core processor. Linux was about making more efficient use of older hardware to me, not making six core haswells run like single core Pentium prescotts from 2005. I felt really bad about this because this is amazing stuff and costs nothing, but moving on was eventual since it wasn't getting any better.