When playing a clip or a project timeline in kdenlive, the audio/video starts in sync, but drifts out of sync (over a few seconds) until the video is about 1/2 second ahead of the audio. Once it's out of sync by that amount, the problem doesn't get any worse--it just stays out of sync by about 1/2 second. Stopping and starting playback causes it to sync up again (whereupon it drifts again). Other details:

• The same thing happens using mlt directly from the command line.


• This happens with all formats which use ffmpeg, (libdv is not affected).


• Rendering works perfectly.


• Occurs with both a pro firewire audio interface connected to jack, and a built-in intel sound card using alsa.


• Downgrading mlt/kdenlive/ffmpeg a version (0.8.6/0.9.2/1.1.2 respectively, I believe), and trying the lastest from git didn't help.


• Other video players (mplayer, vlc) have no problems. Neither do other editors (cinelerra, pitivi)

Now, I rather suspect this isn't a general bug in kdenlive or mlt, as it affects almost everything and would have been noticed. Searching for solutions hasn't really turned up anything--most reported sync problems seem render-related--so I was wondering if anybody had ran into something similar or had any ideas as to what might be wrong with my system!

I'm using mlt 0.8.8, kdenlive 0.9.4, ffmpeg 1.1.3. System is a core 2 quad (Q9550), with an Nvidia 7900GS (binary blob drivers), running Arch Linux. This system previously (a year or so ago) ran kdenlive well with no problems. I was inclined to blame ffmpeg, but a nearly identical software config doesn't have a sync problem on a second machine (a old laptop which isn't fast enough to do any real editing.)

Any help would be appreciated!

A good description of problems and distro but no mention of source material. What are you using? Is it particular formats or all formats and codecs you've tried. Is it HD material? If so have you tried proxys?

Kdenlive and MLT currently don't use vdpau unless compiled in as an option, don't know what Pitivi does in that regard, but it may be the reason you see differences in performance.

Check out the last post on this thread, it may help:

http://www.kdenlive.org/forum/project-plays-av-sync-kdenlive-rendered-version-goes-out-sync

And this one, last post by gRufty.

http://www.kdenlive.org/forum/stuttering-preview-and-all-memory-taken-while-rendering-after-update-solved

If you're using a Ubuntu based distro then why not use sunabs PPA? or Dan Dennedys daily builds?

http://kdenlive.org/download-development

Getting the ffmpeg build wrong compared to which ever MLT was tested and compiled against is a big source of frustration, your render crashes previously was probably due to the same reason.

Yes, I've had that happen for a few months ago, but as I'm using latest git builds from sunabs PPA those sort of bugs from library incompatibilities get fixed quite quickly. Sounds like problem lies in ffmpeg / libav. If you had problems trying to update ffmpeg as you mentioned in an earlier post then stands good chance that's where your sync problem lies like the other 'sync problem' threads pointed to.

Have you tried a PPA or Meltytec build of kdenlive, MLT etc?

I made an inadvertent discovery the other day that may be relevant to this topic.

A while back, I wanted to create a video where events in the video were synced to beats in the music track. To that end, I tried playing the music clip in the clip preview window, and then tapping on the '*' key in time with the music, which should have laid down guides on the beat points. However, it became obvious after a few seconds that the guides were drifting and landing in the wrong place.

Last week I tried to more precisely quantify this problem. So I launched Audacity and created a one-minute-long click track at 120bpm. This had the advantage of having audio pulses that would be extremely visible in the editor timeline, and any misalignment between the pulses and the dropped guides would be immediately apparent. I imported the click track as a clip, played it in the clip previewer, and started tapping on '*' for the length of the clip. I then dragged the clip to the timeline to have a look at it.

The guides started out in sync, but soon drifed to a point about 0.25 seconds out of sync and stayed there. So it looks like some sort of playback buffering is causing some bits of the program to run ahead of others.

But here's where it gets interesting. I opened Kdenlive's Configuration preferences window, and clicked on Playback. In there are several options for setting up how Kdenlive renders to the screen. On a whim, I enabled the one labelled, "Use OpenGL for video display," restarted Kdenlive, and tried the same thing again. (I knew I could get away with this because that particular machine has an NVIDIA card.)

This time... the guides landed in perfect sync! There were occasional one- or two-frame errors, but I put that down to my own poor rhythm hitting the button.

So, at least for my experiment, on my machine, there's something about what Kdenlive picks for video display by default that's drifting out of sync. Maybe you could give that setting a try and see if things improve.

have you tried a daily build, this solved al the problems i was having, the daily builds you just uncompress to a folder and run it from there no install,

Apologies for the delay in following up; I thought I'd subscribed to the thread but it seems it didn't work...

> ...no mention of source material.... Is it HD material?

I've tried everything I could think of. MPEG2 from a camera, MPEG2 from a dvd, h264, flvs downloaded from youtube, big buck bunny, various audio sync test videos, etc. I've also converted source material into a variety of formats in an attempt to pin the problem down, but all to no avail. I haven't systematically tried all supported formats, but must have attempted 10-20 different combinations at least. HD/SD doesn't make a difference either. Neither do proxy clips. Is there a recommended "best" format which should be tried? For the record: 200x113 MJPEG exhibits the problem.

My video card doesn't support vdpau (that's 8000+ only), so it can't be a factor.

I just tried again with the latest kdenlive, mlt, and ffmpeg from git; no difference. (And it causes a bunch of other nasty problems like kdenlive not being able to detect clips' frame rates. ffmpeg git doesn't play very nice with much of anything, it seems. By the way: ffplay does work fine.)

Also tried using OpenGL output as suggested - no apparent improvement. But it also causes massive frame dropping, so it's hard to really tell. But the fact that this doesn't occur with dv files makes me think the problem isn't with the display. The x11 setting doesn't help either.

ewhac: do you have the problem with video playback, too? Or just with the interface?

Not sure if the problem described here:
http://www.kdenlive.org/forum/project-plays-av-sync-kdenlive-rendered-version-goes-out-sync
Is the same or not. It sounds like the sync problem there was between separate video and audio tracks. The problem I have occurs even when just playing a single clip in the clip monitor, with a otherwise blank project.

Are the daily builds statically compiled? If so, might give those a shot to see if this is all down to some weird library interaction.

Beginning to suspect that this is a weird regression in mlt that only affects a few system configurations. If I get some free time, I plan on trying to bisect mlt and ffmpeg to see if I can track down the source of the problem and file a proper bug report. (Since I figure filing one as-is will probably just result in a "won't fix, can't reproduce") Is there a good way to determine which versions of ffmpeg are recommended for which versions of mlt and kdenlive? (Other than hunting for clues in the commit messages, of course... ;))

UPDATE

Tried all that, it's not a problem (directly) with either mlt or ffmpeg. Still has happens as far back as ffmpeg 0.7 and mlt 0.6.0. But got to looking at the SDL code, and setting the buffer size in .asoundrc to 2048 reduced the problem drastically. Setting it to 512 eliminated it, to all appearances, at the expense of the odd buffer underrun. Guessing the problem was caused by some change in the kernel audio card driver to how audio buffers are handled or some such. Curious if changing the buffer size helps anybody else with a similar problem.