Using my MTS clips (from my camera) after rendering the project the video has a 3 frame pause where the clips joined, so it doesn't play smoothly. I'm running Manjaro, with Kdenlive 15.12.3. The sound is unaffected, it's just the first 3 frames of a MTS file are all identical.

My problem has already been described by another user exactly in this bug report https://bugs.kdenlive.org/view.php?id=2659 .

Thanks for your time.

This is an old and ugly problem, When i get this I usually move the start point of the second clip (the one being transitioned into) by a frame or two until I get a smooth transition.

Yes it is an old problem, but I'm not sure that it is a KDenLive "bug", as perceived, that can be (easily) fixed, if at all, as it has to do with the way AVCHD.mts is recorded and the way ffmpeg (and so MLT) decodes the contained H264 streams.

If I might illustrate the underlying issue with an example. Here is the GOP structure of the leading sequence of a sample 1080/60i AVCHD.mts clip from my Canon HF-G10 camcorder:

http://i.imgur.com/zd9roTh.png

So that's the normal repeating 15-frame GOP sequence in which the frames are coded - IBBPBBPBBPBBPBB. However, the sequence in which the frames are actually displayed is different. What happens is that the 2nd and 3rd frames (both B frames - green) are displayed before that first I frame, and then the next pair of B frames are displayed before the preceding P frame (blue). So the display sequence goes BBIBBPBBPBBPBBPBBI.... and so on. In this way, the last two B frames of each repeating GOP are always displayed before the the I frame of the next GOP. This "Open" GOP structure allows P and B frames to have multiple references, instead of only referring to the previous frame. What makes that first I frame in the coded sequence ( i.e. for each freshly recorded mts clip) different is that it is always an IDR (Instantaneous Decoder Refresh) frame; this is a special I frame that specifies no frame after the IDR frame can reference any frame before it. This is intended to make file seeking easier and more responsive in players.

What trips up file seeking when decoding with ffmpeg are those first two B frames that are coded after the first IDR frame but are displayed before it. More often than not it will stick on the first B frame until the time-code hits the that first IDR frame. Indeed, if you put an mts clip on the KDenLive timeline, back-up to the first frame and then try advancing frame by frame, it will freeze on that first B-frame for at least two (and sometimes more) "clicks" before the first IDR frame kicks in and the sequence advances normally.

What perplexes me though is that you say that you are seeing these (B-frame) "replicates" in your render and where the clips are joined. Just tested that myself with a couple of 1080/60i.mts clips. I'm now running KDenLive 16.07.70 (from the Master branch) on Kubuntu 16.04 (AMD 64). When I load and join up two mts clips on the timeline and step-through frame by frame, as expected there is an initial stall on the first frame of the leading clip, but on stepping through the join, there is no stalling/frame replication - only a single black frame where the last frame of the first clip should be. Here's what the end GOP sequence of that 60i mts clip looks like:

http://i.imgur.com/Nd6DWPm.png

The last two frames in the coded sequence are B frames, but the last displayed frame is a P frame and it is that frame that gets blanked. Just why that happens, I'm not sure, without further research. All I can say it is another quirk of ffmpeg/MLT decoding and the same thing occurs when using (ffmpeg encoded) DNxHD transcodes of the mts clips. Rendering out to H264.mp4 (using the render preset) at CRF 15 (or any format), that black frame does persist, but I don't see any duplicated or stalls frames at the start of encode or around the join point when playing the files - only the transient single black frame. And likewise, loading the rendered H264.mp4 files back on the timeline, there are no freeze-ups upon frame-stepping from the first frame - and I didn't expect there to be. x264 is encoded rather differently to the way AVCHD/HD-AVC is recorded on camcorders. Here's the initial sequence of that H264.mp4 render:

http://i.imgur.com/Ehi9FDy.png

In this case the display sequence starts on that first coded IDR frame and then proceeds IBPBPBPBP etc. with the next I frame occurring down the line at frame 120. So there are no pesky leading B frames to trip over.

So just why you are seeing these duplicate frames in renders of your joined mts clips is a bit of a mystery, but it has to be related in some way to the decode/seeking behavior I described above. Is it maybe a bug that has since been resolved at MLT level ?

Out of interest, what camcorder were your clips recorded on and in what standards format - 50i/60i, 25/30PF etc ? What were your project settings? And do you see this problem with every clip or just some ? Could possibly be corruption in the original recording.

If lukefromdc's suggestion works for you, all well and good. Personally I'm quite conservative in my use of transitions. Otherwise, best I can suggest is excising a few frames either side of the clip splice points - finicky I know, especially when frame stepping in reverse tends to throw up weird, corrupt frames - again these are purely "seeking" aberrations on the time-line. Or else pre-transcoding your clips to one of the intra-frame intermediate formats (DNxHD, Matroska.mkv) and working with those. That's what I do, except I use lossless UTVideo.avi intermediates transcoded in Windows with a vfw codec, which doesn't produce this dud black terminal frame. No frame seeking issues at all there - smooth as butter.

If you do that (transcode your clips to DNxHD) do you still see these replicated frames in the transcodes ?

Edit: Just tested some other mts clips - 1080/30PF from my HF-G10 and several 1080/60i and 1080/50i sample clips from other Canon, Sony and Panasonic camcorders and I'm still not seeing evidence of the frame replication bug you describe. Only the single black frame at the clip joins.

If you still consider this a KDenLive bug, might be best to add your comment to that existing bug report, given that the last entry (by vpinon) was in back in Nov 2014.

Regarding:

Inapickle wrote:...Rendering out to H264.mp4 (using the render preset) at CRF 15 (or any format), that black frame does persist, but I don't see any duplicated or stalls frames at the start of encode or around the join point when playing the files - only the transient single black frame. And likewise, loading the rendered H264.mp4 files back on the timeline, there are no freeze-ups upon frame-stepping from the first frame

One other thing I've noticed. If I load that H264.mp4 render on the timeline, duplicate it and join the two copies together, two black frames then occur at the join point.

Edit: I've just gone on to test that 1080/60i.mts clip in KDenLive 0.9.10 which I have running on Mint KDE 17.3 (AMD 64). As before, I loaded the clip on the timeline, duplicated it and joined the two copies together. This time there was no stall when frame-stepping from the first frame of the leading clip and neither was there a black frame at the join. But what I did see was the last displayed frame of the leading clip being replicated three times.

Referring back to the coded frame sequence I posted above:

http://i.imgur.com/Nd6DWPm.png

The frame that was replicated was the first of the two terminal B-frames (in the coded sequence), corresponding to the third frame from the end in the display sequence. In other words it was stalling at that B frame and skipping the next B frame and the final P frame. What's more, when rendered out to H264.mp4 (crf15) those replicated frames were still there in the encode. This appears to be exactly the same thing that the chriswere was describing.

However, when I did the same thing with a DNxHD transcode of the 1080/60i.mts clip, the join was perfect - no replicated frames or black end frame at all. A good argument I would suggest for using a using an intra-frame intermediate for editing AVCHD.mts clips.

I must say though that I found the timeline seeking of mts clips a lot easier on KDenLive 0.9.10 than now on 16.07.70. For one thing you don't see these weird aberrant frames when frame stepping in reverse.

Edit: By "aberrant frames", I'm referring to this type of thing:
http://i.imgur.com/NeS7RiW.png

Hi, apologies for the delayed response but I've managed to find a solution. The error does seem to be more with the MTS filetype.

In version 16.12.0 if I right click on the video in the project file list, go to transcode and click remux with MKV, (it takes about 3 seconds on a 10 minute clip), it packages it up as a MKV file which fixes the issue.

Thank you to those in this thread for your assistance.

Glad you found a solution. It's interesting though that you are able generate a re-muxed mkv file from your mts clips using the KDenLive Transcode profile 'Remux with MKV'.

Since my last post I upgraded my Canon HF-G10 to an HF-G30 and now shoot MP4. However, I've retested some archived 1080/30PF and 1080/60i MTS clips from the HF-G10 with KDenLive 16.12.1 running on Kubuntu 16.10 AMD 64. I tried re-muxing the MTS clips to mkv with the KDenLive Transcode > 'Remux with MKV' operation and all it does is create a tiny file with no video or audio stream. And likewise when attempting to remux using ffmpeg CLI - it throws up an error about not being able to obtain the video stream timestamp. I did however manage to remux to mkv using MKVToolNix (and also with Pegasys Smart Renderer in Windows) and testing the files on the KDenLive timeline they behave just the same as the original MTS clips.

What I see now when frame stepping through a clip-join is duplication of the last frame of the leading clip, followed by a single black frame. And stepping back through the join I am again seeing those corrupt frames. So I don't see that anything has changed really. I'm just happy that shooting mp4 avoids these MTS quirks.

Still, if re-muxing to mkv works for you, that's great. Out of interest, what camera model are you recording your MTS clips on ?

You may need a more professional tool like Brorsoft MTS Converter. I have used it for several years to combine MTS files into one. Very professional. Have a try!