[FFmpeg-user] Audio and video desynchronized in clips.

Leo Izen leo.izen at gmail.com
Sat Mar 26 00:46:42 CET 2011


On Fri, Mar 25, 2011 at 1:00 PM, R. Clayton <rvclayton at verizon.net> wrote:

> I've written a shell script that cuts a media file into a sequence of clips
> using ffmpeg commands that look like this:
>
>  ffmpeg -i failure.mp4 -vcodec copy -acodec copy -ss 00:40:00 -t 00:10:00 \
>    -y clip04.mp4
>

There's two types of seeking in ffmpeg. One is fast seeking, where it skips
to the point in the encoded data, and one is slow seeking, which is when it
decodes the whole block before skipping to the point. Slow seeking is
better, because fast seeking usually causes the audio to be misaligned. You
specify fast seeking by putting the -ss and -t before the -i, and you
specify slow seeking when you put the -ss and -t after the -i, which you
did. The once exception is in -vcodec/-acodec copy. If any of the streams
are set to copying, slow seeking for that stream is automatically disabled
because slow seeking requires data to be decoded first, which stream copy
isn't doing. Pretty much your only option is to decode and recode the
stream, which shouldn't be a big problem if you are using H.264, because
libx264 is the best H.264 encoder available. Other streams like MPEG-4 ASP,
MP3 or AAC should prove a little more difficult and might lose a little
quality on the way, but its the only option for slow seeking.

     Stream #0.0(und): Video: h264 (High), yuv420p, 640x360 [PAR 1:1 DAR
> 16:9], 335 kb/s, 25 fps, 25 tbr, 25 tbn, 50 tbc
>      Metadata:
>        creation_time   : 1970-01-01 00:00:00
>      Stream #0.1(und): Audio: aac, 44100 Hz, stereo, s16, 73 kb/s
>

I can see that you are using H.264, so that's fine, and AAC shouldn't lose
too much quality that wasn't already lost when putting the stream into 73
kbps in the first place, and using libfaac versus ffmpeg's aac should help.


More information about the ffmpeg-user mailing list