iphone上でのライブストリーミングデモうごきました。

iphone上で、Canvasとmp3のm3u8ストリーミングを利用してライブストリーミングをする。
そんな動作のデモができたので、動画にとってYoutubeにあげてみました。

動作の概要は次のとおり。
１：rtmpで映像+音声をred5に送る。
２：red5の内部で映像をjpegにする。生成jpegファイルはwebSocketでリアルタイム共有
３：red5の内部で音声をmp3のストリーミングにする。
４：アクセスユーザーはmp3のストリーミングを実行しつつ、Audioの位置から画像をJavascriptでアニメーションさせる。

３の動作の高速化を実施するために、以前つくったRed5のWebSocketプラグインを利用しています。

いまのところの課題は・・・
１：画像の転送料の軽量化とfpsの改善。
２：プログラムを修正して、room動作で問題がでないように修正。
３：iOS4でも動作するようにしたい。すくなくともiPhone4あたりでも動作してほしい。
(まだ未検証)

今回のデモは320x240の画像で実行していますが、実際にサービスとして利用するとしたら、160x120の小さな画面とコメント等の機能がある通常プレーヤーと従来のmpegtsによる動画だけ、高画質のフルスクリーンモードを準備して、任意で切り替えられる、的な感じですかね。


駄文その１：
ここ数日やっているこのライブストリーミングですが、一応HttpLiveStreamingの動作遅延を極限までなくすと、どこまでつめることができるのか？という検証もかねています。

・今回のストリーミングは、6〜7秒ほどのずれになっていますね。
・rtmpdump + ffmpeg + segmenterの組み合わせでがんばって出せる限界がだいたい20秒〜40秒
・今回のストリーミングの方式のmp3のみフルスクリーン動作でのベンチマーク最高が4秒程度(1、mp3の長さは2秒指定にしてあります。)

という結果になっています。

ffmpegをプログラムとして使う→ファイルとして成立するものをつくる。
xuggleにred5でパケットデータを送る→パケットの出力しかしない。
というわけで、後者の方が有利なのだろうか？と想像しています。
mpegtsのフォーマットを理解して自力でred5 + xuggleでtsパケットをつくれば映像のストリーミングでも8秒以内のずれに押さえ込める気がしますね。

駄文その２：
今回、今後の解決しないといけないものとして、３つあげました。
２はやっつけてつくったプログラムを修正すればあっというまに出来上がります。
３はさっさと公開して、だれかがiOS4の端末で検証してくれるのを待てばOKです。たぶん動作するはず。

で、問題は１ですね。
普通のネット環境で、すいすいみれる状況にしようかとおもったら転送量はできれば500kbps以下にしたいところ。
今回の動作の目標は10fpsに定めていますので
500kbps / 8(byteに変換) / 10 = 6.25 Kbyteが一枚のjpegのサイズということになります。正直これはきついです。ものすごいダメ画質になるでしょう。

ここででてくるのが、Canvasによるピクセル描画ですが、手持ちのiPhone4Sでためしたところ、160x120くらいのサイズでないと厳しいみたいです。
ここまで画像が小さいと、結局jpegを送るのとたいしてかわらないかもしれません。

ま、もっともAppleが考えを切り替えてVideoタグでの表示がフルスクリーンonlyという状況じゃなくなれば、こんな面倒なことしなくてもいいんですけどね。