[FFmpeg-trac] #9776(avdevice:new): pulse and x11grab: audio is around 2 seconds behind video

FFmpeg trac at avcodec.org
Mon May 9 22:34:29 EEST 2022


#9776: pulse and x11grab: audio is around 2 seconds behind video
-------------------------------------+-------------------------------------
             Reporter:  merulasnyde  |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avdevice
              Version:  git-master   |               Resolution:
             Keywords:  pulse        |               Blocked By:
  pulseaudio avdevice delay desync   |
  audio audio/video                  |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Old description:

> Summary of the bug: When recording audio+video of my screen, the captured
> audio is around 2 seconds behind the video.
> How to reproduce:
> {{{
> % ffmpeg -f pulse -ac 2 -channel_layout stereo -i default -r 60
> -video_size 640x480 -f x11grab -i :0.0+0,0 -c:a libvorbis -b:a 192k -c:v
> libx264 -b:v 2M delayed_audio.mkv
>
> * Start the capture (possibly with some audio already playing so
> pavucontrol can be checked to see whether audio is being recorded)
> * Move something that can produce audio at demand into the captured
> region, e.g. a media player with a play/pause button.
> * Periodically push the play/pause button to start and stop audio.
> * Check the recorded video and see whether the audio start+stop matches
> the pushes of the button
> }}}
>
> {{{
> ffmpeg version f77ac5131cd1c623aa54ec432cba0d922e9aa470
> ffmpeg version N-106835-gf77ac5131c Copyright (c) 2000-2022 the FFmpeg
> developers
> built with gcc 11.2.0 (Gentoo Hardened 11.2.0 p1)
>
> configuration: --enable-libx264 --enable-libvorbis --enable-libpulse
> --enable-gpl --enable-ffmpeg --enable-version3 --enable-nonfree
> --disable-ffplay --disable-ffprobe --disable-libx265 --disable-libv4l2
> --disable-libvpx --disable-nvenc --disable-nvdec --disable-cuda
> --disable-vaapi --disable-librtmp --disable-ffnvcodec --disable-hwaccels
> --disable-filters --enable-filter=scale --enable-filter=aresample
> --disable-decoders --disable-encoders --enable-decoder=rawvideo --enable-
> decoder=pcm_s16le --enable-encoder=libx264 --enable-encoder=libvorbis
> --disable-doc
> libavutil      57. 24.101 / 57. 24.101
> libavcodec     59. 27.100 / 59. 27.100
> libavformat    59. 23.100 / 59. 23.100
> libavdevice    59.  6.100 / 59.  6.100
> libavfilter     8. 38.100 /  8. 38.100
> libswscale      6.  6.100 /  6.  6.100
> libswresample   4.  6.100 /  4.  6.100
> libpostproc    56.  5.100 / 56.  5.100
>

> }}}
>
> It was fine in 4.3 and stopped working in 4.4-something.
> I ran a bisect between 4.3 and some bad commit in 4.4, using the strategy
> outlined above to determine whether the commit is good or bad.
> The bisect revealed this to be a (first) bad commit:
> b2d0826513c5e76f9bad2f1f0c809bc5c8e58b0c
> {{{
> Author: Marton Balint <cus at passwd.hu>
> Date:   Sat Feb 6 19:48:51 2021 +0100
>
>     avdevice/pulse_audio_dec: do not read undersized frames
>
>     Keep on reading fragments until we got fragment_size amount of data,
> otherwise
>     we might get frames with 1-2 samples only if pa_stream_peek is called
> slightly
>     less frequently than sample rate.
>
>     Note that fragments might contain a lot less data than fragment_size,
> so
>     reading multiple fragments to get fragment_size amount of data is
> intentional.
>
>     Signed-off-by: Marton Balint <cus at passwd.hu>
> }}}
>

> I was also able to reproduce it on a precompiled binary of (the same)
> master N-106835-gf77ac5131c-20220509 prior to the bisect.
>
> Because it seems to be a pulse issue I imagine there is some extra info
> that could be useful (e.g. pertaining to my pulseaudio installation).

New description:

 Summary of the bug: When recording audio+video of my screen, the captured
 audio is around 2 seconds behind the video.
 How to reproduce:
 {{{
 % ffmpeg -f pulse -ac 2 -channel_layout stereo -i default -r 60
 -video_size 640x480 -f x11grab -i :0.0+0,0 -c:a libvorbis -b:a 192k -c:v
 libx264 -b:v 2M delayed_audio.mkv

 * Start the capture (possibly with some audio already playing so
 pavucontrol can be checked to see whether audio is being recorded)
 * Move something that can produce audio at demand into the captured
 region, e.g. a media player with a play/pause button.
 * Periodically push the play/pause button to start and stop audio.
 * Check the recorded video and see whether the audio start+stop matches
 the pushes of the button
 }}}

 {{{
 ffmpeg version f77ac5131cd1c623aa54ec432cba0d922e9aa470
 ffmpeg version N-106835-gf77ac5131c Copyright (c) 2000-2022 the FFmpeg
 developers
 built with gcc 11.2.0 (Gentoo Hardened 11.2.0 p1)

 configuration: --enable-libx264 --enable-libvorbis --enable-libpulse
 --enable-gpl --enable-ffmpeg --enable-version3 --enable-nonfree --disable-
 ffplay --disable-ffprobe --disable-libx265 --disable-libv4l2 --disable-
 libvpx --disable-nvenc --disable-nvdec --disable-cuda --disable-vaapi
 --disable-librtmp --disable-ffnvcodec --disable-hwaccels --disable-filters
 --enable-filter=scale --enable-filter=aresample --disable-decoders
 --disable-encoders --enable-decoder=rawvideo --enable-decoder=pcm_s16le
 --enable-encoder=libx264 --enable-encoder=libvorbis --disable-doc
 libavutil      57. 24.101 / 57. 24.101
 libavcodec     59. 27.100 / 59. 27.100
 libavformat    59. 23.100 / 59. 23.100
 libavdevice    59.  6.100 / 59.  6.100
 libavfilter     8. 38.100 /  8. 38.100
 libswscale      6.  6.100 /  6.  6.100
 libswresample   4.  6.100 /  4.  6.100
 libpostproc    56.  5.100 / 56.  5.100


 }}}

 It was fine in 4.3 and stopped working in 4.4-something.
 I ran a bisect between 4.3 and some bad commit in 4.4, using the strategy
 outlined above to determine whether the commit is good or bad.
 The bisect revealed this to be a (first) bad commit:
 b2d0826513c5e76f9bad2f1f0c809bc5c8e58b0c
 {{{
 Author: Marton Balint <cus at passwd.hu>
 Date:   Sat Feb 6 19:48:51 2021 +0100

     avdevice/pulse_audio_dec: do not read undersized frames

     Keep on reading fragments until we got fragment_size amount of data,
 otherwise
     we might get frames with 1-2 samples only if pa_stream_peek is called
 slightly
     less frequently than sample rate.

     Note that fragments might contain a lot less data than fragment_size,
 so
     reading multiple fragments to get fragment_size amount of data is
 intentional.

     Signed-off-by: Marton Balint <cus at passwd.hu>
 }}}


 I was also able to reproduce it on a precompiled binary of (the same)
 master N-106835-gf77ac5131c-20220509 prior to the bisect.

 Because it seems to be a pulse issue I imagine there is some extra info
 that could be useful (e.g. pertaining to my pulseaudio installation).

 While I reproduced it on master, it occurred during normal use after
 upgrading to various versions of 4.4.

 Reverting the bad commit on master seems to fix the issue.

--
Comment (by merulasnyde):

 Also
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9776#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list