Hello,

I'd like to use kdenlive to work with FFv1/pcm_s16le losslessly encoded video. I can playback these files perfectly using e.g. VLC, but playing them in kdenlive stutters.

Is there any way for me to tweak/configure kdenlive's playback performance?

Thanks for any hints :)

Proxies can be created by kdenlive via the config and project settings.

I have to be able to edit the lossless format *as-is* without any proxy - for several reasons (long story).

My point is that the system is actually able to deal with these lossless files without any problems (neither CPU nor disk I/O) - and even kdenlive plays them smoothly *sometimes*, but very often it stutters.

So it seems that kdenlive is not running as performant as it could.

Could anyone shed some light on whether this is a configuration issue, or if program code would have to be changed in order to improve this?

I'm intrigued as to what reason(s) that your editing must be done with a lossless format *as-is* and that a decent proxy will not surfice, could you elaborate?

Kdenlive does not have access to video hardware acceleration that VLC does. This may make a difference, though I'm not sure VLC would be able to accelerate FFV1 anyway.

Have you made sure that you video size and the project frame sizwe settings match?

Are there any effects on the timeline?

What is the resolution and pixel aspect ratio of the footage?

Is there a difference between playing the video as a clip and playing it on the timeline?

Have you checked that Kdenlive isn't rendering thumbnails at the same time as you're trying to play?

Not sure if the OP is confused over kdenlives proxies, they are just a stand in, a 'proxy' for editing, not like suggesting transcoding to a 'visually' lossless codec like ProResLT or similar, encoding is done from the lossless ffv1's added.

If ffv1 lossless is ESSENTIAL for editing '*as-is*' then why not create a quarter size ffv1 proxy, kdenlive gives the ability to create our own proxy encoding settings and what point is there editing say HD ffv1 lossless at full resolution in kdenlives Project / Clip Monitors, they are a fraction of the size of a HD display, unless doing editing at full resolution on a seperate screen? :-)

Sounds like OP confusion over what a 'proxy' is, it's not a transcode to more lightweight format to encode from. Maybe wrong but then maybe OP has gone anyway.

Heck does Premiere CS6 with it's Mercury Engine even manage editing HD lossless ffv1 in realtime? :-)

@yellow:
Sorry for not replying earlier, but I didn't receive any mail notifications for this thread :(

The reason why I want to be able to work with the FFv1 directly (without necessity for proxies), because I have to edit hundreds (literally) of videos with kdenlive. We're using FFv1 as our archiving format of choice, and I am trying to avoid any unnecessary processing step whereever possible, because with that amount of videos it adds up :)
btw: We're currently only working with SD-material.

About Premiere and others:
The reason why we chose kdenlive over any other editing system is that it's based on FFmpeg's libraries, therefore we could already use FFv1.3 (although not yet officially released), because FFv1.3 supports multithreading and we can play full-HD material losslessly in realtime. But that's future-talk... :)


@marija:
Wow! that's great news!
I'll give that a try ASAP.

peter_b, many thanks for the info.

marija, useful to know, avi is a poor container for sure and one to avoid whenever possible. kdenlive ffv1 render and transcode profiles use mkv already.

@Marija:
You're right! I've tried it with .mkv and .nut - as well as with cutting the long avi into small files with 1500 frames each (="minute segments").
All 3 variations don't suffer from the freezing/stuttering.

The NUT duration isn't shown correctly, but that might be a different issue.


@Yellow:
I know that AVI is a poor container, but for long-term archiving this "poorness" also means that it's simple. In practice, I'd say that AVIs are at the moment *the* most interoperable container for plain videos.

As it seems to be an issue with files >2GB (and something with OpenDML implementation?), I'll open an issue on kdenlive's bugtracker.

@peter_b, I was not aware you were using AVI container for ffv1 nor was I critizing anyones choice. That's their choice based on their needs, including delivery target and device compatibility.