コンバート処理をマルチスレッド化したい。

とりあえず、安定したコンバートはできるようになった気がします。
30Mbyteほど、flvデータをコンバートしつづけましたが、いまのところバグはでていません。

なので、次の行程にすすみたいと思います。
次はコンバートの動作がおそいので、それを高速化したい件です。
確認方法が、rawビデオとコンバートビデオを出力するようにしておき、両者のずれが何秒ほどあるか？を目視で確認して、ずれを測るというひたすら面倒なことやっているわけですが、まぁ必要な処置でしょう。
あと、これやっとかないと処理途上でバッファ待ちがでて、動画がたびたび止まるという問題にもなってしまいますね。

さてxuggleのコンバートでは、はじめから、音声と映像のストリームをひらいた状況にしておくと、映像しかないデータがインプットになった場合。出力がいつまでたってもはじまらないという動作をします。
よって、新しいトラックをうけとったら、それに対応したパケットを開くようにするという処理をしているわけです。
ところがこの場合、あたらしいメディアデータをうけとったときに、その場でパケットを開いて処理しようとするので、動作がどうしても遅れてしまうみたいです。
また、１つのスレッドで複数のコンバートを走らせているというのもあり、処理に遅延が発生することがある模様です。

実際、11コンバートしたときには、30秒〜１分遅延があったみたいですが、２コンバートにしぼってみたところ6秒ほどの遅延で済んでしまったので、コンバート数が増えれば増えるほど、なにか詰まる原因があるみたいです。

で、考えた対策案
１：あらかじめ動画のみ、音声のみ、両方のコンテナを開いておいて、適宜切り替えて使う。(コンテナを開き直すという動作がなくなることで遅延の原因を取り除く。)
２：コンテナ開く部分をマルチスレッド化しておいて、開くことのオーバーヘッドを減らしておく。
３：リサンプリング、エンコード処理をマルチスレッド化することで、並列処理するようにしておく。

まぁ、当然といえば当然なやり方ですね。
とりあえずは、2,3のところからテストですかね。Thread.joinのメソッドをつかって、処理待ちするようにしてやれば、うまくいくか？