メディアデータの高速変換に挑戦してみたい。

この記事は今週末ちょっとやってみようと思っていることへの先駆けです。
ブログを書いた時点ではきっちりした検証はしていませんことを先に書かせていただきます。

https://github.com/taktod/myLib/blob/217bc0acb2d5165f4c0941d7dfd2534526156b0f/myLib.xuggle.flv/src/test/java/com/ttProject/xuggle/flv/test/MultiCoderTest.java
こちらのプログラムのh263avcMultiThreadTest2の動作・・・
実行すると５秒だけ、h263のflvとavcのflvを並行して作成します。
できるデータは黒字に白で時間が表示されるflvになります。

実際に実行してみると、avcの方だけわずかに短いデータになります。

内部処理でsleep値を5にしてありますが、始めは100にしていました。
100にするとavcの方だけめちゃくちゃ短いデータになります。(２秒くらい？)

このことから推測するに、どうやらavcの変換でははじめにフレームが大量に送られてこないと変換が始まらない可能性があります。

さて、100ミリ秒に設定してあったということは、10fps程度のデータを流し込んでいたことになります。
5ミリ秒に設定したということは(たぶん実際はそこまで速度でていないはずですが・・・) 200fpsでていたことになります。

10fpsを素直に変換すると3秒ほど遅延する。
200fpsを変換するとほぼ遅延しない。

さて、会社でやっているhttpLiveStreamingへの変換ですが、入力flvと出力mpegtsのtimestampを比較するとおおよそ2秒〜3秒遅延します。
rtmpのfpsですが、最高で15fps程度と・・・
ん？どこかで聞いたことあるような遅延秒数ですね。


というわけで、もしかするとh264(avc)への変換ですが、入力ソースが仮に10fpsだとしても、パケットをねつ造して(同じ画像を重ねがけして)100fpsとしてコンバートに回してやればもしかしたら変換遅延を0に近づけることが可能なのではないでしょうか？

まぁ、そんなことするとCPUが異常に必要になったり変換が崩れたりするかもしれませんが、ちょっと週末時間があるときに試したいな・・・と思う次第です。

つくったら誰か買ってくれないかなぁ。
ではでは〜