[FFmpeg-trac] #3615(ffmpeg:new): -y option affects audio/video skew during screen capture

[FFmpeg]

#3615: -y option affects audio/video skew during screen capture
---------------------------------+-------------------------------------
             Reporter:  grepfor  |                     Type:  defect
               Status:  new      |                 Priority:  important
            Component:  ffmpeg   |                  Version:  2.2.1
             Keywords:           |               Blocked By:
             Blocking:           |  Reproduced by developer:  0
Analyzed by developer:  0        |
---------------------------------+-------------------------------------
 Example: On my system, the following script works fine and consistently
 renders normally synchronized audio and video:

 {{{
 ffmpeg  -f alsa -ac 2 -i hw:0 \
         -f x11grab -r 30 -s 1600x900 -i :0.0 \
         -acodec mp3 \
         -vcodec libx264 -preset ultrafast -threads 0 \
         -f matroska -y ofile.mkv
 }}}

 However, removing the **-y** option -- and assuming that a file named
 `ofile.mkv` already exists, so that ffmpeg asks whether to overwrite it --
 results in skew between audio and video.

 The observed skew seems to be roughly equal to the time it takes for the
 user to respond to the //File exists. Overwrite?// question.  This
 suggests that the source of the problem may be that the audio timestamp is
 being initialized prior to the //Overwrite?// question and the video
 timestamp initialized after the user response.  Just guessing.  In any
 case, omitting **-y** produces gross skew effects, and is 100%
 reproducible on my system.

 Logfiles obtained using the **-report** option are attached, one for each
 case (with and without **-y** option).

 **NOTE:** This ticket was filed with priority "important" because during
 my own investigation of the issue, I came across a large number of reports
 by others also stumped by A/V skew peculiarities when attempting aud+vid
 screencaps using `ffmpeg`. Many were frustrated at being unable to get any
 of the (numerous) cargo-cult 'recipe' commandline approaches to work.  A
 few of the recipies do explicitly specify using **-y**, but I didn't see
 any  explanations as to why it was necessary, and it seems (at least to
 me) extremely counterintuitive that that option should have any such
 effect.  In short, aud+vid screencap seems like a not-uncommon application
 of `ffmpeg` and fixing this sooner rather than later may help quite a few
 people avoid tripping over the same issue.

 Just my 2c, and perhaps exaggerating the need for priority. Obviously re-
 prioritize as you see fit.

 NOTES:
   0.  Demo system was Arch linux, synched to repos about 2 days ago.
   1.  Effect has been observed using **mp3** and **pcm_s16le** audio
 codecs.
   2.  Have not tried it with video codecs other than **libx264**.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3615>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker