Opened 7 years ago
Closed 4 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)
Change History (41)
by , 7 years ago
Attachment: | too_many_packets_buffered_example.mp4 added |
---|
by , 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 , 7 years ago
Cc: | added |
---|---|
Keywords: | regression added |
Priority: | normal → important |
Reproduced by developer: | set |
follow-up: 3 comment:2 by , 7 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
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
comment:3 by , 7 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
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 , 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 , 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 , 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.
follow-up: 8 comment:7 by , 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.
comment:8 by , 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 , 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!
comment:10 by , 7 years ago
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.
by , 7 years ago
Attachment: | ffmpeg-20170726-150739.log added |
---|
comment:11 by , 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 , 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 , 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 , 7 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 , 7 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 , 7 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 , 7 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 , 7 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 , 7 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
comment:20 by , 7 years ago
I just encounter this issue with ffmpeg 3.4.2 and input live stream like rtmp
comment:22 by , 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 , 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 , 6 years ago
Cc: | added |
---|
comment:25 by , 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.
comment:26 by , 6 years ago
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
comment:27 by , 6 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 , 5 years ago
Cc: | added |
---|
comment:29 by , 5 years ago
Cc: | added |
---|
comment:30 by , 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 , 5 years ago
Cc: | added |
---|
ffmpeg version git-2020-02-24-bc9b635
This bug is still present... 3 years later... ¿?
comment:32 by , 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.
comment:33 by , 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?
comment:34 by , 4 years ago
Cc: | added |
---|
comment:35 by , 4 years ago
Is this commit related to this issue?
https://github.com/FFmpeg/FFmpeg/commit/453b2f3c154f6b83221940ad411599ded91f7413
comment:36 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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.
sample video