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

<p>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.</p>

<p>This is the command line that I used  that was able to reproduce your lag.</p>

<pre><code>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
</code></pre>

<p>by adding a <code>-force_key_frames 00:00:00.000</code> I was able to sync them correctly.</p>

<pre><code>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
</code></pre>

CC BY-SA 3.0
2014-11-02T04:17:51.573Z
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
CC BY-SA 3.0
2014-08-07T16:15:33.250Z
2014-08-07T16:15:33.250Z
denjello
<p>I actually contributed to a bug report on this issue a year and a half ago ( <a href="https://trac.ffmpeg.org/ticket/692#comment:15" rel="nofollow">https://trac.ffmpeg.org/ticket/692#comment:15</a> ). Basically, the problem is that using <code>ffmpeg</code> 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.</p>

<p>Since contributing to that report, <code>ffmpeg</code> 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 (<code>-ts default|abs|mono2abs</code>). However, I have no idea what these new options mean or how they're meant to be used. I tried again tonight using <code>ffmpeg</code> 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.</p>

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

<pre><code>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
</code></pre>

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

<p><strong>Console Output:</strong></p>

<pre><code>$ 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':
  Metadata:
    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 -&gt; #0:0 (rawvideo -&gt; libx264)
  Stream #0:0 -&gt; #0:1 (pcm_s16le -&gt; 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
</code></pre>

CC BY-SA 3.0
2014-03-13T00:37:48.933Z
Added console output.
ewhac
CC BY-SA 3.0
2014-03-13T01:36:34.293Z
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
CC BY-SA 3.0
2014-03-13T01:59:37.120Z
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
CC BY-SA 3.0
2014-03-13T02:57:52.590Z
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
CC BY-SA 3.0
2014-03-13T03:04:43.197Z
BTW, in the above-mentioned incantation, the video leads the audio by a fraction of a second.
ewhac
CC BY-SA 3.0
2014-03-13T19:21:10.443Z
Try: `ffmpeg  -f alsa -i hw:1 -f v4l2 -i /dev/video0 -c:v libx264 -crf 0 -preset ultrafast -c:a copy lossless.mkv` then re-encode it with `ffmpeg -i lossless.mp4 -c:v libx264 -c:a libfdk_aac test.mp4` Does `test.mp4` have better sync? What CPU are you using?
llogan
CC BY-SA 3.0
2014-03-13T20:25:33.013Z
Will try that when I get home. -- The machine I'm running these experiments on is an older one; AMD Athlon 64 X2 4400+ (2.2GHz).  I also use my laptop; Intel Core 2 Duo T7200 (2.0GHz).  However, the CPU load from these captures is negligible. -- Previously I've been using `mencoder` to do the captures, whose resulting A/V sync is fine, but `mencoder` isn't as flexible as `ffmpeg`.
ewhac
CC BY-SA 3.0
2014-03-14T06:18:30.940Z
Just tried your incantation.  Both `lossless.mkv` and the transcoded `test.mp4` still exhibit the sync problem.  --  It *really* feels like a buffering issue (as I detailed in the bug report 19 months ago).  If I swap the order of the input devices, then the video _trails_ the audio by a fraction of a second.
ewhac
CC BY-SA 3.0
2014-03-14T22:09:28.130Z
What if you use one ffmpeg process to capture video and one for audio (start them at the same time) and then mux the resulting files? `ffmpeg -i audio.wav -i video.mkv -c copy -shortest output.mkv`
llogan
<ffmpeg><linux>
Video Capture using ffmpeg (V4L2 indev) Results in Bad A/V Sync
ewhac
# Video Capture using ffmpeg (V4L2 indev) Results in Bad A/V Sync

(Asked by: username_0 on 2014-03-12)

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':
  Metadata:
    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

**Tags:** ffmpeg, linux

> **Comments:**
> **username_0**: Added console output.  
> **username_1**: 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`.  
> **username_0**: 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.  
> **username_0**: 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.  
> **username_0**: BTW, in the above-mentioned incantation, the video leads the audio by a fraction of a second.  
> **username_1**: Try: `ffmpeg  -f alsa -i hw:1 -f v4l2 -i /dev/video0 -c:v libx264 -crf 0 -preset ultrafast -c:a copy lossless.mkv` then re-encode it with `ffmpeg -i lossless.mp4 -c:v libx264 -c:a libfdk_aac test.mp4` Does `test.mp4` have better sync? What CPU are you using?  
> **username_0**: Will try that when I get home. -- The machine I'm running these experiments on is an older one; AMD Athlon 64 X2 4400+ (2.2GHz).  I also use my laptop; Intel Core 2 Duo T7200 (2.0GHz).  However, the CPU load from these captures is negligible. -- Previously I've been using `mencoder` to do the captures, whose resulting A/V sync is fine, but `mencoder` isn't as flexible as `ffmpeg`.  
> **username_0**: Just tried your incantation.  Both `lossless.mkv` and the transcoded `test.mp4` still exhibit the sync problem.  --  It *really* feels like a buffering issue (as I detailed in the bug report 19 months ago).  If I swap the order of the input devices, then the video _trails_ the audio by a fraction of a second.  
> **username_1**: What if you use one ffmpeg process to capture video and one for audio (start them at the same time) and then mux the resulting files? `ffmpeg -i audio.wav -i video.mkv -c copy -shortest output.mkv`  

---

## 1 answers

### Answer by username_2 on 2014-08-07. Score: 3 | Accepted answer

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

> **Comments:**
> **username_0**: 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!  

---

