FFmpeg convert video w/ dropped frames, out of sync

3

1

I recorded a video using Bandicam with the MJPEG encoder to get the least amount of lag. Now, I am trying to convert that massive file to a h264 avi using ffmpeg. I know there are dropped frames in the video stream...more than 100 in the first two minutes, which I assume is simply because Bandicam dropped some when it couldn't keep up. So, when I convert the file to h264, the video and audio are out of sync, and appear to be more and more out of sync as output video progresses. Here is my basic command in ffmpeg:

ffmpeg -i "C:\...\input.avi" -vcodec libx264 -q 5 -acodec libmp3lame -ar 44100 -ac 2 -b:a 128k "C:\...\output.avi"

I have tried EVERYTHING I can think of including:

-itsoffset [-]00:00:01

Tried this before and after input file. This doesn't work because as the video progresses it becomes more and more out of sync.

-async 1

Doesn't work.

-vsync 1

Doesn't work, but it does show dropped frames being duplicated.

Two inputs of same file with mapping using -map 0:0 -map 1:1. Doesn't work.

The source plays just fine. Any ideas how to convert it with ffmpeg and keep the audio and video synced? Thanks.

preahkumpii

Posted 2012-06-13T08:49:26.840

Reputation: 133

The reason why the synchronization gets worse as the file progresses, is because there is an difference between the length of the video, and the length of the audio. If they were the same length, the offset would fix this. Does the original file have the same issue? You may have to demux the original manually, and convert the audio separately from the video, and then remux into the AVI. – Bon Gart – 2012-06-13T08:57:20.813

OK, I think I can do that. Is is possible that the audio 'dropped frames' as well (I know it doesn't have frames, but you get the idea)? – preahkumpii – 2012-06-13T08:58:57.093

It really depends on whether the PTS (presentation timestamps) are still correct, because only then synchronization would even work. I guess it's hard for the encoder / muxer to even realize there's a dropped frame and where to put the audio in between, so I would go with what @BonGart said and see where you can go from there. // Audio has frames too ("samples"), but I think it's unlikely there are dropped samples. – slhck – 2012-06-13T09:00:58.250

Maybe you can also post the full, uncut console output from your FFmpeg command. – slhck – 2012-06-13T09:05:02.703

Just demuxing the original and looking at the lengths in any info tool should give you a heads up.... providing the audio isn't off in the original. – Bon Gart – 2012-06-13T09:33:43.127

That was it; that is, I extracted the video and audio separately, with video -vsync 1 set to make sure the frames were filled in. Then, I made a new file with the two separate files using -map 0:0 -map 1:0. @Bon Gart pls put a formal answer so I can mark it answered. – preahkumpii – 2012-06-13T10:02:02.037

@preahkumpii done... unless you want me to flesh the answer out more. – Bon Gart – 2012-06-13T22:19:23.837

Answers

5

It may have dropped frames if they were duplicates, if the source plays fine then your problem is more likely related to the fact that AVI containers don't handle VBR encoded formats very well (h264 in particular doesn't play well with AVI). I'd recommend starting by dumping the video to an uncompressed AVI for testing as it's the most consistent format to encode from

ffmpeg -i input.avi -acodec copy -vcodec rawvideo output.avi

Then, assuming that plays in sync you should try doing a straight codec copy and remux the source into a different format, i.e.:

ffmpeg -i input.avi -acodec copy -vcodec copy output.mkv

MKV will usually handle just about anything you stuff in it without a problem. I even hide some encrypted zip files in various mkv videos on my computer since you can encode file attachments in MKVs. So if either of that works without sync issues then try the same thing but re-encode the video or audio, but only one or the other to start and keep the container format consisten so you know where the issue lies. i.e.:

ffmpeg -i input.avi -acodec copy -vcodec libx264 output.mkv

or

ffmpeg -i input.avi -acodec libmp3lame -vcodec copy output.mkv

Try to make each test conversion as simple as possible, i.e. don't change bitrate/sample rate, use the example parameters I listed first. After each one you'll be one step closer to knowing exactly what you can and can't do. If you have to have h.264 I'd recommend going with an mp4 container as it's far more compatible than avi, on the other hand if the requirement is an avi container then I'd recommend wmv3 or msvideo1 for video as they would be the most likely to encode properly.

Justin Buser

Posted 2012-06-13T08:49:26.840

Reputation: 1 147

Having more issues that your method seems to help a bit. I haven't converted it to rawvideo yet, b/c it takes so long, but I tried to convert to mkv and mp4 containers. MKV crashed with this [matroska @ [...] can't write packet with unknown time stamp. av_interleaved_write_frame{}: invalid argument. MP4 said [mp4 @ ...] pts has no value. My original command was ffmpeg -i vid.avi -i aud.mp3 -vcodec copy -acodec copy -map 0:0 -map 1:0 output.mkv[mp4]. I first extracted the video and audio separately and did -vsync 1 with video when I did that to ensure I got a constant 24 fps framerate. – preahkumpii – 2012-06-15T06:05:35.790

it appears that just changing the container to mp4 made the conversion from the original file work correctly. I had no idea the container was that important. – preahkumpii – 2012-06-15T06:18:46.710

It's really situation dependent, I find that the best way to trouble shoot that kind of thing is to incrementally try minor adjustments to my method until I find the point at which it works so I can better understand what's going on. – Justin Buser – 2012-07-15T14:57:50.880

0

Almost always, when audio and video are out of sync and difference between the two get progressively worse over the course of the movie, especially after a conversion, the issue is one where the audio and video components were of a different length. As was observed in this instance, this happened because video frames were getting dropped, but the audio was relatively untouched during the conversion.

At times like this, it is best to first check the source movie to ensure that the audio was indeed in sync. If it is, then demux the movie, and deal with the video and audio components separately.

Bon Gart

Posted 2012-06-13T08:49:26.840

Reputation: 12 574