Opened 4 years ago

Last modified 4 years ago

#3615 new defect

-y option affects audio/video skew during screen capture (alsa+x11grab)

Reported by: grepfor Owned by:
Priority: normal Component: ffmpeg
Version: 2.2.1 Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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:

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

Attachments (2)

log_without_-y.txt (169.5 KB) - added by grepfor 4 years ago.
Log without -y option
log_with_-y.txt (118.9 KB) - added by grepfor 4 years ago.
Log with -y option

Download all attachments as: .zip

Change History (6)

Changed 4 years ago by grepfor

Log without -y option

Changed 4 years ago by grepfor

Log with -y option

comment:1 Changed 4 years ago by michael

  • Summary changed from -y option affects audio/video skew during screen capture to -y option affects audio/video skew during screen capture (alsa+x11grab)

comment:2 Changed 4 years ago by cehoyos

  • Priority changed from important to normal

Please mention if this is a regression and please test current FFmpeg git head.

comment:3 Changed 4 years ago by grepfor

Not sure if it's a regression or not. I've not seen it previously, but also have never attempted to use ffmpeg in this way previously either. However, based on cargo cult postings from several years ago, a few of which seem to imply that -y is somehow important when doing screen capture, I would guess -- and it's only a guess -- that it is a long-standing issue.

Unfortunately, I do not have time to build it from git sources. However, ffmpeg-git r60910.1f2bacc-1 is available from the Arch repos, which I can obtain and run easily as a package install. Will that be of any use to you to know the results from that version?

Last edited 4 years ago by grepfor (previous) (diff)

comment:4 Changed 4 years ago by grepfor

Please update 'Version' field in ticket header to 2.2.2. I just tried it with that version from the Arch repos, and the problem still occurs.

Reproducibility note: On my system, this issue is 100% reproducible, and the resulting a/v skew is extremely obvious, especially if you wait several seconds before responding to the Overwrite? query. So the effort required for a developer to attempt reproducing it on up-to-date git code should be on the order of 1-2 minutes, literally. Just cut-n-paste the script, remove -y, and pre-create a file called ofile.mkv so that ffmpeg asks about overwriting it. I suspect you will see the problem immediately. If not, let me know.

Last edited 4 years ago by grepfor (previous) (diff)
Note: See TracTickets for help on using tickets.