[bug][regression] Too many packets buffered for output stream

[p137]

Summary of the bug:
Trying to transcode some video file fails in the latest ffmpeg master with this message:
Too many packets buffered for output stream 0:1.

It works in 3.2.4 and stopped working in 3.3.0. Using git bisect I could identify this commit as the first bad commit: af1761f7b5b1b72197dc40934953b775c2d951cc

How to reproduce:

% ffmpeg -y -i "./too_many_packets_buffered_example.mp4" -f mp4 out.mp4
ffmpeg version N-83725-gaf1761f7b5 Copyright (c) 2000-2017 the FFmpeg developers
  built with Apple LLVM version 8.1.0 (clang-802.0.42)
  configuration: --prefix=/Users/peter/ffmpeg_latest --disable-doc
  libavutil      55. 47.101 / 55. 47.101
  libavcodec     57. 82.100 / 57. 82.100
  libavformat    57. 66.103 / 57. 66.103
  libavdevice    57.  3.100 / 57.  3.100
  libavfilter     6. 74.100 /  6. 74.100
  libswscale      4.  3.101 /  4.  3.101
  libswresample   2.  4.100 /  2.  4.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/peter/Downloads/too_many_packets_buffered_example.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.25.101
  Duration: 00:00:32.46, start: 0.000000, bitrate: 133 kb/s
    Stream #0:0(und): Audio: aac (Main) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
    Stream #0:1(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1024x768, 4 kb/s, 1.95 fps, 100 tbr, 19200 tbn, 1200 tbc (default)
    Metadata:
      handler_name    : VideoHandler
Stream mapping:
  Stream #0:1 -> #0:0 (h264 (native) -> mpeg4 (native))
  Stream #0:0 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
Too many packets buffered for output stream 0:1.
[aac @ 0x7fa762809000] Qavg: 639.028
[aac @ 0x7fa762809000] 2 frames left in the queue on closing
Conversion failed!

[p137]

sample video

[p137]

Output for running with -report

[p137]

result of running "ffmpeg -v 9 -loglevel 99 -i ./too_many_packets_buffered_example.mp4"

[gjdfgh]

Not a bug. The file has somewhat sparse video or audio frames, and increasing the packet queue size helps:

ffmpeg -i too_many_packets_buffered_example.mp4 -max_muxing_queue_size 400 out.mp4

[Carl Eugen Hoyos]

Replying to gjdfgh:

Not a bug. The file has somewhat sparse video or audio frames, and increasing the packet queue size helps:

The explanation contradicts the resolution...

[lucasstreamable]

I can second this issue. Just started popping up with 3.3. Extending the queue size does not fix it.

[Roger Zimmerman]

I can third this issue. We have many examples of this failure. Providing the -max_muxing_queue_size argument is a workaround, but not a fix.

[ObvB]

Additional data point ... just in case it helps ...

I was encountering this problem on a Raspberry Pi 2.

pi:~/ffmpeg_sources/ffmpeg-3.3$ ./ffmpeg -vcodec mpeg2_mmal -i CBS-Evening-News-With-Scott-Pelley.ts -f null -
ffmpeg version 3.3 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 4.9.2 (Raspbian 4.9.2-10)
  configuration: --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --enable-mmal --enable-decoder=mpeg2_mmal --enable-decoder=mpeg4_mmal --enable-decoder=h264_mmal
  libavutil      55. 58.100 / 55. 58.100
  libavcodec     57. 89.100 / 57. 89.100
  libavformat    57. 71.100 / 57. 71.100
  libavdevice    57.  6.100 / 57.  6.100
  libavfilter     6. 82.100 /  6. 82.100
  libswscale      4.  6.100 /  4.  6.100
  libswresample   2.  7.100 /  2.  7.100
Input #0, mpegts, from 'CBS-Evening-News-With-Scott-Pelley.ts':
  Duration: 00:30:00.50, start: 24953.710244, bitrate: 16569 kb/s
  Program 1
    Stream #0:0[0x31]: Video: mpeg2video ([2][0][0][0] / 0x0002), yuv420p(top first), 320x240, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x35](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, mono, fltp, 128 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (mpeg2_mmal) -> wrapped_avframe (native))
  Stream #0:1 -> #0:1 (ac3 (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Too many packets buffered for output stream 0:1.
Conversion failed!
pi:~/ffmpeg_sources/ffmpeg-3.3$

When attempting to decode an HD ATSC broadcast TV .ts file made by tvheadend, using the decoder mpeg2_mmal, it failed with the message "Too many packets buffered for output stream"

Decoding without specifying the mmal decoder worked.
Decoding an SD (704x480) file worked with (and without) using decoder mpeg2_mmal
ffmpeg 3.2.4 worked in all of the above cases.

As a workaround, allocating more memory to the GPU worked. Setting gpu_mem=256 in /boot/config.txt "fixes" the problem in my case.

[Marc]

We have the same problem with some videos. Increasing the max_muxing_queue_size param didn't help.

With ffmpeg 3.2.4 everything works fine.

[Marton Balint]

Replying to MarcSB:

We have the same problem with some videos. Increasing the max_muxing_queue_size param didn't help.

With ffmpeg 3.2.4 everything works fine.

Please provide a sample and a sample command line where increasing max_muxing_queue_size does not help.

[Nik D.]

Similar problem with ffmpeg 3.3.2 and MP3-file with PNG cover.
-max_muxing_queue_size 9999 resolve problem.
No problems with ffmpeg 3.2.6

ionice -c 3 nice /usr/bin/ffmpeg -y -i "/home/nox/46564100.mp3" -acodec libmp3lame -ab 128k -ac 2 "/home/nox/46564100_b128f0d146.mp3"
ffmpeg version 3.3.2 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Gentoo 6.3.0 p1.0)
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/share/doc/ffmpeg-3.3.2/html --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-O2 -march=native -pipe -fomit-frame-pointer' --disable-static --enable-avfilter --enable-avresample --disable-stripping --enable-version3 --disable-indev=v4l2 --disable-outdev=v4l2 --disable-indev=alsa --disable-indev=oss --disable-indev=jack --disable-outdev=alsa --disable-outdev=oss --disable-outdev=sdl --enable-version3 --enable-version3 --enable-bzlib --disable-runtime-cpudetect --disable-debug --disable-gcrypt --disable-gnutls --enable-gmp --enable-gpl --enable-hardcoded-tables --enable-iconv --disable-lzma --disable-network --disable-openssl --enable-postproc --disable-libsmbclient --disable-ffplay --disable-sdl2 --disable-vaapi --disable-vdpau --disable-xlib --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --enable-zlib --disable-libcdio --disable-libiec61883 --disable-libdc1394 --disable-libcaca --disable-openal --disable-opengl --disable-libv4l2 --disable-libpulse --enable-libopencore-amrwb --enable-libopencore-amrnb --disable-libfdk-aac --disable-libopenjpeg --disable-libbluray --disable-libcelt --disable-libgme --disable-libgsm --disable-mmal --disable-libmodplug --disable-libopus --disable-libilbc --disable-librtmp --disable-libssh --disable-libschroedinger --disable-libspeex --disable-libvorbis --disable-libvpx --disable-libzvbi --disable-libbs2b --disable-chromaprint --disable-libflite --disable-frei0r --disable-libfribidi --enable-fontconfig --disable-ladspa --disable-libass --enable-libfreetype --disable-librubberband --disable-netcdf --disable-libzmq --disable-libzimg --disable-libsoxr --enable-pthreads --enable-libvo-amrwbenc --enable-libmp3lame --disable-libkvazaar --disable-nvenc --disable-libopenh264 --disable-libsnappy --disable-libtheora --disable-libtwolame --disable-libwavpack --disable-libwebp --enable-libx264 --disable-libx265 --disable-libxvid --disable-amd3dnow --disable-amd3dnowext --disable-aesni --disable-avx2 --disable-fma3 --disable-fma4 --disable-xop --cpu=host --disable-doc --disable-htmlpages --enable-manpages
  libavutil      55. 58.100 / 55. 58.100
  libavcodec     57. 89.100 / 57. 89.100
  libavformat    57. 71.100 / 57. 71.100
  libavdevice    57.  6.100 / 57.  6.100
  libavfilter     6. 82.100 /  6. 82.100
  libavresample   3.  5.  0 /  3.  5.  0
  libswscale      4.  6.100 /  4.  6.100
  libswresample   2.  7.100 /  2.  7.100
  libpostproc    54.  5.100 / 54.  5.100
Incorrect BOM value
Error reading comment frame, skipped
Incorrect BOM value
Error reading lyrics, skipped
[mp3 @ 0xad3400] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from '/home/nox/46564100.mp3':
  Metadata:
    title           : 24дня [Новый Рэп] Это реальный трек От реальных реалистов Про реальные расклады В реале Я не тру мы true (ахаха) Я уверин на все сто что, Ты ты ты ▒
    artist          : [muzmo.ru] Allj(Элджей)
    album           : [muzmo.ru]
    copyright       : http://muzmo.ru
  Duration: 00:02:26.08, start: 0.000000, bitrate: 324 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
    Stream #0:1: Video: png, rgb24(pc), 300x300 [SAR 11811:11811 DAR 1:1], 90k tbr, 90k tbn, 90k tbc
    Metadata:
      title           : 3.png
      comment         : Other
Stream mapping:
  Stream #0:1 -> #0:0 (png (native) -> png (native))
  Stream #0:0 -> #0:1 (mp3 (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
Too many packets buffered for output stream 0:1.
[libmp3lame @ 0xb13c60] 4 frames left in the queue on closing
Conversion failed!

[Nik D.]

mp3 with png cover

[guillaumekh]

I can provide some complementary data on how easily the current default queue size is hit.

On running ffmpeg -i path/to/file.m4a -filter_complex ebur128=peak=true:dualmono=true -f null /dev/null on a large music catalog of M4A files sourced from various online music stores, we see around ±15% of processes failing with a Too many packets buffered for output stream error.

Sample: ​https://www.dropbox.com/s/av7hrmkztnwcm54/Send%20Someone%20Away%20%28feat.%20Jos%C3%A9%20Gonz%C3%A1lez%29.m4a?dl=0

[t.rapp]

Also stumbled over the issue with FFmpeg v3.3.2 (see attached report file). In my case I was able to work-around the issue by limiting the number of threads with "-threads 2".

Further noticed that the log output contains a lot of "cur_dts is invalid" lines.

[afarah]

I have a specific video file (below) which ffmpeg from git-master (at 1193301758b8af2ccd05e0dba5c4320e1e0702ac) fails to process with Too many packets buffered for output stream 0:1, unless -max_muxing_queue_size 9999 is passed as an argument, as reported by NoX (above). The input video file was successfully generated using ffmpeg itself (more precisely with ffmpeg -i original.mp4 -ss 01:34:56 -t 00:00:38 -c copy input.mp4, where original.mp4 is a 3GB file, using ffmpeg 3.2.4).

Full command line to reproduce the error: ffmpeg -v 9 -loglevel 99 -i input.mp4 /tmp/out.mp4

[Full output for ffmpeg from git master](​https://paste.ubuntu.com/25224478/).

ffmpeg 3.2.4 fails with a different error than the one from git master, and passing the aforementioned parameter does not fix the issue. Namely, it fails with Unable to parse option value "-1" as pixel format. [Compile options, full command line and output](​https://paste.debian.net/plainh/7c7a9177). I can provide more info if necessary. Notice that I built ffmpeg from git master on a Debian system whereas 3.2.4 was built on Gentoo (I can (re)build both on the same system if need be).

The file is 20MB so [externally uploaded](​http://inf.ufrgs.br/~afarah/files/ffmpeg_bug_report.mp4), sorry, making it shorter "solves" the issue.

[keynet]

I've also experienced this with recent git N-87068-g8a0954dd51 on some DVB recordings converted by ffmpeg last year. It happens on recordings with sparse AAC-LC sound tracks (Audio Description). I had some issues last year playing back AD streams converted to AAC (or MP3 actually), so now the vdr-convert script only copies these MP2 tracks, it doesn't try to compress to anything more modern. The ones giving me trouble are some test conversions that got away.

I set -max_muxing_queue_size 4000 and it's OK so far.

[lkiesow]

Same issue here with 3.3.4 and some input files. Using -max_muxing_queue_size 1000 solved the issue for me but since it seems to be more common than expected, I am wondering if it would make sense to increase the default value?

[Ben R]

It looks like the default value is 128? With -max_muxing_queue_size 400 we're still occasionally hitting errors.

If it is advised that we tweak this option to workaround the issue, can you please provide some further guidance on what is a sane range of values? In this report I see 400, 1000, and 9999 all mentioned. https://ffmpeg.org/ffmpeg.html#Advanced-options states "The default value of this option should be high enough for most uses, so only touch this option if you are sure that you need it.", which makes me feel like we probably don't want to be configuring this value too high over the default.

[Andrès]

Same issue with ffmpeg 3.4, setting -max_muxing_queue_size 1024 works as well.

I think we should consider this as a regression and either find the source cause (because somehow if this change happened in 3.3 in that commit, it has to be because of something which can surely be fixed), or raise the default so that this error happens less often.

[Marton Balint]

Not that simple to fix this, because the root cause of these issues, which is the fact that ffmpeg only writes the header of the output after it gets one decoded frame from each input is intentional as far as I know.

Increaseing the muxing queue seems realtively harmless, but it might increase the initial latency and the initial memory usage of ffmpeg. (for cases which would fail right now).

Until we figure out something better, incresing the default to 1024 seems like the right move, altough that is still not something that will fix every case which used to work.

[julian]

i've also encountered the issue on quite a few files when transcoding from MKV to MP4. workaround seems to work, but should not be necessary

[keynet]

Recent off-air HD recording with the following streams:

Stream #0:0[0xc9]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0xca](eng): Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
Stream #0:2[0xce](eng): Audio: aac_latm (HE-AACv2) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
Stream #0:3[0xcd](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)

Required increasing -max_muxing_queue_size to 9999. the original 4000 was not enough (ffmpeg errored out with "Too many packets buffered for output stream 0:1.")

However, using a value of 9999 causes empty (but apparently valid) AAC audio streams to be produced when transcoding. Excluding stream 0:2 (which is AAC-HEv2 and sparse as it's the AD stream) works OK - but with a -max_muxing_queue_size of 4000

[zermok]

I just encounter this issue with ffmpeg 3.4.2 and input live stream like rtmp

[neckTwi Ozfguah]

Yep! Just bumped into it on 3.4.2! I wish I could fix it!

[Vinay]

We've been bumping into this in version 4.0.0. Since we transcode a large amount of videos from WEBM to MP4 in production, we've had to settle on -max-muxing_queue_size of 4000 for now. Will report back if this fails in any way.

[Vinay]

As an update - setting the max muxing queue size to 9999 has helped but not eliminated issues for a decent percentage of our workload still. Anybody know the root cause of this? How could it be this was working for us completely in 3.4.1 but is now broken in 4.0? Bumping past 9999 leaves me a bit worried here.

Seems like perhaps the code added to the commit in the description could have resulted in some code paths that account for the queue size in a way that wasn't intended?

For easy ref: ​http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=af1761f7b5b1b72197dc40934953b775c2d951cc

[stib]

Happening for me while working with 6K prores camera footage. Command was:

ffmpeg -n -i $_ -vf lut3d="KC_NEUTRAL.cube" -c:v prores -profile:v 3 -c:a copy (Join-Path '..\one_light_grade\' $_.name)

(I'm using powershell to batch a folder applying a LUT, hence the '$_' is the input file).

Adding -max_muxing_queue_size 99999 seems to be working.

[Kai Hendry]

Hitting this error transcoding an IOS screencast for the Web:
​https://media.dev.unee-t.com/2019-01-22/B06C6A3A-DB9E-4A4F-876A-C2ADFA568016.MOV
​https://media.dev.unee-t.com/2019-01-23/B06C6A3A-DB9E-4A4F-876A-C2ADFA568016.mp4.log
​https://s.natalian.org/2019-01-23/without-hw-accel-B06C6A3A-DB9E-4A4F-876A-C2ADFA568016.mp4.log

[shironeko]

Hit this too in 4.1.1, with

$ ffmpeg -i BDMV/STREAM/00000.m2ts -f null -
ffmpeg version n4.1.1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.2.1 (GCC) 20181127
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100
Input #0, mpegts, from 'BDROM/BDMV/STREAM/00000.m2ts':
  Duration: 00:23:56.94, start: 4232.000000, bitrate: 43483 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
    Stream #0:1[0x1100]: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, stereo, s16, 1536 kb/s
    Stream #0:2[0x1101]: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, stereo, s16, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
  Stream #0:1 -> #0:1 (pcm_bluray (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Too many packets buffered for output stream 0:1.
Conversion failed!

[Shebuka]

I also have this error with iOS screen recordings with 4.1.3

ffmpeg version n4.1.3 Copyright (c) 2000-2019 the FFmpeg developers
  built with Apple LLVM version 10.0.1 (clang-1001.0.46.3)
  configuration: --disable-debug --disable-ffplay --disable-ffprobe --disable-doc --disable-iconv --disable-zlib --disable-bzlib --disable-securetransport --disable-encoders --disable-muxers --disable-filters --disable-protocols --disable-bsfs --enable-gpl --enable-libx264 --enable-encoder='libx264,aac,mjpeg' --enable-muxer='mp4,ipod,image2' --enable-filter='scale,crop,aresample,thumbnail' --enable-protocol=file --enable-bsf=aac_adtstoasc --extra-ldflags=-L/Users/fbk/Projects/git/ffmpeg/lib --extra-cflags=-I/Users/fbk/Projects/git/ffmpeg/include --prefix=.
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'file:movie_20190711T083758Z.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp41mp42isom
    creation_time   : 2019-07-11T08:38:00.000000Z
  Duration: 00:00:11.00, start: 0.000000, bitrate: 531 kb/s
    Stream #0:0(und): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p(tv, bt709), 476x848, 526 kb/s, 7.64 fps, 30 tbr, 600 tbn, 1200 tbc (default)
    Metadata:
      creation_time   : 2019-07-11T08:38:01.000000Z
      handler_name    : Core Media Video
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 2 kb/s (default)
    Metadata:
      creation_time   : 2019-07-11T08:38:01.000000Z
      handler_name    : Core Media Audio
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
Too many packets buffered for output stream 0:1.
[aac @ 0x7ffda6818c00] Qavg: 65179.457
[aac @ 0x7ffda6818c00] 2 frames left in the queue on closing
Conversion failed!

-max_muxing_queue_size 512 fixes it

[BoKK]

ffmpeg version git-2020-02-24-bc9b635

This bug is still present... 3 years later... ¿?

[icecrawler]

When you have framerates too low, as one is tempted to do when merging audio with a "poster" image, ffmpeg runs into problems.
The time of the output comes out wrong. I've had the output time coming wrong still with "-shortest -fflags +shortest -max_interleave_delta 100M" (though it made it better), so I had to cut the output with the "-t" command.

And then, if you grab the output and copy it, with "ffmpeg -i output.mp4 output-copy.mp4", it throws the problem in this page:
(

Too many packets buffered for output stream 0:1.
[aac @ 0x7ffda6818c00] Qavg: 65179.457
[aac @ 0x7ffda6818c00] 2 frames left in the queue on closing

)
Which is solved by "-max_muxing_queue_size 9999" (before the output, after the input)

Which again, if you set the fps (or "-r") higher, the problems, all of them, dissapear.

Looking at the ffmpeg doc for "max_muxing_queue_size", I got some insight:

-max_muxing_queue_size packets (output,per-stream)

When transcoding audio and/or video streams, ffmpeg will not begin writing into the output until it has one packet for each such stream. While waiting for that to happen, packets for other streams are buffered. This option sets the size of this buffer, in packets, for the matching output stream.

I think ffmpeg has to grab one video frame and a lot of audio frames at the same time, so it needs to buffer a lot of audio frames at the same time, and isn't used to that, it's used to... buffer 1/30th (for 30fps) of those audio frames, join them with a video frame, and move on. Maybe.

I think ffmpeg should work this to be more smooth maybe... but idk, maybe you just have to once and for all read all the ffmpeg doc.
Maybe put some prompt, "need to increase muxer buffer detected, want to raise it? (y/n) to preset this, see docs for "max_muxer_(etc)"".
I don't know why the incorrect output time exists though, but something similar could solve it.

[monnier]

So far, the only workaround I have seen for this problem is to add the -max_muxing_queue_size argument, but that's not an option when the ffmpeg command is run from a tool you don't control (e.g. within peertube).

So until this problem is solved, how can I ask ffmpeg to generate files which it will process correctly without bumping into this problem?

[Mattias Wadman]

Is this commit related to this issue?

​https://github.com/FFmpeg/FFmpeg/commit/453b2f3c154f6b83221940ad411599ded91f7413

[Arjun]

Seems to have been fixed at latest git head (checked on N-99980-g8f468c6668-g42ccef2846+5), by the above commit.

If anyone comes across this who is still using older versions, I found that this was usually caused by a late starting track, where ffmpeg would buffer encoded packets until there was at least 1 packet encoded for every output stream before muxing, so the late starting track would significantly delay this, going over the threshold for max_muxing_queue_size, causing ffmpeg to drop the late track entirely in order to not drop the original packets. This does mean that, so long as you know that you'd have enough memory to buffer encoded packets before any late tracks start, you're safe to increase max_muxing_queue_size to whatever you want. Of course, I wouldn't set it too high without knowing what's up with your sources, since it's possible that a track from a broken input might never start, and then you're left buffering your entire output until exiting.