project file structure


I'm new to this forum.
So first of all I want to say: "THANK YOU FOR KDENLIVE!" :-)

It's the single most usable video editor for Linux.
I know there are others but either they are too subborn to
be called "intuitive" or they lack certain functionalities.

I admit that also Kdenlive has a number of issues where it
can be improved but it has (IMO) much less issues than all
other available programs.
But enough of the flattering stuff ... ;-)

I'm writing this post for another reason.
I'm currently at the beginning of a project involving several
videos (composed from other videos), slideshows, computer
generated grafics and some animated DVD menus.

I just finished the first video (using Kdenlive of course).
During the process Kdenlive messed up my project file
three times and was unable to load it properly afterwards
telling me about invalid producers or simply dropping clips
from the time line and so on.
I managed to rescue my work each time by editing the project
file manually.

While doing this I notices something that I want to ask here.
(Maybe it's just me not understanding the full logic behind it.
But maybe it's somthing that should be improved.)

I have exactly 7 media files involved in the first video. It is
4 movies and 3 sound files. Some clips in the time line are
parts from the movie files where I stripped off the sound or
sometimes I took only the sound of a movie dropping the pictures.
(I assume these are normal use cases for video editing.)

This means from my understanding that I have 7 "producers" of
clip material (no matter if video, audio or both) and everything
in the time line should only refer to the producers as parts of
But when I look in the project file I see 22(!!!) producer
sections inside the section (not counting the default
"black" producer).

Why is this?
Well, I generally know why. It's for sure the way I edit the
video sequence. There are certain actions in the editing
process that create a "producer" in the project file (beside
adding media files).
My question is: Why are there "producers" created with other
actions than adding media files?
It seems completely unnecessary and error-prone to me.

Some of these producers were obviously created for clips
without sound or clips with sound from a video but without
pictures. Why?

I think this structure leads to redundancy and confusion when
loading the project file. It would be better to have only ONE
producer section inside for each media file in the project.
All mlt.playlist.entry sections should refer to these solitary

I edited my project file following this rules and it worked
every time. (Means Kdenlive and Melt can handle it this way.)

In my opinion the mlt.producer should not know if the media
file contains only audio or only video or both. This information
should be part of the mlt.playlist.entry section because the
user can change these parameters for every mlt.playlist.entry
in the GUI separately.

I hope my questions and remarks are understandable. In case of
questions I will try to elaborate.


As you learned, it was supposed to work like you think with only 7 producers shared across all cuts.

The devil is in the details. In reality, the way audio decodes within the avformat producer and is delivered into MLT frame objects means there is some buffer of audio samples for the next frame object left in the producer. These remaining samples are due to audio compression standards using chunks (they call them frames, but they are not like video frames). So, to decode audio for one video frame means that often there are remaining samples for the next mlt frame. Then, when a cut from a clip is combined with another cut from the same clip and mixed to do an audio cross-fade, then a shared producer can feed the wrong set samples into the mlt frames and produce incorrect results.

In short, it used to work this way, but a bug report made us change it. After long consideration of how to fix this in MLT, it was easier to just make each shot be a separate producer.

Thanks for the explanation.
I think I understand now why it works this way (I had to read your answer twice though :-) ).