xuggleのコンテナ経由せずに動画データを取り込めないか？その１

xuggleの変換はやりやすいのですが、どうもバグがあるみたいで、無理矢理いれた最新のgitバージョンから起こしたプログラムでは、ffmpegから要求されるデータ量が数MByteになってしまったり、bad pictureのエラーがでてとまったりしてしまいます。
(google codeにあがっている方ではいまのところこの問題は発生していません・・・*1)

ですが、やっぱり最新版ので動作させたいと思いますので対抗策を考えてみました。

一番手っ取り早そうなのはIContainerの読み込み部分の動作を解析して問題点を暴くことですが、さすがにそこまでマニアックなことはできないので、もっと簡単なところからせめて見たいと思います。

そこで今回は入力Containerの読み込み前と後でなにがかわるか確認してみました。
基本知識として、FLVファイルは
[ヘッダ(タイプ + データ量 + タイムスタンプ + トラック番号)(11バイト)] + [パケット情報(コーデックその他)(物による)] + [データ本体(任意)] + [末尾データ量]という形になっています。

ですから、データ本体とタイムスタンプ、コーデック情報あたりがセットになったオブジェクトになってるんじゃね？と思った次第で調べてみました。

まずはデータ本体

FLVデータの構造はググったら、調べることができるので、青マーカーで入力されたデータのうちメディアデータ本体がどこにあるか調べてみました。もののみごとに対応していますね。

つづいてタイムスタンプ

青マーカーで同じくかこったところがタイムスタンプの指定です、生データ側では、16進数になっていますが
0x0514 -> 1300
0x0543 -> 1347
とうまく対応しています。

というわけで、別にIContainerを経由しなくてもつくれそうな気がしてきました。

戯れ言*1
このブログの記事そのものも不確定要素満載の戯れ言ですが、その中での戯れ言。
google codeにあがっているxuggleとgithubにあがっているxuggleの違いについてなんですが、いまのところ次のような疑惑があります。
１：flv読み込み動作の安定性の件
githubのコードの場合、読み込みをつづけていると急に6Mくらいの大きなデータの読み込み要求がでて、変換がとまってしまう上に、読み込みきったらxuggleのcppで書かれた部分がデコードミスを起こして壊れてしまう。
google code側では、問題はでず。github側では、問題が発生する。

２：flvで中途でトラックが追加されたときの動作の件
flvフォーマットは、このタイムスタンプから、このメディアデータを再生するようにという定義になっています。なので、映像データは連続してくるのに、音声データはとびとびにとんでくるという状況が発生します。(マイクのループバック回避のために、microphoneにslience設定をいれていたりすると発生します。)
このときに後から追加されたトラックを無視してしまうみたいです。
google code側では問題なく動作する。github側では、問題が発生する。

３：対応フォーマットが違う。
一番大きいのは、vp8が対応している点、あとで余力があったらwebMのストリーミングのセグメント作成もさせてみたいので、できたらgithub版を使いたい。
google code側vpxは読み込みのみ、github版出力もOK
等々

そんなわけで、なんとかして、github版で安定動作させたいなと思っております。
ではでは〜