ffmpegでmax_muxing_queue_sizeを指定したらメモリーを大量に消費してしまうのだが

ビデオファイルのサイズを小さくしようとエンコードしまくっています。最近はffmpegを使っています。
ところが Too many packets buffered for output stream ... とエラーが出てffmpegが終了してしまうファイルがありました。
解決しようとmax_muxing_queue_sizeオプションを指定すると・・・
メモリーを大量消費してくれました。

とあるファイルをffmpegでエンコードしようとすると

Too many packets buffered for output stream 0:1.

とエラーが出て終了してしまいます。

エラーメッセージの通り何かしらバッファーが溢れているのでしょう。
どのバッファーだろう？いろんなバッファがあるのでオプション指定がわかりません。
調べると最近のチケットにありました。

#6375 reopened defect
[bug][regression] Too many packets buffered for output stream
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.

そうです。これこれ。

なにやら3.3系のバージョンで生じているようです。3.2系では出ないみたい。
そして肝心の解決方法はオプション "-max_muxing_queue_size"を指定すればよいようです。
値はどれくらいでしょうか？400では解決しない場合があるようです。9999ならOKとか。
私の場合は400では解決せず500にするとエラーが無くなりました。大きな値を指定しても無駄なので500で様子を見る事にします。
という事で次のオプションを追加しました。
-max_muxing_queue_size 500

これで解決・・・と思ったら・・・
Windows 10がメモリー不足で落ちました。
エンコードマシンのメモリーは16GB搭載しています。普段は使いきる事が無いので仮想メモリーは使っていませんでした。
仮想メモリーをシステム管理に設定してもう一度やってみます。
問題のファイルのエンコードを始めると・・・

ぐんぐんメモリーを使っていきます。コミット済みで約20GBで安定してきました。
ちょっと・・・なんでこんなにメモリー使うの？

何とかエンコードは進行しているようです。
ここでこの現象を検索しようとchromeを立ち上げると・・・スワップ発生！
大昔のPCの様に動作が遅い・・・chromeが反応しない・・・文字が打てない・・・
メモリー16GBでSSDのマシンなのにこんなに遅くなるんだぁ、とちょっと感動。

このオプションは出力するパケットをディスクへ書き込む前にメモリーに貯め込みます。そのためメモリーを消費するのはわかるのですが・・・500パケットの指定で10GBほど消費している事になるんだけど？元のファイル１GBなんだけど？

このオプションは緊急避難で使うのが良いようです。

#元ファイルのタイムスタンプがおかしいのかもしれません。
#結局 バージョン3.2.4を使ってエンコードしました。