FFMPEG: Too many packets buffered for output stream 0:1

I want to add a logo to a video using FFMPEG. I encountered this error: "Too many packets buffered for output stream 0:1.", "Conversion Failed.". I tried with diffent pictures and videos, always got the same error. Google didn't help much either. I found a thread

C:\Users\Anwender\OneDrive - IT-Center Engels\_Programmierung & Scripting\delphi\_ITCE\Tempater\Win32\Debug\ffmpeg\bin>ffmpeg ^
Mehr? -i C:\Users\Anwender\Videos\CutErgebnis.mp4 ^
Mehr? -i C:\Users\Anwender\Pictures\pic.png ^
Mehr? -filter_complex "overlay=0:0" ^
Mehr? C:\Users\Anwender\Videos\Logo.mp4
ffmpeg version N-90054-g474194a8d0 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libmfx --enable-amf --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth
  libavutil      56.  7.101 / 56.  7.101
  libavcodec     58. 11.101 / 58. 11.101
  libavformat    58.  9.100 / 58.  9.100
  libavdevice    58.  1.100 / 58.  1.100
  libavfilter     7. 12.100 /  7. 12.100
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\Users\Anwender\Videos\CutErgebnis.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.9.100
    comment         : Captured with Snagit 13.1.3.7993
                    : Microphone - Mikrofon (Steam Streaming Microphone)
                    :
  Duration: 00:01:51.99, start: 0.015011, bitrate: 148 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1918x718 [SAR 1:1 DAR 959:359], 149 kb/s, 14.79 fps, 15 tbr, 15k tbn, 30 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 1 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Input #1, png_pipe, from 'C:\Users\Anwender\Pictures\pic.png':
  Duration: N/A, bitrate: N/A
    Stream #1:0: Video: png, pal8(pc), 400x400, 25 tbr, 25 tbn, 25 tbc
File 'C:\Users\Anwender\Videos\Logo.mp4' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 (h264) -> overlay:main (graph 0)
  Stream #1:0 (png) -> overlay:overlay (graph 0)
  overlay (graph 0) -> Stream #0:0 (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 @ 000001f4c5257a40] Qavg: 65305.387
[aac @ 000001f4c5257a40] 2 frames left in the queue on closing
Conversion failed!

My FFMPEG Version: ffmpeg-20180322-ed0e0fe-win64-static

Details about the Video:

    C:\Users\Anwender\OneDrive - IT-Center Engels\_Programmierung & Scripting\delphi\_ITCE\Tempater\Win32\Debug\ffmpeg-20180322-ed0e0fe-win64-static\bin>ffprobe.exe C:\Users\Anwender\Videos\CutErgebnis.mp4
ffprobe version N-90399-ged0e0fe102 Copyright (c) 2007-2018 the FFmpeg developers
  built with gcc 7.3.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
  libavutil      56. 11.100 / 56. 11.100
  libavcodec     58. 15.100 / 58. 15.100
  libavformat    58. 10.100 / 58. 10.100
  libavdevice    58.  2.100 / 58.  2.100
  libavfilter     7. 13.100 /  7. 13.100
  libswscale      5.  0.102 /  5.  0.102
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\Users\Anwender\Videos\CutErgebnis.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.9.100
    comment         : Captured with Snagit 13.1.3.7993
                    : Microphone - Mikrofon (Steam Streaming Microphone)
                    :
  Duration: 00:01:51.99, start: 0.015011, bitrate: 148 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1918x718 [SAR 1:1 DAR 959:359], 149 kb/s, 14.79 fps, 15 tbr, 15k tbn, 30 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 1 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

Try try add this option at the end of your video options to increase the queue size:

-max_muxing_queue_size 1024

This worked for me, but you may need a higher value like 2048 or even 4096. I found out about this here: https://discussion.mcebuddy2x.com/t/ffmpeg-bug-too-many-packets-buffered-for-output-stream/1148

I solved by adding this option (ffmpeg version 3.4.6):

-max_muxing_queue_size 9999

For example:

ffmpeg -i input.mp4 -max_muxing_queue_size 9999 out.mp4

This issue may have been "fixed" in a recent build of ffmpeg. However, the root cause appears to be faulty source file content and not ffmpeg.

TL;DR: There are 3 ways to solve this problem.

1. Choose a different source file
2. Apply ffmpeg command parameter (as others mentioned above) of -max_muxing_queue_size 9999 However, be warned this is resource intensive and depending on your system and how badly the source file is malformed, may cause ffmpeg to crash.
3. Build yourself a custom version of ffmpeg, using a nightly build released after November 23, 2020 (and hope for the best).

Details... Details... for inquiring minds...

-max_muxing_queue_size 9999 tells ffmpeg to allocate additional memory for caching video frames. What is basically happening is there's a problem with how the source file video frames are structured, and ffmpeg is trying to keep track of the early frames in the file until it can figure out how it's all supposed to be organized. Doing this means ffmpeg has to consume more memory. Sometimes, A LOT more. The "9999" is an arbitrary value that you can almost think of as setting it to infinity; meaning, you may run out of RAM using this approach (rare, but possible... and highly dependent on your hardware).

You can read more about the suspected cause via the original defect report here: https://trac.ffmpeg.org/ticket/6375

Or, more succinctly explained here: https://trac.ffmpeg.org/ticket/6375#comment:36

You will find the code changes of the October 29 commit that might fix it here (but again, remember this is not really ffmpeg's fault... so, quite frankly this is a band-aid fix... tho kudos to the dev who solved it... but the real fix is use a different source file!): https://github.com/FFmpeg/FFmpeg/commit/453b2f3c154f6b83221940ad411599ded91f7413

The same problem happened with me just recently. I tried so many solutions but was not able to fix this. Then I analyzed the error sentence; it says 'too many packets buffered', which means that when the recording was started or the video was made, at the given second, too many packets were used to record that moment. So I thought if I crop the video from the given second 'til the end and then tried to convert it, and it worked.

So below is the command to crop the video file. You can make adjustments according to requirement. Basic is your video file is corrupted. If you are OK with cropping a second from the file and use it, then this solution is OK.

Crop:

ffmpeg -i video.mp4 -ss 00:00:05 -t 00:03:14 -async 1 cut.mp4

Here is the command that I was trying to convert the file with when I encountered this issue.

Convert:

ffmpeg -i cut.mp4 -crf 32 output2.mp4

This was fixed after I upgraded from version 4.0.2_1 -> 4.4_2.

On Mac, run:

brew install ffmpeg

This will update it.

I was able to encode the faulty audio stream separately. Then I encoded the video and included the already-completed audio with -c:a copy.

(This is obviously a workaround rather than a proper fix, but it worked for me.)

In my case, my input file was generated by ffmpeg as well, I was concatenating (using concat demuxer method) multiple png images and was using -c:v copy, as a result, the video stream of the output file (which I used as the input file for the next operation and lead to this error) has a Format of PNG and not AVC or something else. I have read @MrPotatoHead's answer and after reading more into it, I have kinda made a sense of what was going on.

So I simple removed the -c:v copy in my first operation and the format of the video stream of my first operation became AVC and the error no longer appears when I try to use that output file as an input on my next operation.

I don't know if this is relevant to the problem here, but I was getting the 2 frames error while trying to hardsub a file with external subtitles. I tried various things and finally solved it in my case.

1. There was some issue with filter and copy not working together Solution - I just used copy
2. The 2 frames left in the queue on closing error Solution - Removed any commas (,) that were present in the name of my subtitle file

In my case :

i was using :

ffmpeg -i downloaded.mp4 -ss -to -async 1 -c:v copy trimmed.mp4 

to crop a portion of video ,

so simply removing the past -c:v copy wouldn't cause buffer issues