#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
