Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-02T04:17:51.573Z
Answers.Text: 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!
Answers.UserDisplayName: ewhac
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-07T16:15:33.250Z
Answers.LastActivityDate: 2014-08-07T16:15:33.250Z
Answers.UserDisplayName: denjello
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-13T00:37:48.933Z
Comments.Text: Added console output.
Comments.UserDisplayName: ewhac
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-13T01:36:34.293Z
Comments.Text: 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`.
Comments.UserDisplayName: llogan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-13T01:59:37.120Z
Comments.Text: 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.
Comments.UserDisplayName: ewhac
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-13T02:57:52.590Z
Comments.Text: 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.
Comments.UserDisplayName: ewhac
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-13T03:04:43.197Z
Comments.Text: BTW, in the above-mentioned incantation, the video leads the audio by a fraction of a second.
Comments.UserDisplayName: ewhac
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-13T19:21:10.443Z
Comments.Text: 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?
Comments.UserDisplayName: llogan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-13T20:25:33.013Z
Comments.Text: 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`.
Comments.UserDisplayName: ewhac
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-14T06:18:30.940Z
Comments.Text: 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.
Comments.UserDisplayName: ewhac
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-03-14T22:09:28.130Z
Comments.Text: 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`
Comments.UserDisplayName: llogan
Tags: <ffmpeg><linux>
Title: Video Capture using ffmpeg (V4L2 indev) Results in Bad A/V Sync
UserDisplayName: ewhac
ThreadText: # 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!  
  
  ---
  
  