When recording, audio duration is shorter by the time it takes to spin up the video

[chuckwoodchuck]

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).

[Balling]

Does it happen on flac?

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

That is not strange, we support editlist for aac in the beginning. So the added silence from the start is removed.

Probably when you press q it exits instantly and does not record audio. Still strange

[chuckwoodchuck]

Replying to Balling:

Does it happen on flac?

Yes it does. I tried multiple audio output formats in separate tests, the trimmed tail is of the same length in all cases.

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

That is not strange, we support editlist for aac in the beginning. So the added silence from the start is removed.

To clarify - assuming the recording started at 10:00:00, video codec took 3 seconds to begin its operation, and "q" was hit at 10:00:10, the audio portion in the final file comes from 10:00:00 to 10:00:07, and not from 10:00:03 to 10:00:10. So even though the recording was still going between 10:00:07 and 10:00:10, and the portion from 10:00:00 to 10:00:03 is present, last 3 seconds are discarded.