Alex Zambelli さんのブログ http://alexzambelli.com/blog/
原文： The Birth of Smooth Streaming
（独自翻訳 by 奥主：正確な表現は原文を参照ください。）
Smooth Streaming の誕生
前回の投稿ではマルチビットレート ストリーミングの歴史について簡単にふれ、メディア配信のメカニズムが RTSP と HTTP ストリーミングから HTTP ダウンロード方式に回帰しているトレンドについて書きました。この投稿ではアダプティブストリーミングと従来のストリーミング（例：RTSP）、普通のプログレッシブダウンロード の違いをもっと見ていきます。
従来のストリーミング
まず従来のストリーミングプロトコルの一例として RTSP を見てみましょう。RTSP はステートフルなプロトコルとして定義されています。これはクライアントがストリーミングサーバーに接続すると切断するまでサーバー側でクライアントの状態情報を保持することを意味します。クライアントは状態をサーバーに PLAY, PAUSE あるいは TEARDOWN コマンドを送信することで知らせます。最初の二つはわかりやすいですね。最後のコマンドはサーバーから切断し、ストリーミングセッションを閉じる時に使います。
クライアントとサーバーの間のセッションがいったん構築されるとサーバーはメディアを小さなパケットの安定したストリームとして配信を始めます。このパケットの様式は RTP として知られています。一般的な RTP パケットのサイズは1452バイトで、１Mbps でエンコードされたビデオストリームはパケットあたり ビデオ中のおよそ 11 ミリ秒分を含んでいるに過ぎないことになります。RTSP ではパケットは UDP でも TCP でも配信可能です。ファイアウォールやプロキシーがUDPパケットをブロックする環境では後者が推奨されますが、TCPパケットは受信確認がとれるまで再送されますのでこれによってさらなる遅延に繋がることにもなります。
ということで RTSP を従来のストリーミングプロトコルの一例として取り上げました。
一方でHTTP プロトコルはステートレスなプロトコルです。もしHTTPクライアントがデータをリクエストした場合にはサーバーはデータを返送する動作を当然します。しかし、どのクライアントからのリクエストだったか、あるいはその状態に関しては記憶しません。各 HTTP リクエストは完全に独立したワンタイムのセッションとして取り扱われます。
Windows Media Services は RTSP と HTTP 双方のストリーミングに対応しています。さて、こうなると今度は「HTTPがステートレスなプロトコルだったら何故ストリーミングで使えるの？」と思うことでしょう。WMS はストリーミング用に改良された HTTP、MS-WMSP を使用し、データの転送には標準のHTTPプロトコルの手順に従いながらセッションの状態も保持するメカニズムになっています。結果として RTSP/TCP プロトコルのような動作をします。Windows Media Services は UDP と TCP の双方で RTSP ストリーミングは 2003年 (WM9 シリーズ) からサポートしています。このプロトコルの実装についての公開ドキュメントは MS-RTSP です。
RTSP や WMS-HTTP のような従来のストリーミングプロトコルで覚えておくべき重要な点は下記です。
プログレッシブダウンロード
現在のWebで流行っているよくあるメディア配信の形態はプログレッシブダウンロードです。プログレッシブダウンロードは単に IIS や Apache のような HTTP Web サーバーからの通常ファイルダウンロードのことです。これは Silverlight, Flash, WMP そして 地球上に存在するそれ以外のほとんどのメディアプレイヤーでサポートされている方式になります。プログレッシブという言葉を使っている経緯としてはほとんどのプレイヤーがダウンロード中でもファイルのプレイバックを許可している点から来ています。ファイルの全体がディスクに書かれる前で、通常ブラウザーのキャッシュ内にある時から再生を始めます。HTTP1.1 標準をサポートするクライアントはまた、まだダウンロードしていないメディアファイル中の位置をバイト範囲リクエストを Web サーバーに行うことでシークすることができます。これはもちろん Webサーバー側が HTTP1.1 に対応しているとクライアントは想定して動作するということです。
今日 Webで最も人気のあるビデオ共有 Web サイトはほとんどのケースでプログレッシブダウンロードを使用しています。YouTube, Vimeo, MySpace, MSN Soapbox - そして 若干ネーミングが誤解しそうな Silverlight Streaming Service などもそうです。前回の私の投稿でなぜ HTTP ダウンロード形式のメディア配信が流行ってきたかの理由はご覧になってください。
クライアントに対して一度に10秒分のメディアデータしか送らないストリーミングサーバーと違って、HTTP Webサーバーは ダウンロードが完了するまでデータを流し続けます。これは YouTube サイトでの経験によって多くの人が今は知っているユーザーエクスペリエンスになっているでしょう。YouTube のビデオを開いてすぐに一時停止して待っていると、じきにビデオ全体のブラウザキャッシュへのダウンロードが完了し、途中で問題が発生することなくビデオの全体をスムーズに再生することができるわけです。この動作にはもちろん反対の影響もあります。完全にダウンロードしたたとえば10分間のビデオを再生し、30秒見たところでもう見たくないと思い、再生を止めてしまうと利用者とコンテンツプロバイダーの両方が 9分20秒 分の帯域幅を無駄にしたことになります。この問題を緩和するために IIS7 Media Pack 1.0 は Bit Rate Throttling という実に便利な機能を含んでおり、提供されています。このモジュールはコンテンツプロバイダー側のメディアデータ ダウンロードのスロットル制御ができることになり、経費削減に繋げることができたりします。ただ、それはまた別の話です。。。
アダプティブストリーミング
不適切な名称と言えば、もう一つありますね。アダプティブ ストリーミングです。実はですね。。。従来の感覚でのストリーミングでもなんでもないです。
アダプティブ ストリーミングは 本当のところはハイブリッドな方式です。ストリーミングのように動作しますが、実際には HTTP プログレッシブ ダウンロードです。アダプティブストリーミングのもっと技術的に正確な名前を考えてみると「様々なサイズの分割されたビデオの連続したプログレッシブダウンロード」でしょうか。でもこの名前じゃ凄腕のマーケティング担当者でも売れませんよね。
アダプティブストリーミングで覚えておくべき大事なポイントとしては、この方式に関しての標準実装が現段階で定まっていないということです。これは単に拡張されたダウンロードの概念でしかなくて、プロトコルの定義ではないからです。故に Microsoft Smooth Streaming と Move Networks Adaptive Stream を 双方で互換性の無いコーデック、書式、暗号化方式を使っているにも関わらず、アダプティブストリーミングの例として取り上げているのです。双方ともにHTTPをデータ配送プロトコルとして利用し、メディアダウンロードを一つの大きなダウンロードとしてではなく、とても細かく分割された単位で多くの回数行われるプログレッシブダウンロードとして実装されているのが共通事項です。
アダプティブストリーミング の プロトタイプレベルの実装では、ビデオ/オーディオのソースはとても小さい多くの単位に（塊）に分割され、期待される配送フォーマットにエンコードされます。この塊は通常 2～4 秒分の長さにします。ビデオ コーデックのレベルで各単位はビデオの GOP 境界（それぞれの塊の最初にキーフレームが入る）で分割されていることを通常意味し、それぞれの塊はそれ以前、あるいはそれ以降のものと関係がなく完全に独立していることになります。これにより、それぞれの塊で独立してデコードを行うことが可能になるわけです。
エンコードされたそれぞれの塊は普通の HTTP Webサーバーに置かれてホストされます。クライアントは Web サーバーに順番にリクエストし、HTTP プログレッシブダウンロードを使ってダウンロードします。クライアントにダウンロードしたものが蓄積されるに連れ、順番に再生が行われていきます。ギャップや重複が無いようにエンコードが行われているため、ビデオの再生はシームレスに行われるというわけです。
このソリューションの「アダプティブ」な部分はビデオ/オーディオのソースが複数のビットレートでエンコードされている時に適用されます。つまり、ビットレート別に2～4秒のビデオを複数の塊で生成しておくことです。クライアントはこれによってどの大きさの塊かを随時選択ができるようになっているわけです。Web サーバーは通常ネットワーク帯域の許す限り、データをできる限り速く配送しようとするので、クライアントはユーザーの使用帯域を予想することができやすく、より大きな塊を要求するか、小さいものにするかを事前に判断ができるようになります。再生/ダウンロードのバッファーは完全にカスタマイズ可能です。
まとめると、アダプティブストリーミングはハイブリッドなメディア配送手段です。
他の HTTP 方式の配信方法と同様、アダプティブストリーミングはコンテンツプロバイダーに下記のアドバンテージを提供します。
エンドユーザーにも下記の利点を提供します。
マイクロソフトのアダプティブストリーミング プロトタイプ：NBC Olympics 2008
私たちは HTTP ベースのアダプティブストリーミングをまず NBC Olympics 2008 プロジェクトでプロトタイピングしました。短い期間で要求された品質レベルを提供するために、最も基本的なアダプティブストリーミングの実装を採用しました。NBC’s Digital Rapids と Anystream エンコーダーに違うビットレート/解像度の複数の WMV ファイルを各ソースに用意してもらいました。新しいエンコーディングのテクニックを全く使わなかった代わりに厳しいエンコーディングのガイドラインに従いました(closed GOP, fixed length GOP, VC-1 entry point headers) 。これにより正確なフレームの順番と接続性を確実にし、ビデオをスムーズに流すようにしました。その後、WMV ファイルは後処理のツールを通し、各WMVファイルを2秒ずつの塊に分割しました。そうした上で Limelight の Web サーバー（Apacheが稼働）にすべてをアップロードし、あとは塊をダウンロードし、順番に再生する Silverlight のプレイヤーを用意しました。以上です！
よいお知らせ：エンドユーザーにとってこの実装はすごくうまく機能しました。簡単な HTTP ダウンロードで WMS ストリーミングよりも良いストリーミング体験をしてもらえました。
悪いお知らせ：CDN のオペレーターは数時間 いや 数日をこれらのいっぱいある細かいファイルの管理に追われました。想像してください。もし各 2 秒のビデオがそれぞれファイルになって、これが 5 種類のビットレートに用意されていて、一分あたり 150 ファイル になるとします。90 分のサッカーゲームのデータは 13,500 個のファイルということになります！
NBC Olympics は Silverlight と HTTP ベースのアダプティブ ストリーミングとしては大成功だったわけですが、このことによって私たちはまたホワイトボードと格闘するところへ話を戻さないといけないということになりました。
ついに！Smooth Streaming！
IIS メディアチームはすぐに NBC Olympics アダプティブストリーミングのソリューションを本物のサーバー製品にするアクションを始めました。正式な名称は IIS7 Smooth Streaming といい、IIS7.0の拡張としての開発です。
IIS メディアチームはコンテンツ作成と配送の部分に関してプロトタイプと比較して、ファイル管理にかかる過剰な手間を軽減しながら元のソリューションのいいところを残すように再設計しました。新しいデザインは塊ごとに一つのファイルを作るアプローチを止め、各エンコードのビットレート毎に一つのファイルを置くアプローチをとりました。この時に採用したファイルのフォーマットは MPEG-4 です。
Smooth Streaming サーバーは MPEG-4 Part 14 (ISO/IEC 14496-12) ファイルフォーマットを格納と配送のフォーマットして使用します。厳密に言うと、 Smooth Streaming のスペックはそれぞれの塊/GOP を MPEG-4 ムービーの断片（moof）として定義し、ランダムアクセスがしやすいように 連続して MP4 ファイルに格納します。各ビットレートに対して一つの MP4 ファイルを用意することになります。クライアントが特定の再生時間（3秒後から10秒後までなど）を指定してリクエストをしてきた時に動的にムービーの断片をファイルの中から探して、それぞれを独立したファイルとして送信する動きをし、完全にキャッシュ可能にすることを保証しています。
言い直すと Smooth Streaming ではクライアントのリクエスト時に細かい断片として生成されていくことになりますが、実際のビデオはディスクに全編収録された状態でビットレートごとに一つのファイルとして格納されます。
Smooth Streaming の今後
Smooth Streaming サーバーサポートは次のバージョンの IIS7 Media Pack として登場します。これは Windows Server 2008 用の無償ダウンロードになります。既に IIS7 Smooth Streaming サーバーのテクノロジープレビュー は Akamai 社を通じて既に確認が可能です。彼らはこのサービスを Akamai AdaptiveEdge Streaming for Microsoft Silverlight と呼んでいます。このサービスのデモは http://www.smoothhd.com でご覧いただくことができます。
コンテンツ制作の側としては、Smooth Streaming に対応したビデオの制作は既に Expression Encoder 2 SP1 を使用して可能です。Smooth Streaming エンコーディングサポートは Expression Encoder 2 の完全版の購入が必要です。”Express” と呼ばれるトライアルバージョンには入っていません。Smooth Streaming などのために複数のビットレートでエンコーディングを行う際のヘルパーツールとして、私が作った Smooth Streaming Calculator を推奨しておきます。Expression Encoder を使った Smooth Streaming エンコーディングについては引き続きブログを書きます。
さらに、エンコーディング関連開発している ISV 数社と プロフェッショナルなエンコーディングを行う製品において Smooth Streaming のサポートいただけるように協業しています。
Smooth Streaming 再生
Silverlight 2 が Smooth Streaming ソースの再生をサポートしているのはもうご存じでしょう。もしまだだったら是非 http://www.smoothhd.com へ行ってください。しかし、どうやっているんでしょうか。
よく信じられていることに反して、Silverlight は実際には特定のアダプティブストリーミングのテクノロジーをネイティブにサポートすることはありません。Microsoft、Netflix、Move Networks などがその例ですが。Silverlight におけるSmooth Streaming サポートは MediaStreamSource API を通じて実装されています。この API は開発者にMediaElement のネイティブトランスポートのメソッドに頼るのではなく、自身のメディア配送メソッドを実装する方法を提供しつつ、Silverlight のネイティブデコーダやレンダラーを使います。言い換えると Silverlight におけるSmooth Streaming サポートは .NET コードで提供されています。MPEG-4 ファイルフォーマットの解釈、HTTP ダウンロード、ビットレート切り替えのメカニズム、などなどがそうです。これにより、開発者はどのお客様のシナリオにも適合してくれることを祈りながら次のSilverlightのリリースを待つ必要はなく、クライアントのアダプティブストリーミングのコードを必要に応じて変更、チューニングすることができます。
Smooth Streaming Silverlight クライアント開発の最もチャレンジングなところはやはりビットレートをいつ、あるいはどのように切り替えるかを判断している部分のモジュールです。基本的なストリームの切り替え機能はネットワークの状態に合わせて遅滞なくスムーズに切り替えることを要求します。しかし、素晴らしいエクスペリエンスを提供するにはそれでは不足している場合があります。さらに検討しないといけない点としては、下記のような点があります。
- ユーザー側の帯域は十分にあるが、CPUのパワーが高いビットレートや解像度を処理するに足りない場合にはどう動けばいいのか？ - ビデオが一時停止した時にどうなるのか、ブラウザーが最小化した時にどう動くべきなのか？ - 準備されているビデオストリームで最適なものの解像度が実際のスクリーン解像度よりも大きくて帯域を無駄に使ってしまうような場合はどうするか？ - ダウンロード バッファーのサイズはどのくらいであるべきなのか？ - 誰が広告などの常に新しく切り替わるメディア資産がシームレスに表示されるのを保証するのか？ という具合にどんな Web アプリケーション開発者も言うと思いますが、いいプレイヤーを作るということは単にソースのURｌをセットすればいいなどというレベルではありません。
Silverlight に Smooth Streaming サポートを加える上で 一からそのようなコードを書きたくない方は幸運にも二つのオプションが用意されています。
これらのテンプレートはすぐに使える Smooth Streaming 体験を提供しつつ、開発者には引き続き革新的でチューンアップをできる環境を提供します！
ということなんですが、この元の投稿が出た時から時間が経ってまして、IIS7 Smooth Streaming のベータ版はもう提供を開始していますので IIS Extensions のサイトと Learn サイトの記事をご確認ください。（●＾o＾●）
http://www.iis.net/extensions/SmoothStreaming http://learn.iis.net/page.aspx/89/serving-media-content/