2012年5月20日日曜日

iphone上でコメントが流れる生放送を作りたい、その1

できそうな目処がたったので、実行してみたいと思います。

動作的には次のような感じ

Flashのrtmpをつかって放送する

Red5でうけとる。

ストリームをxuggleに渡してリアルタイム変換を実行する。
・jpgでコマ画像を12〜15fps程度で実行
・mp3はm3u拡張として流せるように準備

iPhone用のストリームはhttp経由で適当にアクセス
Flash用のストリームはrtmpでそのままアクセス

といった感じ

今のところ可能っぽいこと。
・xuggleの変換後のwriterPacketのデータの中身は生メディアデータになるみたい。
(単純にmp3のフレームデータになっていたので、前回のmp3 splitterと同じようなことが可能。)フレームの長さを計算しつつ、いくつのパケットを結合するか計算すれば、問題なく組めそう。
・jpgにして書き出す操作は、xuggleにやらせてもいいし、xuggle-xuggler-red5の動作で以前各フレームの画像の抜き出しに成功したので問題ないはず。
・mp3フレームのデータには、キーフレームという概念がないので、どこできってもきちんと動作する。tsの場合は(たぶんh.264を動画コーデックに利用しているからだと思うが)終了時のフレームの位置によっては再生が強制的にとまったりする。

解決しないといけなさそうなこと。
・音声のないストリーム、もしくは無音なデータが含まれるストリームの場合、単純に結合すると音声がない間のmp3フレームが抜け落ちる。よってその間をうめるなにかを用意しないと、mp3のm3u拡張がめちゃくちゃになる。(無音部が抜け落ちるため)
→確認として、音声のあるflvデータ→音声のないflvデータ→mp3に変換を実行すると、mp3にはストリームがない状態になってしまう。

いまのところの解決案
1:ダメ画質の映像をもったtsファイルのストリームにして、audioタグにつっこんでおく。
→tsファイルにしたら問題なく動作することはわかっていますが、tsファイルにすると放送がとぎれたときのコントロールがややこしいかもしれぬ。あと、tsファイルベースのaudioタグ再生だと、挙動がかわる。(別アプリに移動したときとか一旦停止してしまって、放送者との同期がずれるかもしれない。)
2:無音のmp3フレームを別途保持しておいて、音がないときには、そのデータでうめておく。これならうまくいけるかもしれないが、xuggleの変換処理が別スレッド動作になるから同期が面倒か?

できたら2で解決したいですね。

あとは作ってみてどのくらいずれが生じるか?
フレームのデータをwebsocketでやり取りするとして、先読みとかうまく動作するか?
そんなところでしょうか?

会社でやってるtsファイルのストリーミングは、現状3〜5分遅延、アップデート後目標30秒〜1分遅延なんですが、今回は技術検証の意味とxuggleをつかったred5上でのリアルタイムエンコードなのでできたら10秒遅延以内を目指したいですね。

果たして、妙な技術エラーにぶちあたらないといいけど・・・どうなることやら。
以上意味不明な駄文でした。

0 件のコメント:

コメントを投稿