[FFmpeg-trac] #3615(ffmpeg:new): -y option affects audio/video skew during screen capture (alsa+x11grab)
FFmpeg
trac at avcodec.org
Sat Nov 16 23:24:15 EET 2019
#3615: -y option affects audio/video skew during screen capture (alsa+x11grab)
------------------------------------+----------------------------------
Reporter: grepfor | Owner:
Type: defect | Status: new
Priority: normal | Component: ffmpeg
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+----------------------------------
Changes (by madscientist159):
* version: 2.2.1 => git-master
Comment:
I am able to confirm this bug exists in the latest FFmpeg GIT, *and* that
it affects more than just screen capture.
Easiest way to see it in action is to use one alsa and one video4linux
input into some kind of stream muxer (which one doesn't seem to matter),
then wait for a bit on the "Overwrite?" screen. If you wait on that
screen, and the capture hardware doesn't have massive buffers available,
you'll see an ALSA XRUN indicating the audio device was open and running
the entire time the prompt was shown. Passing -y produces no XRUN.
My primary concern right now is that I've been trying to track down a
subtle, constant A/V desync with properly timestamped ALSA/V4L buffers
(hardware synced clocks), and I'm wondering if this issue is related. If
pausing on the Overwrite prompt causes buffer overrun, I wonder if the
small amount of code executed between the ALSA device opening and the V4L
device opening with -y passed could still be introducing the slight
(~20ms) constant desync.
I'm not giving a full command line because capture devices will vary
between users, and a live source does seem to be required to trigger the
issue (x11 screen grab, V4L capture, etc.).
--
Ticket URL: <https://trac.ffmpeg.org/ticket/3615#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list