マルチ変換について

先ほど、マルチ変換について調査してみた。

https://github.com/taktod/streaming/tree/streaming
ソースのベースはこちら。
まぁ、プログラムの更新をすすめながらやって今日の変更分はまだpushしていないのですけど

１：
mpegtsとflv、webmの320x240の出力を実行する動作を走らせていたのですが、はじめの状態ではクオリティが悲惨なものになりました。
どうやら、om.ttProject.xuggle.ConvertManagerのエンコードまわりの動作をマルチスレッドにしているのが、よろしくないみたいです。この辺の処理、マルチスレッドで動作させておくと、ノイズがはしるみたいになるみたいですね。

２：
というわけでエンコードの部分だけ、マルチスレッドはずしてみました。
そうすると、映像のクオリティはなかなかなものになりました。
webmは、そもそもvorbisの動作があやしかったので、変換対象から撤去して、mpegtsとflvだけ出力させていましたが、いい感じでした。

３：
つづいて、640x480で試してみました。
前と同じくmpegtsとflvの出力を実施してみましたが、今度は、mpegtsもflvも遅延するようになりました。
あまり処理が増えると遅延が発生するみたいです。マルチスレッド処理にxuggleが対応していないみたいですね。

４：
では、jvmをわけちゃえということで、flazrのプログラム２つにしてみました。
両方とも動作はまぁ良好だったわけですが、640x480で２つ実施したときと同じように、遅延が酷くなりました。リサンプルとエンコードの部分は共有しているので、コンテナ書き出しだけ重複するはずですが、動作がいまいちでしたね。

５：
では、単体では？ということになりましたので、ためしてみたところ、単体だと問題なく動作しました。
flvのh.264 + mp3の動作640x480でやったところ遅延がほぼなく動作しました。むしろ微妙に追いつきかけてました。
コンテナに書き込むのって微妙に重いのだろうか・・・
コンテナから読み込む部分、自力でやるようにしたので、コンテナに書き込む部分も自力化してしまえばもしかしたらいいかもしれません。

６：
320x240 160x120をh.264 mp3でflvとmpegtsで計４つつくってみました。
すると動作がいい感じになりました。あとがんばれそうな部分はコンテナの書き込みの部分だけ、自力化すると高速になるかも・・・といったところですね。

変換パラメーターとかいじればさらに動作がよくなるかもしれません。
結論としては
・xuggleはマルチスレッドつかわない方がよさそう。
・変換さえおいつくなら複数コンバート可能っぽい。
・jvmを別にしてもxuggleを複数同時にはしらせるのはお勧めしない。
やるならショボいサーバーを並べた方がよさそう。といったところでしょうかね。

ちなみに、ffmpegを複数プロセス同時に走らせるのは実は特に問題ないです。
全く違うコーデックの出力をいくつもつくるなら、xuggleつかうより、processBuilderをつかって、ffmpegを外部プロセス扱いにして動作させちゃった方が楽だと思います。

今日の戯れ言はこんなところで・・・