Dear developers,

first of all: Thank you for your time and efford to make kdenlive what it is - a great video editor.

I wonder if my understanding of mlt and ffmpeg tasks is correct: mlt is used to render the frames and ffmpeg to encode. Is that correct? If so, I have a feature proposal.

Last week I took a look at cinelerra-gg that has a cool feature: Pipe rendering. The user creates a named pipe (mknod /tmp/pipe.raw p) and then renders his project in a raw format (e.g. yuv, rgb) to that pipe by choosing the pipes name as filename. cinelerra-gg complains that the file is already there and if you choose to overwrite it, it simply waits until a consumer reads from the named pipe. You will do that by

Code: Select all

ffmpeg <options> -i /tmp/pipe.raw

.
In the <options> you now can use the hardware encoding from ffmpeg. A 720p input file has been rerendered (without changes) with 220fps and a conversion 1080p to 720 with material from my camcorder (with 17MBit/s AVCHD) came to about 100 fps. I will create the 220fps scenario in kdenlive today and check how long rendering to "rawvideo" with destination /dev/null takes (otherwise my tmpfs will run out of memory). So this was the cinelerra-gg world.

I tried that named pipe scenario in kdenlive and unfortunately kdenlive overwrites the pipe after saying the filename already exists - overwrite? (Well and in fact, it did what I told it to do ).

So, here are two feature proposals: If ffmpeg is used for encoding, it would be great to be able to additionally pass ffmpeg options to the render dialog for encoding. Or if rendering to a named pipe, do not delete the pipe when rendering starts.

If encoding is done with hardware acceleration, video and audio have to rendered seperately and then muxed. Maybe kdenlive could do that in one workflow (invisible for the user) later. First I am curious if hardware encoding works, soon.

Thanks for your time, again!
Achim

Just checked the render time with rawvideo. It was quite disappointing to see that a 23 second 720p clip with 5.3MBit/s takes 18 seconds to render. So I guess the ffmpeg pipe for encoding mp4 is a good idea, when rendering will be significantly faster. Bummer!