ffmpegやavconvのパフォーマンス改善案ってどんなのあったっけ？

　ffmpegやavconvは動画を扱うサイトなら、だいたいつかっているopenSource界の重鎮です。で、会社でこのコンバートまわりのチューニングする必要がでてきそうなので、その前にいままでを振り返ってなにができるのか、ブログにまとめておきたいと思います。いままでも何回か書いたことあるので、重複にはなりますが、まぁ自分用のまとめってことで・・・
　僕の領分はrtmpとflv、mp4、mp3、mpegts、mkvこのあたりです。あとはmidiってのも扱ったことがあります。

　つづいてターゲットとなるソース。rtmpに流れているデータが対象になります。特徴としては、rtmp→flvの変換は非常に容易になっていること。ただし、flvはtimestampが絶対値で書かれているのに対し、rtmpでは相対かつ映像と音声で扱いが独立していること。
中途で片方のメディアデータが欠損することも別のコーデックや設定に切り替わることも許可していること。こんな感じです。
　出力周りの要件としては、mp4、webm(mkv)、flv、httpLiveStreaming(mpegts、mp3)といったところです。
　動作の要件としては、httpLiveStreamingに変換してライブで映像を流すなら、なるべくリアルタイムな動作ができるように調整する必要あるし、同じhttpLiveStreamingにするとしてもVOD用のファイルをつくるなら、セグメントの大きさとかに注意して帯域が乱高下するようなデバイスでも必要なデータバッファが保持できるような構成にするとか考慮できます。

　で、パフォーマンスをあげましょう。
１：flvデータを事前に修正してやったら負荷が下がる。
データの欠損や並び順がおかしいことがあるのでcodec copyで一度変換に通してやることでそのあたりの修正をいれることが可能です。
flvtoolをつかったり、codec copyをつかった変換プログラムに通したり、自力で修正したりすればいいです。
codec copyを使う場合の注意ですが、できたらコンテナ変換した方が修正できる可能性があがります。(そうでない場合は中途で変換がとまったりする。)
自力で修正する件に関してはやった実績があります。

２：pthreadを有効にせず負荷をさげる。
pthreadを使うと、マルチスレッド動作になってパフォーマンスがあがります。
言い換えると、マルチスレッドになる分、処理の間にthreadごとの動作を調停するための処理が追加されたりするわけです。
手持ちの動画を最高の画質でコンバートするという要件だったら、つけておくと高速化できていいわけですが、１つのサーバーで複数のデータの変換を実施するみたいなことをやる場合はむしろ余計な処理が増えて邪魔です。
なので、pthreadを抜いてffmpegを使うのも「あり」だと思っています。
ただし、目立った改善を目にしたことはありません。xuggleの動作で元々はいっているffmpeg動作側にpthreadはいっているみたいですが、むしろコレが足を引っ張っていたことがあります。

３：ffmpegのパラメーターの順番をかえることで負荷を下げる。
ffmpegのパラメーター配置では、変換の開始位置を変更したり、入力ソースのフォーマットをあらかじめ指定したりすることで、動作効率をあげることができます。
-ssパラメーターをいじるのが一番わかりやすい例だと思います。

こんなもんだっけ？なんかもっとあった気がするんだが・・・思い出したら追記していこう。