HTTP Pseudo Streaming with Flash

June 28, 2009

先日の記事ではAppleのHTTP Live Streamingの草案を紹介しました。

HTTPのStreamingは現時点でも行われていますが、最も不便なことといえば、Progressive Downloadであるため、接続・再生開始した直後に途中の10分経過後等へランダムアクセスできない（ファイルをダウンロードしただけの時間軸しか使えない）ことだと思います。

そこで、Appleはm3uプレイリストを使って再生ポイントと分割されたファイルを結びつけ、ランダムアクセスもどきを実現しているようでした。

ところが、それとは若干違うアプローチが開発されている模様です。Apache等のwebサーバーにモジュールをインストールすることでFlash10 PlayerでH.264ファイルのランダムアクセス再生をFlash Media Serverを使わずに実現したとのことです（生中継は無理でして、あくまでオンディマンド配信のみですが）。

これはHTTP Pseudo Streaming（HTTP疑似ストリーミング）と呼ばれる技術で、そのモジュールを紹介しているページはこちら。そして、webサーバー配信でのランダムアクセス再生のデモはこちら（ポートが8080なので、企業等の制限のある環境の方は接続できない場合があります）になります。

これとAppleのHTTP Streamingが共存できれば同一の.mp4を同一のApacheサーバーからMac/iPhone向け（AppleのHTTP Streaming）、Windows/Linux向け（Flashを使ったHTTP Pseudo Streaming）にそれぞれへ配信可能になるかもしれません。

私自身は最近時間がとれないので、このApacheモジュールをまだインストールしてませんが、近いうちに実験を行い、追って結果をお見せしたいと思います。

posted by kuni at 12:02 AM | comments (0) | permalink |

What is HTTP Live Streaming?

June 21, 2009

WWDC 2009基調講演において、QuickTimeXのHTTP Live Streaming （25:10頃）、iPhone OS 3.0のHTTP Live Streaming（1:02:02頃）について、紹介はされたもの、詳しい説明はありませんでした。これまでのRTSPではなく、HTTPで生中継するとはどういう仕組みなのか？何をもたらすのか？これについて最近、ネット上でApple Inc.のRoger Pantos氏が提出しているInternet-Draft（規格の草案）が見つかりました。

これをそのまま読んでも私はわからなかったのですが、Apple主催のStreaming-server-users mailing list（QTSS/DSSについて情報交換するメーリングリスト）内でこのdraftについて議論があり、David Glaude氏がわかりやすい解説をしてくれましたので、それを元に、HTTP Live Streamingとはどういう原理なのかを説明したいと思います。

It is basically a playlist (M3U) with "hint as extended comment" that indicate where to jump to when someone try to seek.

Your encoder must produce small files MPEG 2 TS or PS or audio elementary stream.
By small file they talk about 10s per file as a typical value.
Then you must produce those playlist file (easy for VOD) but for live they have the option of a sliding window playlist (let's say a playlist that is dynamicaly updated with the next chunk as they appear.)

So all in all it might be possible to do a continuous streaming of a live event in Near Real Time.

This draft recommend to have always 3 chunk available at any given time and to start playing anywhere except on the last and second-to-last files.

--拙訳--
この規格は基本的に、拡張コメントによるヒント化がされたプレイリスト（m3uファイル）を用いており、そのプレイリストには、再生のために時間単位での問い合わせがあった場合には、どのファイルに飛ぶべきかが記述されています。

生中継用エンコーダーは小さい単位のMPEG2-TSファイル、又はMPEG2-PS、又は音声のエレメンタリーストリームを出力可能であることが条件となります。小さい単位の標準的な値としてファイル一つ当たり10秒と設定しています。ビデオオンディマンド用に前述のプレイリストファイルを作成することとなりますが、生中継の場合には通常のプレイリストファイルとは異なるスライドウィンドウ型のプレイリスト（例えて言うなら、次のファイルが見つかれば、動的にリスト内容が次のファイルを含む内容に書き換わるリスト）を使うこともできます。

この動的リストにより、リアルタイムに近い継続的なストリーミング中継が可能となるのです。

この草案では、クライアントがサーバーに接続した瞬間において、プレイリスト上で常に3つのファイルがアクセス可能になっている状態を推奨しています（ストリーム全体の最後、及び最後から2番目のファイルにアクセスするしかない瞬間を除いて）。
----

要するに、QTSS/DSS等は全く必要とせず、エンコーダー側がftp（もしくはweb dav？）でファイルをwebサーバーにアップロードして、クライアントがwebブラウザでダウンロードする動作をプレイリストを使って連続的に動作しているように見せるという、結構な力業の模様です。また、MPEG2-TS/PSファイルですが、ビデオ、オーディオのCodecはH.264、AACになるようです。

例えば、Appleのメディアイベントの基調講演が2時間（WWDC09は2時間だったので）で、これを10秒毎のMPEG2-TS/PSファイルで配信すると仮定すると、m3uファイルには、約720個の.mpgファイルがリスト化されているはずです。時間指定による再生も可能という仕様ということなので、仮に14分11秒を指定して再生する場合、プレイリストは85番目の.mpgファイルをQuickTimeX(Mac/PC)又はSafari(iPhone3.0)に伝え、再生が開始されるはずです（下図参照：クリックで拡大）

また、生中継の場合は動的にプレイリストが更新される仕様とのことなので、エンコーダーがファイルをアップロードする10秒毎に.m3uが更新されていくということになります。（下図参照：クリックで拡大）

なお、基本的にプログレッシブダウンロード再生を連続して見せているという技なので、当然ながら、帯域が十分でないと生中継的に再生できなくなります。WWDC09基調講演の中で、帯域別に再生のクオリティを調整するという説明がなされていたのは、QuickTimeでいうref movie（複数帯域のムービーを回線状態に応じて振り分ける）と同じ機能をm3uに持たせることであろうと、Streaming-server-users mailing listでは理解されています。また、常に３つの10秒間ファイルをリストに提示しているということは、エンコーダー側のアップロードにかかる時間を無視しても、撮影現場と必ず30秒以上の遅延が生じることとなります。（QuickTime7までは、現場との遅延は最短で8秒以下）

全体として、QuickTime 4〜7の生中継システムが以下の図（クリックで拡大）であり、

新たにQuickTimeXで生中継を行う場合のシステムが以下の図（クリックで拡大）のようになるはずです（エンコーダーについては現段階でEnvivioしか発表していない）。

QuickTimeXによる生中継の利点は
１）完全なHTTP通信のため、Firewall等は全く気にする必要はない（QuickTime7までの場合、RTSPをTCP:80で送信しても、企業等のproxyサーバーでは結局HTTPプロトコールではないため、通じなかった）。
２）iPhoneへの生中継が可能。
の2点だと思います。

しかし、コンテンツ作成者という視点（一般ユーザーではない）から見た時、明確な欠点は
１）過去のQuickTimeコンテンツと完全に互換性が失われるため、配信環境更新（特にエンコーダー）・コンテンツの再作成等を強いられる
というものです。

例えば、当サイト管理者の場合、これらの利点と欠点は大きな影響があります。
現在はSMIL1.0を使って、Appleの基調講演と私の通訳音声を同期させているのですが、新しいQuickTimeXでAppleが基調講演の映像をオンディマンド配信した場合、SMILで制御できる保証はないので、新たなコンテンツ作成を求められる可能性があります。逆に、当方がiPhone用のコンテンツを作成できれば、Appleが基調講演をiPhone用にストリーミング配信（現状はiPhone用はPodcastのみ）を開始した場合、通訳付きの基調講演をiPhoneでもお楽しみいただけると思います。

今後も、QuickTimeXの動向にはiPhoneユーザーとしても、QuickTimeコンテンツ配信者としても注目し、必要に応じて、このサイトで情報をお伝えしたいと思います。

posted by kuni at 5:39 AM | comments (1) | permalink |

Envivio iLiveTV for iPhone 3.0

June 18, 2009

EnvivioのiPhone向け、生中継ソリューションが発表されました。

"Everything needed to get started is in the iLiveTV package including the Envivio 4Caster™ C4 world-class video encoding platform, the content delivery server software and a royalty free CoverFlow web-based iPhone client portal."

「iLifeTVパッケージには生中継を始めるために必要な全てが含まれています。内容は、世界最高峰のエンコーダーであるEnvivio 4Caster C4、コンテンツ配信用サーバーソフトウェア、そして著作権フリーのweb版CoverFlowインターフェイスのiPhone用ポータル等です」

やはり、Envivio 4Casterの登場ですか。
値段がいくらなんだろ、このパッケージ？とても高額で、一般人には手が出ないだろうなぁ、、、

posted by kuni at 1:13 AM | comments (0) | permalink |

WWDC 09 Keynote in Japanese Part2

June 10, 2009

WWDC09基調講演の日本語通訳の配信を開始しました。

このリンクをクリックいただくと、ウィンドウが開き、基調講演の本編と日本語が同時にスタートします。

また、５分ごとの任意の時間から本編と同時通訳のシンクロ再生が可能になっております

詳しい操作方法につきましては左側メニューの「通訳放送受信手順」をご覧ください。

ただ、Firefox 3では、残念ながらjavascriptとQuickTime Plug-inとの間で不具合が生じることが報告されており、動画部分がコマ落ち及び劣化して再生されるようです。そのような場合には、Safariなどの他のブラウザを使っていただくか、2008年1月まで使用していました、QuickTime Playerの二つのウィンドウをユーザー側で同期させていただく方法を使って下さい。

QuickTime Playerで同期させる場合、このリンクをクリックすると、日本語同時通訳音声がQuickTime Playerで再生されますので、Apple側のムービー配信と同期させてください。詳しい操作方法はこちらをご覧下さい。

通訳の内容はできる限り忠実に訳しているいるつもりですが、当然公式訳ではありませんので、参考程度と考えてください。作成時間上の制約から、訳が不完全な部分が有るかも知れませんが、ご了承をお願いいたします。

• コメントをいただけると、今後も続けていくための励みになります。お時間がおありの際は、ぜひコメントをお願いいたします。
• 通訳者の声の調子がおかしい？、ニコニコ動画への投稿等についてはFAQを参照ください。

posted by kuni at 5:18 AM | comments (5) | permalink |

Notice for Delay

June 9, 2009

WWDC09基調講演QuickTimeムービー対応の日本語同時通訳音声配信ですが、予定より少し遅れて、6月9日の深夜になることを、お知らせします。

これは主にAppleのムービー配信が通常より2時間以上遅かった（通常は午前7時台に配信を開始するところを、本日は午前10時頃に開始した）ことに加えて、サイト管理人が夕方から夜にかけて、個人的用事（子供がいる一般家庭の生活）があり、その後作業を再開することになりそうなためです。

配信が遅れることをお詫びいたしますとともに、今一度お待ちいただけますよう、よろしくお願いいたします。

また、チャットイベントのtwitterの配信に関してですが、twitterのAPIによる制限（1時間に約60回の投稿があると、投稿受付が停止される）により、途中から配信ができなくなった模様です。これについてもお詫びいたします。

twitterに関しては、今後、対応策について検討をしたいと思います。

posted by kuni at 4:54 PM | comments (3) | permalink |