httpTakStreamingで利用しているsegment分割ですが、ちょっと動作をかえようと思っています。
現在の動作では、設定秒数以上で、動画のキーフレームがきた時点で分割するように調整してあります。
これを、キーフレームでなくても、指定時間以上経ったら分割する方向ですすめようと思います。
現状の動作では、たまにsegmentの長さが長くなっちゃいます。
上図でも1.0程度のセグメントもあれば、2秒超えているものもあります。
実験ではカメラとの相性もありますが、ひどいときには、4秒近いセグメントになることもありました。
サーバー内部での設定では、durationを1秒にしてあるので、4秒近いセグメントができているということは、4秒間動画のkeyframeがこなかったということになります。
このままでは、追いつかなくなった場合に、動画再生がとまってしまうという不具合が発生しまうので、flmデータの生成時に、keyFrameがこなくても指定してある以上の動画フレームを取得した場合に分割するように調整してみたいとおもいます。
さて、なぜkeyFrameが先頭にくるようにしているかというと、HttpLiveStreamingがベースだからです。
httpLiveStreamingの場合、先頭にキーフレームがこない場合は、次のようになるみたいです。(デバイス依存なので、確実にそうなるわけではないといっておきます。)
1:動画データをうけとった場合、映像が再生可能になるまで音声だけ流れます。
2:その後、映像が再生できるようになったら、動画として再生されます。
という動作になることがあります。
単に映像を見せるだけのサービスならまぁいいんですが、ここにお金が絡んでくると映像がみれないのに、お金を取られたという話が入ってきちゃうんですよね。
というわけで、確実に動画として始めから再生させるために、いろいろ調べるうちに、keyFrameを強制的に先頭になるようにするというのが、デフォルトになっていました。
さて、今回のHttpTakStreamingですが、flvデータの根幹的な部分の解釈を行う、BaseStream.asの中で、動画のkeyFrameを取得するまで、すべてのデータを捨てるようにしてあります。
という動作をするようにしてあるので、問題のあるデータがあったとしても、まぁ大丈夫な動作になるであろうということが期待できます。
で、これを書いている間にFlazrのプログラムをちょっと書き換えてみました。
で、実際にためしてみたところ次のようになりました。
ほぼすべてのデータが1.055秒のセグメントになっていますね。
動作もBuffer.length=2にしたときとほぼ同じ動作になった感じになりました。
めでたしめでたしといったところ。
0 件のコメント:
コメントを投稿