Audio/Video Sync Drift
Page 1 of 1 (13 posts)
Tags:
None
Registered Member 
|
I seem to be having a problem with audio drifting out of sync with video. Videos assembled in the editor play back fine in the timeline, but acquire drift in the final rendered output. The final video starts out with all elements in sync, but slowly drifts out of sync, until there's about half a second gap between audio and corresponding video. All audio drifts together -- that is, all audio tracks remain in sync with each other, but drift relative to video imagery.
I managed to create a very simple test case that reproduces the problem -- a single video file (with a single audio effect) and single audio file. Vital Stats:
melt 0.9.0 ffmpeg 1.2.3 Debian 'unstable' 32-bit Video file (captured from video grabber using 'mencoder', AVI container):
audio track: PCM 48KHz 16-bit stereo
The last time I had this consistently happen, it had something to do with the handling of AVI files. I was able to "fix" it by ripping the audio out of the AVI file into its own separate track, then group it with its original video track, and mute the video track (yes, a pain in the neck). However, based on an earlier effort, this technique no longer appears to work. Using one of the kdenlive nightly builds yields the same results. Rendering using a different codec combo (WebM) also results in drift. I can upload the project file for reference once I get home. In the meantime, anyone have any hints on where to look? Any further vital stats you need? |
|
Registered Member
|
Now that I'm home, I can provide more concrete detail on my setup.
And here's some info about the raw media assets:
I misstated the video resolution before; it's actually 720x480 (good ol' non-square NTSC pixels). |
Registered Member
|
No errors? Are you using any audio filters? |
|
Registered Member
|
Nope, 'melt --version' shows no errors after the version number (just copyright info).
In my test project, I have a keyframeable volume effect on the video track, with no keyframes yet (so basically a flat gain). In the final project, there's a bunch of volume adjustments throughout the timeline. |
|
Registered Member
|
I don't know what's causing the sync drift. Am willing to brainstorm with you. Maybe we can hack out a solution. So please humor me if I suggest something you've already tried or doesn't make sense. There's a theory bubbling in my head that the video and audio are getting out of sync in the encoding process due to an internal timing error. E.g. like the H.264, due to its ability to run on multiple cores, but the AAC encoder doesn't creates a bottleneck. Perhaps switching to a single processor will help--THREADS=1.
Q. Does the problem occur in all your video players.? My favorite player to testing video playback is ffplay (part of ffmpeg). You run it from the command-line Q. Mediainfo is my favorite video and audio diagnostic tool. Do you use it? It's output may provide us with additional clues. Q. Is the video ahead or behind of the audio tracks? Q. Have you tried rendering to a lossless format? Then testing that files' A/V sync? Afterwards transcoding that output with ffmpeg on the command-line or using HandBrake to your desired output. |
|
Registered Member
|
Seems really unlikely, but it's easy enough to try. I'm running that render now. I primarily use mplayer2, but it shows up in ffplay as well. Well, hmm. Here's some info from my test render with drifting sync (-full output). Very interesting difference between reported video duration and audio duration -- it's about the amount of observed drift at the end of the video:
By the end of the video, the audio is leading the video by about half a second. I did try rendering to WebM, which uses totally different codecs, but got the same sync drift. I'll try an uncompressed render once this single-threaded render ends. |
|
Registered Member
|
I agree. I wonder how that happened? It's like the video is being slowed down due to an extra 12.797 frames! |
|
Registered Member
|
Single-threaded render complete. Sync drift still there. 'mediainfo -full' has this to say about the resulting file. Audio and video durations are still off by about 0.4 seconds:
BTW, does anyone know what MLT's "timebase" is? My original video capture also has a difference between audio/video durations (about 0.5 seconds difference). I'm wondering if MLT is seeing the differences in duration and thinking to itself, "Self, AVI files are almost never written correctly, so I'll believe the audio duration and squash/stretch the video to match it." Hmm... I wonder if I could deliberately kluge together an AVI file with this property, and see how MLT reacts to it? |
|
Registered Member
|
Just got home to check my uncompressed (DV NTSC 4:3) render. It's also got the same sync drift.
|
|
Registered Member
|
I empathize with what you're going through.
I thought of something else you want to try. Try transcoding with Handbrake to resolve that .4 second drift in the source footage. In my experience Handbrake is one of the best transcoding engines around. It automatically solves a lot of problem videos automagically. Unfortunately, I don't see any audio drift correction options. |
|
Registered Member
|
Just for the hell of it, I tried re-rendering the test video on my 64-bit laptop (my desktop is running 32-bit). It took about 40% less time to render (!!!), but the sync drift is still there.
The situation is such that I've been checking out other video editing packages. In every case, I'd be trading one set of warts for another. So I'd like to figure out why Kdenlive is having this problem. Will keep experimenting. BTW, how does one file a formal bug? I'd really like to engage an actual developer... |
|
Registered Member
|
I managed to solve the immediate problem with a rather ugly, brute-force method.
I ripped the soundtrack from the out-of-sync video into its own file and loaded it into Audacity. I then uniformly stretched the entire track by 0.5 seconds (the "Change Tempo" effect lets you do this). Using an only slightly convoluted 'ffmpeg' command, I then replaced the old soundtrack with the newly stretched one. Poof! everything's in sync now. This is obviously a hideous kluge, and I'd like to see Kdenlive not have the problem in the first place. Where do I file a bug? Who do I work with to root-cause this? |
|
Registered Member
|
I'm glad you found a work-a-round.
ffmpeg is an awesome tool. I store all great command-lines in Google Keep. I hope to become an ffmpeg pro one day. |
Page 1 of 1 (13 posts)
Bookmarks
Who is online
Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot]
