Your conversion stops with Too many packets buffered for output stream before anything is written to the output file. This is a muxing queue overflow. FFmpeg buffers the packets that arrive first while it waits for every output stream to be ready. When the buffer grows past its limit, the job stops. The fix is usually one extra option. If you do not need to re-encode, copying every stream avoids the wait completely.

A container stores its streams (video, audio and so on) interleaved in roughly time order. The muxer, the part that writes the container, can start writing only after every output stream has been set up. Until then, FFmpeg holds the packets that have already arrived in a buffer called the muxing queue. Once the queued data passes a size threshold (50 MB per stream by default, set with -muxing_queue_data_threshold), -max_muxing_queue_size sets how many packets that queue may hold. If one stream is still not ready while packets for the other streams keep arriving, the queue passes its limit and FFmpeg stops with this error.

Why This Happens

The error appears when the first frame of a stream that is re-encoded (or filtered) arrives late. A stream copied with -c copy is ready at once. A re-encoded stream is ready only when its first frame reaches the encoder. If the video’s first frame is late (for example, the video starts later than the audio, or a filter holds frames back), the audio packets that arrive in the meantime pile up in the muxing queue. With enough delay the queue overflows and the job fails. This happens whether the audio is copied or re-encoded. A job that copies every stream with -c copy rarely hits it, because every stream is ready from the start.

The error does not mean the file is corrupt. The streams become ready at different times.

Fix 1: Raise the Muxing Queue Size

Give the muxing queue more room with -max_muxing_queue_size. It is an output option, so it goes before the output file. Keep the codec options from your original command and add the larger queue:

ffmpeg -i input.mp4 -max_muxing_queue_size 1024 -c:v libx264 -c:a copy output.mp4
  • -max_muxing_queue_size 1024 — allow up to 1024 packets to wait in the muxing queue
  • -c:v libx264 -c:a copy — an example that re-encodes the video and copies the audio (keep the codec options from your original command)

A larger queue uses more memory while the job runs, but FFmpeg can then hold enough packets until the late stream is ready. Start at 1024.

If 1024 still fails, raise the value further. The same applies when the audio is re-encoded too:

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

Fix 2: Copy Every Stream When You Don’t Need to Re-encode

The wait comes from re-encoded streams. If you do not need to change the codecs, copy every stream. Copied streams are ready from the start, so there is no wait.

ffmpeg -i input.mp4 -map 0 -c copy output.mp4
  • -map 0 — include every stream of the input (without it, FFmpeg picks only one video and one audio stream)
  • -c copy — copy every output stream without re-encoding (lossless, fast)

If you need to re-encode (to compress or convert), raise the queue with -max_muxing_queue_size as in Fix 1.

Summary

Situation What to do
Error while re-encoding Packets for the other streams overflow while FFmpeg waits for a stream whose first frame is late
First fix Add -max_muxing_queue_size 1024 before the output
Still overflowing at 1024 Raise it to -max_muxing_queue_size 4096
No re-encoding needed Copy every stream with -map 0 -c copy

FAQ

Where do I put -max_muxing_queue_size in the command?

It is an output option. Put it after the input(s) and before the output file, for example ffmpeg -i input.mp4 -max_muxing_queue_size 1024 -c:v libx264 -c:a copy output.mp4. It sets the queue of 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 until every stream is ready. It does not affect the encoded quality. The cost is a little more RAM while the job runs.

Why doesn’t it happen when I only use -c copy?

Copied streams are ready from the start. The wait lasts only until the first frame of a re-encoded stream reaches its encoder. Re-encoding the audio as well does not help: if the video’s first frame is late, the queue overflows the same way.

What value should I start with?

Start at 1024. If the error remains, try 4096. If you do not need to re-encode, copy every stream with -c copy (Fix 2); then this error almost never occurs.