前からおいておきたいな・・・とおもっていたwonderflにHttpTakStreamingのプレーヤーを設置しました。
http://wonderfl.net/c/9VnJ
んで、youtubeのFinalFantasy9のBGMでも流しながら実験していたのですが、どうも音がとぎれることがあった・・・
おかしいなと思って調べてみたところ、どうやら原因はリストファイルへのアクセスを頻繁に実行しすぎるためみたいでした。
もともと0.5秒に1度データを取得しにいく形だったのですが、これを1.2秒ごとに変更したところなんとかなったっぽいです。
いくつかわかったことがあるので、書いておきます。
1:Flashからダウンロード要求を発行しすぎると、詰まることがありえる。
chromeのNetWorkをみてて気づいたのですが、メディアデータをDL後にindexファイルのDLが詰まっていました。どうやら、タイマーの間隔をつめすぎていたみたいです。0.5秒は無茶だったという。
もしくは処理完了してから、indexファイルの読み込みを要求するように書き換えないとだめですね。
とりあえず。0.5秒→1.2秒にしたらなんとかなった模様です。
この設定ちょっとまずいんですけどね。
2:FlashMediaLiveEncoderの出力データのキーフレーム間隔が非常に広いみたいです。
各mediaデータの生成タイミングは、設定間隔以上で動画のキーフレームがきたら・・・という条件にしてあります。
で、出力データをしらべてみたところ、200フレーム以上はなれてkeyFrameがくるようになっていました。
14秒ごとくらいの間隔?設定間隔を1.2秒にしていたので、もっと小さなデータがながれてくることを期待していたんですが・・・
ちなみに先ほどのちょっとまずいという件は、もし、キーフレームの密度が高い放送をやってしまうと、メディアデータの間隔が、ちょうど1.2秒になります。
タイマーも1.2秒だと、下手すると、ファイルをうまく受け取れない可能性が・・・
というわけで、リアルタイム性を押し出そうとおもったら、ちょっとエンコードして、キーフレームの間隔狭めておかないとだめですね。
com.ttProject.xuggle.out.flvのパッケージのクラス準備しなきゃだめかもw。
とはいえ、変換をかませるとそれだけで遅延の原因にもなりかねないし・・・どうなんだろう。
とりあえず、やらないといけないことは・・・
1:エンコード間隔を3秒程度に変換しておく。
2:HttpTakStreamingを生データから作成ではなく、xuggle変換後の出力にする?(リアルタイムに近づけるなら。)
それか、innerFrameのところで切っても問題なく再生できるような仕組みを考える。
3:Flash側の取得動作まわりのもろもろの対策
このあたりでしょうか・・・
昨日からFlashモードになってるから、1、3やって2は天啓がおりてくるまで待機かなw
ではでは〜
0 件のコメント:
コメントを投稿