Opened 7 years ago

Closed 3 years ago

#6375 closed defect (fixed)

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

Reported by: p137 Owned by:
Priority: important Component: ffmpeg
Version: git-master Keywords: regression
Cc: Marton Balint, tmatth@videolan.org, ffmpeg@frank.haefemeier.eu, bokeron2020@gmail.com, monnier@iro.umontreal.ca Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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!

Attachments (5)

too_many_packets_buffered_example.mp4 (527.3 KB ) - added by p137 7 years ago.
sample video
ffmpeg-20170505-182833.log (16.8 KB ) - added by p137 7 years ago.
Output for running with -report
video_info.log (200.7 KB ) - added by p137 7 years ago.
result of running "ffmpeg -v 9 -loglevel 99 -i ./too_many_packets_buffered_example.mp4"
46564100.mp3 (931.9 KB ) - added by Nik D. 7 years ago.
mp3 with png cover
ffmpeg-20170726-150739.log (18.7 KB ) - added by t.rapp 7 years ago.

Download all attachments as: .zip

Change History (41)

by p137, 7 years ago

sample video

by p137, 7 years ago

Attachment: ffmpeg-20170505-182833.log added

Output for running with -report

by p137, 7 years ago

Attachment: video_info.log added

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

comment:1 by Marton Balint, 7 years ago

Cc: Marton Balint added
Keywords: regression added
Priority: normalimportant
Reproduced by developer: set

comment:2 by gjdfgh, 7 years ago

Resolution: worksforme
Status: newclosed

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

in reply to:  2 comment:3 by Carl Eugen Hoyos, 7 years ago

Resolution: worksforme
Status: closedreopened

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

comment:4 by lucasstreamable, 7 years ago

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

comment:5 by Roger Zimmerman, 7 years ago

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.

comment:6 by ObvB, 7 years ago

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.

comment:7 by Marc, 7 years ago

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.

in reply to:  7 comment:8 by Marton Balint, 7 years ago

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.

comment:9 by Nik D., 7 years ago

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!

by Nik D., 7 years ago

Attachment: 46564100.mp3 added

mp3 with png cover

comment:10 by guillaumekh, 7 years ago

Deleted

Last edited 7 years ago by guillaumekh (previous) (diff)

by t.rapp, 7 years ago

Attachment: ffmpeg-20170726-150739.log added

comment:11 by t.rapp, 7 years ago

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.

comment:12 by afarah, 7 years ago

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.

comment:13 by keynet, 7 years ago

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.

comment:14 by lkiesow, 6 years ago

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?

comment:15 by Ben R, 6 years ago

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.

comment:16 by Andrès, 6 years ago

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.

comment:17 by Marton Balint, 6 years ago

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.

comment:18 by julian, 6 years ago

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

comment:19 by keynet, 6 years ago

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

Last edited 6 years ago by keynet (previous) (diff)

comment:20 by zermok, 6 years ago

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

comment:21 by neckTwi Ozfguah, 6 years ago

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

Last edited 6 years ago by neckTwi Ozfguah (previous) (diff)

comment:22 by Vinay, 6 years ago

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.

comment:23 by Vinay, 6 years ago

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

comment:24 by Tristan Matthews, 6 years ago

Cc: tmatth@videolan.org added

comment:25 by stib, 6 years ago

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.

Last edited 6 years ago by stib (previous) (diff)

comment:27 by shironeko, 5 years ago

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!

comment:28 by Frank Haefemeier, 5 years ago

Cc: ffmpeg@frank.haefemeier.eu added

comment:29 by Frank Haefemeier, 5 years ago

Cc: ffmpeg@frank.haefemeier.eu added

comment:30 by Shebuka, 5 years ago

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

comment:31 by BoKK, 4 years ago

Cc: bokeron2020@gmail.com added

ffmpeg version git-2020-02-24-bc9b635

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

comment:32 by icecrawler, 4 years ago

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.

Last edited 4 years ago by icecrawler (previous) (diff)

comment:33 by monnier, 4 years ago

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?

Last edited 4 years ago by monnier (previous) (diff)

comment:34 by monnier, 4 years ago

Cc: monnier@iro.umontreal.ca added

comment:36 by Arjun, 3 years ago

Resolution: fixed
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.