2013年9月20日金曜日

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

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

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

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

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

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

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

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

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


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

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

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

2013年9月13日金曜日

mavenのxuggleについて

xuggleというライブラリがあります。
javaでのffmpegを扱うためのライブラリです。
xuggleそのものは2、3年前から知っていて、僕が借りているsakuraのvpsにもxuggleをソースコードからインストールしてつかっていたりしてます。

このxuggle、インストールするのが非常に厄介なので配信ツールみたいな一般のユーザーに配るプログラムには向いていないなぁと思っていたのですが、なんと、mavenで公開されているjarファイルには、JNIで読み込むライブラリが同梱されています。(40MByteほどサイズあるけど)

しかも同梱されているライブラリはwindows用、mac用、linux用と3つきちんと入っています。(40MByteほどサイズあるけど)

一応、iMac、windowsXP、CentOSで動作することを確認してあります。

ちなみに同梱されているライブラリはGPLバージョンでh264やmp3、aacも扱うことが可能みたいです。

変換用のライブラリがわざわざコンパイルしなくても利用できるのは非常にありがたいことですね。


ついでにいうと、変換プログラムを動作させるのにシステムライブラリを汚さないところもGoodだとおもいます。


惜しいところはどうもxuggleは最近下火になっているんですよね。

では、今日もはりきってプログラムしていこう。