Read and understand this carefully: the project (video) profile that I have selected is correct and it correctly matches what the video is supposed to be! I expect the frame rate to be 29.97 fps, Nautilus properties report the frame rate to be 29.97 fps (it actually just says 30 fps). I've set the frame rate of the profile in Kdenlive to 29.97 fps before importing any clips - so I know that I'm using the right frame rate in the project for the right frame rate of the video.

If I import a clip, the audio is visibly shorter than the video (there is a period of audio waveform that is flat - a little at the beginning, but most at the end), which to me indicates that the frame rate in Kdenlive is incorrect. I exported the audio of that clip and it came to be 5:28;26, which is what I expect the clip length to be. Moreover, that is exactly the length of the same clip (both video and audio) that I get when I use Cinelerra and there is no period of flat audio waveform at start/end. Cinelerra reports a frame rate of 29.97 for the project profile as well.

This is the weirdest, most annoying thing and its rendering Kdenlive useless to me. I cannot tell though if the problem is isolated to Kdenlive or if it is the case with any program that relies on melt (MLT?).

I even trancoded the clip and forced a frame rate of 30 FPS and then imported it into Kdenlive but got the same results. Even ffmpeg reports that the frame rate is 29.97, so I know that I have the frame rate setting correct!

Please help...

So your source file is a NTSC DVD of a film transfer?

Maybe these might help:

http://www.afterdawn.com/glossary/term.cfm/inverse_telecine

https://trac.handbrake.fr/wiki/Telecine

http://neuron2.net/LVG/telecining2.html

My source are clips coming from a DV tape recorded with a Sony HVR-A1U HDV 1080i video camera. I'm capturing with dvgrab and it's creating .m2t files. I transcoded them to MPEG2 with the intent of using the transcoded file as proxy clips for easier editing but both the original and the transcoded file have this problem. I thought that the frame rate of the original file should be 29.97 fps and that's what everything was indicating.

Thanks for the links. I skimmed them quickly but will read closer. I'm not sure if this is my problem/solution though.

Any additional thoughts? I can post an image later of what I'm seeing, if it will help.

A 1080i camera, then frame rate is 60i not (29.98) unless you are deinterlacing?

Try a 1080i HDV project and see if it resolves your problem. As an aside kdenlive offers a great proxy function, no real need to transcode to proxies outside of kdenlive, it could get a bit messy swapping over for encoding.

My apologies about the links I should have said IF your source is NTSC video of film transfer the problem could relate to telicine but it doesn't. :-)

Well that's confusing to me, because it is my understanding that 60i means 59.94 fields per second and with interlacing that translates to 29.97 frames per second. That follows pretty much everything I've ever read... I'm not deinterlacing; maybe you meant to say fields rather than frames?

I had selected a HDV 1440x1080i 29.97 fps (frames per second) profile. I tried selecting profiles I knew to be wrong and Kdenlive would detect that the profile was incorrect and recommend that I use the HDV 1440x1080i 29.97 fps (frames per second) profile. Yet, even with the right profile, Kdenlive would sometimes say that the frame rate of the clip was something like 36.XXXX frames per second with a message box or sometimes not and I'd have to look at the clip properties to see this. The clip should be 00:05:28;26 long but Kdenlive shows it to be 00:05:29;11. The video and audio tracks are both too long, but the audio has (sometimes) a brief gap of silence at the beginning and always at the end that lasts for 20-15 frames. If I use the Extract Audio feature, the length of the generated audio clips is 00:05:28;26. I have tested this with the original clips that are .m2t, but also tried with transcoded clips to MPEG2 (even forced frame rate to 29.97 in some tests) and I get pretty much the same result; nothing has solved it.

Moreover, Cinelerra doesn't have any issue with the video. A profile of 29.97 fps (frames per second), interlaced, 1440x1080 and I don't have the issue I have with Kdenlive. At this point based on these two things it seems that somehow there's an issue with understanding the frame rate of the video in Kdenlive. I've tried both 0.9.4 and 0.9.6 versions with mlt 0.8.8 and 0.8.9; yet both on 64-bit systems.

If you have some other ideas for how I can troubleshoot this, let me know. I'll post images and samples of things later today.

(I knew that Kdenlive has a proxy clips feature, but my workflow is a little different than Kdenlive can handle right now. Transcoding is not the issue here).

Yes, your correct, fields not 60 frames, I was thinking specifically in 'framerate' typical palance not technically correct and didn't actually say 60 frames per second. ;-)

Basically if you have 60i source with kdenlive then a 60i project is required and then if you want 30p out at the other end you use the force progressive in the render properties rather than using a 30P progressive project to start with, just the way kdenlive / MLT seem to work.

So back to the problem, if you look at the clip properties for one of your clips and you know them to be 60i, what do the clip properties say? If they report 29.98 progressive then try using the overides to force interlaced and top or bottom first.

Maybe ffmpeg is reporting incorrectly to MLT and you need to overide 'force' what you know to be correct.

I've tried forcing the frame rate when transcoding and also from within Kdenlive on the original clip. Kdenlive crashes whenever I try to force the frame rate, so that's been unsuccessful. Forcing the frame rate during transcode also has no effect on Kdenlive. All indications to me are that there is a bug in Kdenlive or the underlying framework (at least on a 64-bit machine; results of 32-bit pending).

Here are some pictures to show what I've been trying to say...

1. The first two pictures show the same clip in Kdenlive and in Cinelerra. Both have the same project profiles and the clip properties in Kdenlive indicate that the frame rate is correct. Yet, the length is screwed up - the video is actually too long - and as a result you can see the audio is screwed up. The frame rate shouldn't have any affect on the clip length - just it's relative playback speed - so there's a bug here!

2. The last three show that Kdenlive is reporting the wrong frame rate for an imported clip when Nautilus and Cinelerra both report the right frame rate. This is must be a bug. Either with Kdenlive or the underlying framework.

I'd try to fix the issue by cutting the end off that has the silent audio but then the video from clip to clip wouldn't match up (would have lost frames) and the audio would be out of sync as well.

Notes:
System Info: 64-bit Ubuntu 13.04, 6 GB RAM, Intel Core i7
Test on and issues seen with: Kdenlive 0.9.4 and 0.9.6 with mlt 0.8.8 and 0.8.9.

I'm going to see if I have time to test it on a 32-bit system to see if that makes a difference.

It'd be great to get this working on my 64-bit system. Plus, I'd much rather use Kdenlive than Cinelerra because the interface and general usability is way better; just this major problem I've been having is crippling.

I can't get the images to upload because of some error: "The selected file Screenshot from 2013-06-18 19:04:16.png could not be uploaded. The file is 79.66 KB which would exceed your disk quota of 1 MB."

Can you provide a short clip to test? As you say maybe underlying problem with MLT or incompatibility with your ffmpeg version. I have HDV media and see no problems with it.

Dropbox is an ideal host for images and video, 5GB free storage, free account.

www.dropbox.com to sign up.

**EDIT**

I see your camera offers: HDV 1080, 60i/30F/24F Recording and Playback, 60i/30frame/sec, 24 frame/sec with 2:3 pulldown switchable, so do you have problems with kdenlive using all of these modes or particular ones, which mode is causing you problems. Note: 24F is an option going back to the links to Inverse Telecine NTSC 29.97 to 24fps.

https://www.dropbox.com/s/5nx7jt3rlk378y6/kam-kdenlive-issue.pdf


This may not be the best test clip in terms of audio levels, but it's what was easy to grab.
https://www.dropbox.com/s/5r1usyvd1wkxhuf/reception-mcburney-001.m2t

I also had a look at your clip, as I had a similar issue with strange framerates with a video recorded with my smartphone.

I added the clip to a HDV 1440x1080i 29.97 fps kdenlive project. The audio thumbnail indeed looks strange at the end of the clip, but I also noticed that the last 24 frames or so the video is "frozen" and that there is silence exactly during that time when the video plays.

Then I cut off those frames and rendered the video as H.264 and added the resulting video as a clip, then the audio thumbnail looks normal and A/V sync seems to be fine too, looking at the violin playing.

Could it be that the only issue really is those duplicated video frames at the end of the clip?

Oh and BTW, ffmpeg seems to have issues with this material:

[mpegts @ 0xd53b80] Continuity check failed for pid 2068 expected 1 got 15
[mpeg2video @ 0xd596c0] mpeg_decode_postinit() failure
[mpegts @ 0xd53b80] PES packet size mismatch
Last message repeated 23 times
[NULL @ 0xd5d540] start time is not set in estimate_timings_from_pts
[NULL @ 0xd77680] start time is not set in estimate_timings_from_pts
[mpegts @ 0xd53b80] PES packet size mismatch
Last message repeated 1 times

Stream #0.0[0x810]: Video: mpeg2video (Main), yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 25000 kb/s, 36.28 fps, 29.97 tbr, 90k tbn, 59.94 tbc

And it actually thinks the frame rate is 36.28 fps.

Yes I concur with dode, ffmpeg has problems with these files, so does MKVMergeGUI with error:

Error: Found B frame without second reference in a non closed GOP. Fix the MPEG2 video stream before attempting to multiplex it.

Suggesting the .m2t files produced by the camera are 'broken' in some way for less forgiving codec implementations.

However using a simple commandline app available from Ubuntu distro called dvbcut, for DVB mpeg2 transport stream cutting and remuxing without reencoding (as long as m2t's aren't trimmed :-) ). http://dvbcut.sourceforge.net/ and a simple batch script, it's possible to very quickly index and remux each '.m2t' file into a '.mpg' container.

Creating a shell script with gedit or similar, saving it as say m2t_to_mpg.sh

for file in *.m2t ; do
dvbcut $file -generateidx $file -idx $file'.idx'
dvbcut $file -batch $file -exp './Out/'$file'.mpg' | $file
done

Give it execute permissions via nautilus properties.

Install dvbcut, which is a small app, create a folder of .m2t's and a sub folder called 'Out', open a terminal in the folder containing the .m2t's and start the batch script with ./m2t_to_mpg.sh and all the m2t's should be indexed and remuxed one by one.

This does double disk space usage but personally I copy files for a project off my RAID archive/backup into a project folder and use those rather than working off original files, so no problem to delete the copied m2t's in the project folder and work with the mpg's. You may disagree.

dvbcut does appear to resolve the issue you're having from the file you gave.

Thanks for the attention to this problem.

I didn't see that the frames were "frozen" over the period of silence; I had checked this and I thought that I say slight movement during this time on several of the clips, but I'll look again to be sure.

I'll try what was suggested here and let you know how it goes. Thanks again.

Well,

I tried what was described here and it doesn't really work for what I need it too. I do agree that using dvbcut appears to fix the video/audio length/frames of the clip, but then when I go to line up/join several clips into Kdenlive, there is a stutter or some sort of audio gap between the clips. It's not the long period of silence that I would have gotten with the .m2t files but it's still some sort of stutter that makes it impossible to have a series of clips joined together to make a nice video.

I resorted to recapturing my video into long files so that I could just trim the start and end off and remove the video/audio and avoid the frames/audio issues in each clip and avoid the stutter when playing from one clip to another. Then I didn't need to do any sort of remuxing or transcoding before editing. Capturing in one large file isn't ideal for what I was hoping to do in terms of my capturing\editing workflow, but it works the best when it comes time to edit.

There is obviously an issue though with ffmpeg/avconv and/or melt when it comes to handling .m2t files because this issue doesn't exist with .dv files that have been captured. Although there are some differences in how these formats it seems like this will need to be resolved in the future as HD file formats are more common. Again, all the issues that I was expericnce with the .m2t clips I have wasn't present in Cinelerra, but I really dislike the way that Cinelerra is setup in terms of editing and manipulating clips. Maybe someday this issue won't exist with these other tools.