I actually contributed to a bug report on this issue a year and a half ago ( https://trac.ffmpeg.org/ticket/692#comment:15 ). Basically, the problem is that using ffmpeg to record from a USB video capture device leaves the audio and video tracks out of sync. Depending on which input you list on the command line first, the sync problem will be different.

Since contributing to that report, ffmpeg has undergone many revisions, and the bug report has been updated to say that the problem was fixed by adding new command line options to the V4L2 indev (-ts default|abs|mono2abs). However, I have no idea what these new options mean or how they're meant to be used. I tried again tonight using ffmpeg to record from the video capture device. While the audio and video aren't as badly out of sync as they were 18 months ago, they're still out of sync.

Clearly, someone thinks this is fixed, leading me to think that I need more magic on the command line. Here's my latest incantation:

ffmpeg  -f alsa -i hw:1  -f v4l2 -i /dev/video0  -acodec libfaac -b:a 128k -vcodec libx264 -b:v 12M -g 1 -preset ultrafast  SYNCTEST.mp4

Adding various -ts options to the line doesn't seem to accomplish anything. I'm using ffmpeg version 2.1.4. Can anyone provide further insights?

Console Output:

$ ffmpeg  -f alsa -i hw:1  -f v4l2 -i /dev/video0  -acodec libfaac -b:a 128k -vcodec libx264 -b:v 12M -g 1 -preset ultrafast  SYNCTEST.mp4
ffmpeg version 2.1.4 Copyright (c) 2000-2014 the FFmpeg developers
  built on Feb 24 2014 08:21:48 with gcc 4.8 (Debian 4.8.2-16)
  configuration: --prefix=/usr --extra-cflags='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security ' --extra-ldflags='-Wl,-z,relro' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --disable-stripping --enable-libvpx --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-librtmp --enable-avfilter --enable-libfreetype --enable-libvo-aacenc --disable-decoder=amrnb --enable-libvo-amrwbenc --enable-libaacplus --libdir=/usr/lib/x86_64-linux-gnu --disable-vda --enable-libbluray --enable-libcdio --enable-gnutls --enable-frei0r --enable-openssl --enable-libass --enable-libopus --enable-fontconfig --enable-libpulse --disable-mips32r2 --disable-mipsdspr1 --disable-mipsdspr2 --enable-libvidstab --enable-libzvbi --enable-avresample --enable-libiec61883 --enable-libfdk-aac --enable-vaapi --enable-libdc1394 --disable-altivec --disable-armv5te --disable-armv6 --disable-vis --shlibdir=/usr/lib/x86_64-linux-gnu
  libavutil      52. 48.101 / 52. 48.101
  libavcodec     55. 39.101 / 55. 39.101
  libavformat    55. 19.104 / 55. 19.104
  libavdevice    55.  5.100 / 55.  5.100
  libavfilter     3. 90.100 /  3. 90.100
  libavresample   1.  1.  0 /  1.  1.  0
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
Guessed Channel Layout for  Input Stream #0.0 : stereo
Input #0, alsa, from 'hw:1':
  Duration: N/A, start: 1394670862.629223, bitrate: 1536 kb/s
    Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Input #1, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 575244.424820, bitrate: 165722 kb/s
    Stream #1:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 720x480, 165722 kb/s, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc
No pixel format specified, yuv422p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x1d1b0a0] using cpu capabilities: MMX2 SSE2Slow SlowCTZ
[libx264 @ 0x1d1b0a0] profile High 4:2:2 Intra, level 3.0, 4:2:2 8-bit
[libx264 @ 0x1d1b0a0] 264 - core 142 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=1 keyint_min=1 scenecut=0 intra_refresh=0 rc=abr mbtree=0 bitrate=12000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=0
Output #0, mp4, to 'SYNCTEST.mp4':
    encoder         : Lavf55.19.104
    Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv422p, 720x480, q=-1--1, 12000 kb/s, 30k tbn, 29.97 tbc
    Stream #0:1: Audio: aac (libfaac) ([64][0][0][0] / 0x0040), 48000 Hz, stereo, s16, 128 kb/s
Stream mapping:
  Stream #1:0 -> #0:0 (rawvideo -> libx264)
  Stream #0:0 -> #0:1 (pcm_s16le -> libfaac)
Press [q] to stop, [?] for help
frame=  436 fps= 30 q=-1.0 Lsize=     706kB time=00:00:14.91 bitrate= 387.9kbits/s dup=0 drop=4    
video:448kB audio:240kB subtitle:0 global headers:0kB muxing overhead 2.682203%
[libx264 @ 0x1d1b0a0] frame I:436   Avg QP: 0.00  size:  1051
[libx264 @ 0x1d1b0a0] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264 @ 0x1d1b0a0] final ratefactor: -25.57
[libx264 @ 0x1d1b0a0] coded y,uvDC,uvAC intra: 0.0% 0.0% 0.0%
[libx264 @ 0x1d1b0a0] i16 v,h,dc,p: 97%  0%  3%  0%
[libx264 @ 0x1d1b0a0] i8c dc,h,v,p: 100%  0%  0%  0%
[libx264 @ 0x1d1b0a0] kb/s:252.03
  • Added console output.
    – ewhac
    Mar 13, 2014 at 0:37
  • What player are you using? Does it seem like the sync is correct with ffplay? The option you referenced is meant to be used as an input option for the v4l2 input: -f v4l2 -ts abs -i /dev/video0 or -f v4l2 -ts mono2abs -i /dev/video0.
    – llogan
    Mar 13, 2014 at 1:36
  • I'm using mplayer2, which has been exceedingly reliable (and I'm used to its keystrokes). I'll re-check with ffplay. -- It's not always obvious where to put the codec- or device-specific options on the command line; I'll try your positioning later this evening but, again, I don't know what they mean or are supposed to do.
    – ewhac
    Mar 13, 2014 at 1:59
  • Just tried using ffplay; the sync problem presents the same as in mplayer2 -- Tried both -ts abs and -ts mono2abs in the position you suggested; no apparent effect.
    – ewhac
    Mar 13, 2014 at 2:57
  • BTW, in the above-mentioned incantation, the video leads the audio by a fraction of a second.
    – ewhac
    Mar 13, 2014 at 3:04

1 Answer 1


The first thing that I noticed is that your camera is delivering yuv422p - which isn't bad in and of itself, but you could try forcing it to yuv420 by adding -pix_fmt yuv420p to your command. (This is nice if you ever plan on displaying your video on anything that isn't linux.)

The second thing that I noticed is that the start times are wildly different - which can often be a signal that things are going to sync wrong.

This is the command line that I used that was able to reproduce your lag.

ffmpeg -f alsa -ac 2 -i hw:0,0 -f v4l2 -i /dev/video0 -r 25 \
       -acodec libfdk_aac -b:a 128k -pix_fmt yuv420p -vcodec libx264 SYNCTEST.mp4

by adding a -force_key_frames 00:00:00.000 I was able to sync them correctly.

ffmpeg -f alsa -ac 2 -i hw:0,0 -f v4l2 -i /dev/video0 \ 
       -force_key_frames 00:00:00.000 -r 25 -acodec libfdk_aac \ 
       -b:a 128k -pix_fmt yuv420p -vcodec libx264 SYNCTEST.mp4
  • Finally got around to trying this, using ffmpeg v2.4.2. Although I swapped the position of the inputs on the command line from your example, it appears to work. Thank you very kindly!
    – ewhac
    Nov 2, 2014 at 4:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.