[FFmpeg-trac] #3615(ffmpeg:new): -y option affects audio/video skew during screen capture
FFmpeg
trac at avcodec.org
Mon May 5 22:30:21 CEST 2014
#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
More information about the FFmpeg-trac
mailing list