このサーバーからFlazrで落としたデータがやはりおかしいので、ずっと困ってます。
というわけで、ちょっと調べてみたので、記録の記事にしておきます。
■その１：h.264じゃないflvデータ
FlashMediaServerにデフォルトでvodについてくるsample.flvについて確認してみました。
Flazrをつかってダウンロードを実行すると、100%同じファイルになりました。
このflvデータ、ちょっと特殊でaudio→videoの順にデータがならんでいるみたいです。
また、videoのデータはtimestampが0からはじまらないというかわったファイルになっていました。
ダウンロードデータを以前つくった、xuggleのテストプログラムに突っ込んだところ
問題なく変換できました。
よって、たぶん普通のflvデータなら、問題なくflazrでダウンロードできて処理できると思います。
■その２：h.264のファイル
以前youtubeで拾ったマリオギャラクシー２のプロモーション動画をFlashMediaServerのvodにおいてみた。
application/vod/media/のディレクトリにおくだけでOKで再生するときのstreamNameをファイル名(拡張子をのぞく？)で実行すると視聴できます。
同じところにflazrをむけて動作させてみた。
するとなぜか、audioとvideoの先頭のデータだけTimestampが0xFF FF FEになっていました。
原因は不明ですが、FlashPlayerでは普通に見れました。
まぁ、これだけなら、Timestampが0xFF FF FEになっているデータをみつけたら、0x00 00 00に変更してやればいいという話になります。
■その３：FlashMediaLiveEncoderで流しているデータ
自分の映像をFlashMediaLiveEncoderで流してみました。音声はなし。
するとこうなった。
以下データは
[先頭タグ]:タイムスタンプ + bodySizeとなってます。
meta:16777214 + 513
video:16777214 + 57
video:16777214 + 25315
video:16777214 + 4760
video:16777214 + 425
video:16777214 + 629
video:16777214 + 591
video:16777214 + 6420
video:16777214 + 1164
video:16777214 + 1249
video:16777214 + 1197
video:16777214 + 8978
video:16777214 + 1427
video:16777214 + 1649
video:16777214 + 1557
video:16777214 + 9077
video:16777214 + 2022
video:16777214 + 2505
video:16777214 + 2214
video:16777214 + 10924
video:16777214 + 3077
video:16777214 + 3258
video:16777214 + 2809
video:16777214 + 11334
video:16777214 + 2639
video:16777214 + 3216
video:16777214 + 2804
video:16777214 + 10719
video:16777214 + 2221
video:16777214 + 2820
video:16777214 + 2530
video:16777214 + 10440
video:16777214 + 2288
video:16777214 + 2823
video:16777214 + 2446
video:16777214 + 13142
video:16777214 + 4423
video:16777214 + 4754
video:16777214 + 4276
video:16777214 + 12695
video:16777214 + 3666
video:16777214 + 4389
video:16777214 + 3866
video:16777214 + 10751
video:16777214 + 2444
video:16777214 + 3033
video:16777214 + 2557
video:16777214 + 11655
video:16777214 + 2786
video:16777214 + 3042
video:16777214 + 2780
video:16777214 + 12388
video:16777214 + 2221
video:16777214 + 2736
video:16777214 + 2249
video:16777214 + 10721
video:16777214 + 2581
video:16777214 + 3039
video:16777214 + 2839
video:16777214 + 13249
video:16777214 + 3955
video:16777214 + 4452
video:16777214 + 3796
video:16777214 + 12503
video:16777214 + 3495
video:16777214 + 4224
video:16777214 + 3701
video:16777214 + 12482
video:16777214 + 2011
video:16777214 + 2316
video:16777214 + 2073
video:16777214 + 12082
video:16777214 + 3651
video:16777214 + 3970
video:16777214 + 3567
video:16777214 + 10431
video:16777214 + 2145
video:16777214 + 2601
video:16777214 + 2362
video:16777214 + 12563
video:16777214 + 1567
video:16777214 + 1267
video:16777214 + 1969
video:16777214 + 11633
video:16777214 + 3379
video:16777214 + 3249
video:16777214 + 1883
video:16777214 + 12011
video:16777214 + 1790
video:16777214 + 2532
video:16777214 + 3526
video:16777214 + 10777
video:16777214 + 2939
video:16777214 + 3245
video:16777214 + 2837
video:16777214 + 10400
video:16777214 + 2611
video:16777214 + 2997
audio:16777214 + 157
audio:24 + 157
video:45 + 2691
audio:50 + 157
audio:76 + 157
audio:102 + 157
video:113 + 10604
audio:26957 + 157
audio:26983 + 157
video:27009 + 3304
audio:27009 + 157
audio:27036 + 157
audio:27062 + 157
video:27077 + 3887
audio:27088 + 157
audio:27114 + 157
先頭のvideo 16777214のタイムスタンプが先ほどの0xFF FF FEです。
なんかものすごく大量にvideoの不明データがあります。xuggleの確認動作のプログラムでデコードさせようとしても、当然うまくいきません。
そしてデータがやっときたな・・・とおもっても、timestampが100前後からいきなり26000に飛んでます。
わけわからないですね。
とりあえずh.264動画の場合動画のはじめのデータが再生に必要な情報(サイズや利用機能)の記述なので、このデータは是が非でもみつけなくてはいけません。
wiresharkの通信記録から、一致するデータを探し出したところvideoの先頭データ(赤くしてるところ)だけが該当していました。なので、はじめのよくわからない0xFF FF FEのタイムスタンプのついているデータを無下にしてはいけないっぽいです。
また、audioはmp3に指定してあるのですが、mp3は、0.026...秒ごとにデータ化されていることがわかっています。
audioだけ抜き出すと
16777214(-2) 24 50 76 102 26957(128?) 26983(156?)と一応26ずつ増えている模様です。
一応、このずれている数値ですが、aggregateMessageからflazrの解析の性で算出されているみたいです。なので、その部分すくなくとも値のジャンプが発生しないように調整したら、netStream.appendBytesにまわすことも、xuggleの変換にまわすこともできるようになります。
ただ、両方ともきちんとは動作しないみたいです。
1:appendBytesの方は、まぁきちんと動作するのですが、はじめの方、ちょうど0xFF FF FEの部分で、映像が早送りみたいになります。
その後は中途フレームから再生させても一応大丈夫なデータとして処理できる模様です。
2-1:xuggleの変換動作では、先頭の20個ほど動画フレームのデコードに失敗します。
2-2:音声データもあるデータの場合、デコード失敗が続いたあとに音声データがくるわけですが、xuggleの動作として音声デコーダーの取得に失敗します。(nullになる)データがくるのが遅すぎる？
2-3:変換をつづけていると、パケットデータの読み込みに失敗することがある。
３つとも、IURLProtocolHandlerの読み込みまわりがおかしいので、ffmpegのnative動作？が解析ミスってるみたいです。
なんなんだろう・・・これほんと邪魔なんですけど。
現状こんなところです。
さて、どうやって調査するかなぁ・・・
いまのところ想定している調査方法は・・・
1:wiresharkで送信しているデータを確認する。
2:mirror機能をつかってFlashMediaServerとred5(もしくはwowza)にむけてデータをなげて、両方からダウンロードさせる。
メディアデータの構成を確認してどのように対応しているか確認する。(いまのところrtmpサーバーはメディアのコンテナ変換はしそうだが、エンコードデコードはできないっぽいため。)
3:Flazrの機能をつかってh.264を含むflvをFlashMediaServerにpublishしてやって、そのデータをダウンロードして確認する。
これくらいですかね・・・３つ目が一番手軽そう・・・
0 件のコメント:
コメントを投稿