[FFmpeg-trac] #11330(ffmpeg:new): When recording, audio duration is shorter by the time it takes to spin up the video (was: -f pulse cuts last 2 secodns of audio)

[FFmpeg]

#11330: When recording, audio duration is shorter by the time it takes to spin up
the video
----------------------------------------+----------------------------------
             Reporter:  chuckwoodchuck  |                    Owner:  (none)
                 Type:  defect          |                   Status:  new
             Priority:  important       |                Component:  ffmpeg
              Version:  unspecified     |               Resolution:
             Keywords:  pulseaudio      |               Blocked By:
             Blocking:                  |  Reproduced by developer:  0
Analyzed by developer:  0               |
----------------------------------------+----------------------------------
Changes (by chuckwoodchuck):

 * summary:  -f pulse cuts last 2 secodns of audio =>
     When recording, audio duration is shorter by the time it takes to spin
     up the video


Old description:

> Summary of the bug:
> -f pulse cuts last 2-3 seconds of audio when stopped by hitting "q"
> How to reproduce:
> I observed the behavior by recording screen with x11grab for video and
> pulse for audio. Last 2 seconds of audio are missing in every file.
> {{{
> $ ffmpeg -y -f x11grab -i "$DISPLAY" -f pulse -i alsa_output.pci-
> 0000_05_00.6.analog-stereo.monitor /tmp/recording.mp4
> }}}
> I decided to split video and audio with -map to separate files to measure
> the stream length, and indeed audio is shorter:
> {{{
> $ ffmpeg -y -f x11grab -i "$DISPLAY" -f pulse -i alsa_output.pci-
> 0000_05_00.6.analog-stereo.monitor -map 0:v /tmp/foo.mp4 -map 1:a
> /tmp/foo_audio.mp4
> $ ffprobe /tmp/foo_audio.mp4 |& grep Duration
>   Duration: 00:00:02.08, start: 0.000000, bitrate: 135 kb/s
> $ ffprobe /tmp/foo.mp4 |& grep Duration
>   Duration: 00:00:04.37, start: 0.000000, bitrate: 912 kb/s
> }}}
> It's not an issue with x11grab. Passing an arbitrary file in its place
> (-i something/mp4) produces the same effect with the audio being 2-3
> seconds shorter.
>
> The audio is not cut when total recording length is specified beforehand,
> with -t 15. It happens only when "q" is hit.
>
> The issue occurs on ffmpeg versions 5.1, 7.1 (Debian stable/sid) and
> recent builds, too. There's no difference between the pulseaudio or
> pipewire-pulse as the backend.

New description:

 Summary of the bug:
 When recording video+audio in a single ffmpeg instance, depending on the
 video codec used, the audio is trimmed at the end by exactly the duration
 it took for the video (codec?) to initialize.

 I observed the behavior by recording screen with x11grab for video and
 pulse for audio. Last 2 seconds of audio are missing in every file.
 {{{
 $ ffmpeg -y -f x11grab -i "$DISPLAY" -f pulse -i alsa_output.pci-
 0000_05_00.6.analog-stereo.monitor -c:v libx264 /tmp/recording.mp4
 }}}
 I decided to split video and audio with -map to separate files to measure
 the stream length, and indeed audio is shorter:
 {{{
 $ ffmpeg -y -f x11grab -i "$DISPLAY" -f pulse -i alsa_output.pci-
 0000_05_00.6.analog-stereo.monitor -c:v libx264 -map 0:v /tmp/foo.mp4 -map
 1:a /tmp/foo_audio.mp4
 $ ffprobe /tmp/foo_audio.mp4 |& grep Duration
   Duration: 00:00:02.08, start: 0.000000, bitrate: 135 kb/s
 $ ffprobe /tmp/foo.mp4 |& grep Duration
   Duration: 00:00:04.37, start: 0.000000, bitrate: 912 kb/s
 }}}
 It's not an issue with x11grab. Passing an arbitrary file in its place (-i
 something/mp4) produces the same effect with the audio being 2-3 seconds
 shorter.

 The audio is not cut when total recording length is specified beforehand,
 with -t 15. It happens only when "q" is hit.

 Examples:
 With libx264 -preset ultrafast the audio is 800 ms shorter
 {{{
 $ ffmpeg -y -f lavfi -i sine -f x11grab -i $DISPLAY -map 0:a
 /tmp/foo_audio.mp4 -c:v libx264 -preset ultrafast -map 1:v /tmp/foo.mp4

 $ ffprobe /tmp/foo.mp4 |& grep Duration; ffprobe /tmp/foo_audio.mp4 |&
 grep Duration
   Duration: 00:00:02.84, start: 0.000000, bitrate: 6460 kb/s
   Duration: 00:00:02.04, start: 0.000000, bitrate: 75 kb/s
 }}}

 With libx264 -preset veryslow the audio is 3200 ms shorter
 {{{
 $ ffmpeg -y -f lavfi -i sine -f x11grab -i $DISPLAY -map 0:a
 /tmp/foo_audio.mp4 -c:v libx264 -preset veryslow -map 1:v /tmp/foo.mp4

 $ ffprobe /tmp/foo.mp4 |& grep Duration; ffprobe /tmp/foo_audio.mp4 |&
 grep Duration
   Duration: 00:00:04.81, start: 0.000000, bitrate: 1202 kb/s
   Duration: 00:00:01.67, start: 0.000000, bitrate: 75 kb/s
 }}}

 libx265 with default settings, exactly 1 second
 {{{
 $ ffmpeg -y -f lavfi -i sine -f x11grab -i $DISPLAY -map 0:a
 /tmp/foo_audio.mp4 -c:v libx265 -map 1:v /tmp/foo.mp4
 $ ffprobe /tmp/foo.mp4 |& grep Duration; ffprobe /tmp/foo_audio.mp4 |&
 grep Duration
   Duration: 00:00:03.64, start: 0.000000, bitrate: 1854 kb/s
   Duration: 00:00:02.62, start: 0.000000, bitrate: 73 kb/s
 }}}

 And lastly, mpeg4, the streams are of equal length
 {{{
 $ ffmpeg -y -f lavfi -i sine -f x11grab -i $DISPLAY -map 0:a
 /tmp/foo_audio.mp4 -c:v mpeg4 -map 1:v /tmp/foo.mp4
 $ ffprobe /tmp/foo.mp4 |& grep Duration; ffprobe /tmp/foo_audio.mp4 |&
 grep Duration
   Duration: 00:00:02.57, start: 0.000000, bitrate: 7464 kb/s
   Duration: 00:00:02.62, start: 0.000000, bitrate: 73 kb/s
 }}}

 A behavior I'd expect, is that irrespective of the video codec used, since
 both audio and video capture is started in the same time, the streams
 should be of equal length. What's strange is that the audio is cut from
 the end, not the beginning (that is, the audio that is played while codec
 is starting is NOT lost - the lost part is the tail).

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