で、以前webで見つけた。
これを私は重宝しています。
前にもブログに書いたことあったはずです。
で、ですが、このswfプレーヤー、なぜかTakStreamingとの相性がすこぶるわるかったんです。
再生してもうまく動作しなかったり、いろいろと不具合があったわけですが、やっと理由がわかりました。
たぶん、FlashPlayer11以降によるh.264の映像出力全般にいえることだと思います。
１つ目、h.264のmediaSequenceHeaderがキーフレームごとにくる。
mediaSequenceHeaderというのは、h.264やaacのデータの特殊なflvTagです。詳しくは学習がすすんでいないのですが、mediaに関する特別な情報が載っているみたいです。HttpTakStreamingではこのデータを伝搬するために、flhファイルに必要があれば、追記してあります。FlashMediaLiveEncoderで放送した場合や、Flazrをつかってflvデータからライブストリーミングをした場合には、かならず先頭にtimestamp0でやってくるのですが、Flashのh.264放送では、キーフレームごとに送信されるみたいです。
いままでのtakFlazrのプログラムでは、mediaSequenceHeaderはうけとったまま保持していました。これだと、このheaderがはいっている場合にtimestampが0にならず、複合したときに矛盾がでるみたいです。
２つ目、放送をあきらめるタイミングが早すぎる。
TranscodeWriterの中で、ある程度データ転送がない場合に、動作していないと判定して、とめてやり直す処理があります。
このソースの80行目あたりです。
このあきらめる処理、現状の動作では必要ありません。が、いれたままにしてあります。
どうして入っているかというと、ffmpegやxuggleにつないでコンバートさせるとき、コンバートするのをあきらめるタイミングがわからないため、こうなっています。
いままでは、メディアデータの書き込みが1.5秒ない場合は、動作がおかしくなったと判定して、あきらめるようにしていたのですが、Flashからのflvの出力はこの部分が少々あやしくなっていると思ったので、とりいそぎ3秒にあげてみました。
というわけで、メディアデータの取り扱いを見直すことで、また１つ動作が安定したと思います。
0 件のコメント:
コメントを投稿