データ変換まわりのバグとり作業。

さらにつっこんでみようと思う。

いい加減このバグはつぶしたいところです。
(調査すること、30分くらい)
で、バグはとれました。やったー。

まずは、xuggleの動作を確認してみました。
先ほどのxuggle-testのプロジェクトのログから、動作エラーがでたときについて調査してみました。
するとエラーがでる直前が次のようになっています。

---ログ---

ビデオパケットでコード完了。

ビデオパケットでコード完了。

読み込みします。32768

223

229599

読み込みします。32545

0

229599

18:51:18.807 [Thread-1] ERROR org.ffmpeg - [h264 @ 0x7fac2480aa00] AVC: nal size 18542

18:51:18.810 [Thread-1] ERROR org.ffmpeg - [h264 @ 0x7fac2480aa00] no frame!

vデコード失敗

---ログここまで---

どうやら32768バイト要求をしたものの、応答で返答できたのが、223バイト(動画データとして成立してません。)

仕方ないので再度動画データを要求しています。32545バイト。

ファイルの終端にきているので、0バイトしか応答できていません。

そして、問題のエラーが発生しています。

　推測ですが

・２度までトライする

・それがおわったらデコード処理にまわす。

・このときに必要なデータがそろっていない場合はエラーがでる。

かと思いました。

さて、これをふまえて本番側の動作ログを確認してみました、すると小さなデータの読み込みを２度実行して失敗しています。(両方2kbyte程度)

過去の失敗からすると、h.264のキーフレーム部(10kbyte以上あるところ)

となっているので、どうやら、２度読み込みのサイズが小さすぎてデータをうまく拾えていないのが原因みたいですね。

で、対処方法ですがIContainerのsetInputBufferLength(long)メソッドで読み込み時の最低バッファ数を指定できるみたいなので、これで対処できそうです。大きな数値をいれればいいのですが、この数値はエンコード環境に左右されそうなので、逆に15バイトに設定しておいて、タグのサイズを毎回解析しながら動作してもらうことにします。

とりあえず、変更を加えてみたところ、エラーでずにしばらく動作できたので、これでよしとしていきたいと思います。

さて、次の作業はマルチスレッド化かな・・・応答動作速度が飛躍的に向上するからね。