I'm working on a project with a separately recorded audio track and two video tracks; one from a Nikon D800 and another from a Panasonic Lumix DMC-TZ10. Thanks to the audio-based track alignment, getting it all to sync is now an easy process -- thanks to the developers for adding this feature!

I use proxying to speed up the editing process, but I have a problem when rendering to file from the originals (the same problem is also visible when disabling the proxy clips, btw):

When I clip INTO footage from the Panasonic (MTS AVCHD Lite format), kdenlive does NOT automatically go back to the previous I-frame to properly calculate the first frame to be used; it starts with a (gray) frame and uses only the B-frames that I clip into -- until it gets to the next I-frame. The same happens if I transition into a clip from the Panasonic. The result is pretty weird, as you might be able to guess...

I use a few color grading effect on the tracks (White Balance and Gamma -- needed for "color grading"), and only simple (dissolve) transitions.

There are no problems clipping into the D800 footage in the same way.

Am I doing something wrong? Or could this be an unfortunate bug?

I know I could just transcode to some other suitable format, but I'd rather not if possible, and just use proxies for the editing.

I have been doing something similar before with the same Panasonic, and didn't have problems then, as far as I remember, so any hints or ideas would be helpful.

Thanks in advance,


-- Per.

NB: For the record, I'm running Ubuntu Studio 13.04 using the latest stable versions from sunab's repo (0.9.6).

Seems like there is an easy way to "provoke" the problem: If I import a (single) clip into an empty project and drag it to the timeline at some position, and then offset the inpoint one or two pictures to the right, it will produce a grey picture until the next I-frame is encountered, every time I use the Panasonic camera -- i.e. it is not using the preceeding I-frame to calculate properly the first picture.

However, if I remux the AVCHD Lite MTS stream to a MKV container like this:

for f in *.MTS; do \
ffmpeg -i $f -scodec copy -acodec copy -vcodec copy -f matroska `basename $f .MTS`.mkv; \
done

and then use the matroska clips instead, it works as expected and renders correctly using the I-frames.

So at least there is a workaround, albeit a bit cumbersome... and I guess the problem is then more like a minor bug for the MTS rendering (in melt/ffmpeg?)

I've observed the same issue when dealing with MPEG-2 files, so I think it's a limitation in MLT.

@ewhac: Good to know it's not only a local problem here on my machine.

I'm wondering, though, if it would be a limitation or "just" a bug in MLT. As mentioned above, re-framing to another container format (MKV) seems to remove the problem, although the video I and B frames are not changed. So apparently sometimes (MKV) MLT figures out it needs to go back a little to find the preceeding B frame and at other times (MTS, MPEG2-based) it doen't.

Do you happen to remember which container format your MPEG2 files were in?