What is HTTP Live Streaming?


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では理解されています。また、常に3つの10秒間ファイルをリストに提示しているということは、エンコーダー側のアップロードにかかる時間を無視しても、撮影現場と必ず30秒以上の遅延が生じることとなります。(QuickTime7までは、現場との遅延は最短で8秒以下)
全体として、QuickTime 4〜7の生中継システムが以下の図(クリックで拡大)であり、

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

QuickTimeXによる生中継の利点は
1)完全なHTTP通信のため、Firewall等は全く気にする必要はない(QuickTime7までの場合、RTSPをTCP:80で送信しても、企業等のproxyサーバーでは結局HTTPプロトコールではないため、通じなかった)。
2)iPhoneへの生中継が可能。
の2点だと思います。
しかし、コンテンツ作成者という視点(一般ユーザーではない)から見た時、明確な欠点は
1)過去のQuickTimeコンテンツと完全に互換性が失われるため、配信環境更新(特にエンコーダー)・コンテンツの再作成等を強いられる
というものです。
例えば、当サイト管理者の場合、これらの利点と欠点は大きな影響があります。
現在はSMIL1.0を使って、Appleの基調講演と私の通訳音声を同期させているのですが、新しいQuickTimeXでAppleが基調講演の映像をオンディマンド配信した場合、SMILで制御できる保証はないので、新たなコンテンツ作成を求められる可能性があります。逆に、当方がiPhone用のコンテンツを作成できれば、Appleが基調講演をiPhone用にストリーミング配信(現状はiPhone用はPodcastのみ)を開始した場合、通訳付きの基調講演をiPhoneでもお楽しみいただけると思います。
今後も、QuickTimeXの動向にはiPhoneユーザーとしても、QuickTimeコンテンツ配信者としても注目し、必要に応じて、このサイトで情報をお伝えしたいと思います。