Your conversion runs for a while and then aborts with Too many packets buffered for output stream. This is a muxing queue overflow: FFmpeg buffers packets for an output stream while it waits for every stream to be initialized and interleaved, and when that buffer grows past its limit the job aborts. The fix is usually a one-flag change, and understanding why it happens tells you when a re-encode is the cleaner answer. This article covers both.

Tested with: FFmpeg 8.1

What You’ll Learn

  • What the muxing queue is and why it overflows
  • How to raise the limit with -max_muxing_queue_size
  • Why poor interleaving in the input triggers the error during stream copy
  • Why re-encoding instead of copying often resolves it for good
  • How to pick a sensible queue size

The core idea: a container interleaves streams (video, audio, …) together in roughly time order, and the muxer can only start writing once every output stream has been initialized. While it waits, FFmpeg buffers the packets it has already read for a stream in the muxing queue. -max_muxing_queue_size sets how many packets that buffer may hold; if one stream produces far more packets than the muxer can interleave yet, the buffer overflows its cap and FFmpeg stops with this error.

Why This Happens

The error almost always shows up during stream copy (-c copy), where FFmpeg passes packets through untouched. Because it isn’t re-encoding, it can’t adjust timing — it must hand the muxer packets in an order it can interleave. If the input is poorly interleaved (for example, a long run of video packets before any audio, or timestamps that jump around), FFmpeg keeps reading and buffering one stream’s packets while it waits for the other to catch up. With enough lag, that buffer overflows the default muxing queue size and the job fails.

In short, it is not corruption — it is a timing/interleaving mismatch between the streams and what the output muxer expects.

Fix 1: Raise the Muxing Queue Size

The direct fix is to give the muxing queue more room with -max_muxing_queue_size. This is an output option, so it goes before the output file. With a stream copy you keep -c copy and just raise the queue:

ffmpeg -i input.mp4 -max_muxing_queue_size 1024 -c copy output.mp4
  • -max_muxing_queue_size 1024 — allow up to 1024 packets to wait in the muxing queue
  • -c copy — keep the streams as-is (lossless, fast), only enlarging the buffer

A larger queue costs more memory while running, but it lets FFmpeg hold enough packets to bridge the gap between the lagging streams. Start at 1024, and only go higher if the error persists.

If raising the queue on a copy still fails, re-encoding usually resolves it — decoding and re-encoding regenerates clean interleaving (see Fix 2). A combined option that pairs a larger queue with a re-encode handles most stubborn cases:

ffmpeg -i input.mp4 -max_muxing_queue_size 4096 -c:v libx264 -c:a aac output.mp4

Fix 2: Re-encode Instead of Copying

Because the overflow is driven by the input’s interleaving, re-encoding rather than copying often resolves it outright. When FFmpeg decodes and re-encodes, it regenerates timestamps and writes a cleanly interleaved output, so the muxer no longer has to buffer one stream while waiting on another.

ffmpeg -i input.mp4 -c:v libx264 -c:a aac output.mp4
  • -c:v libx264 — re-encode video to H.264 with regular keyframes and timing
  • -c:a aac — re-encode audio to AAC, interleaved alongside the video

If you specifically need to copy without re-encoding (to stay lossless and fast), keep -c copy and lean on -max_muxing_queue_size from Fix 1 instead. Re-encoding is the more robust choice when quality loss from a single transcode is acceptable.

Summary

SituationWhat to do
Error during -c copyInput is poorly interleaved — buffer is overflowing
First fix (stay lossless)Add -max_muxing_queue_size 1024 with -c copy before the output
Copy still overflowingRaise the queue and re-encode: -max_muxing_queue_size 4096 -c:v libx264 -c:a aac
Want it gone for goodRe-encode: -c:v libx264 -c:a aac regenerates clean interleaving

FAQ

Where do I put -max_muxing_queue_size in the command?

It is an output option, so place it after the input(s) and before the output file — for example ffmpeg -i input.mp4 -max_muxing_queue_size 1024 -c copy output.mp4. It controls the queue for the output muxer, not the input.

Does a bigger queue size hurt quality?

No. -max_muxing_queue_size only changes how many packets FFmpeg may hold in memory while interleaving. It has no effect on the encoded quality — it just prevents the overflow. The trade-off is a little more RAM while the job runs.

Why does -c copy fail but re-encoding works?

With -c copy FFmpeg can’t adjust timing, so a poorly interleaved input forces it to buffer one stream heavily. Re-encoding regenerates timestamps and produces evenly interleaved output, removing the need for deep buffering and so avoiding the overflow entirely.

What value should I start with?

Start at 1024. If the error persists on a particularly bad file, jump to 4096. There is rarely a need to go much higher than that; if even 4096 overflows, re-encoding (Fix 2) is the more reliable path.

Tested with FFmpeg 8.1 — verified with our command-check script
Primary sources: ffmpeg.org/ffmpeg.html / ffmpeg.org/ffmpeg-codecs.html