Alex Zambelli さんのブログ http://alexzambelli.com/blog/
原文： Smooth Streaming Architecture
（独自翻訳 by 奥主：正確な表現は原文を参照ください。）
Smooth Streaming のアーキテクチャー
今までの二つの投稿で説明してきたように Smooth Streaming はマイクロソフトの HTTP ベースのアダプティブストリーミング - ハイブリッドなメディア配信モデル - の実装です。ストリーミングのように動作しますが、実は HTTP のプログレッシブダウンロードをベースにしています。HTTP ダウンロードは小さな塊が繰り返し行われ、メディアを容易にそして安価にユーザーに近いネットワークエッジでキャッシュすることができます。複数のビットレートでエンコードされた同一のメディアソースは Silverlight クライアントにシームレスで動的にビットレート間をネットワークの状況やCPUのパワーに基づいてスィッチさせることができます。その結果、エンドユーザーの体験は 信頼性が高く、安定した、バッファリングやストレスの無い再生を実現します。一言で言い表すと Smooth なんです。
この投稿ではもっと Smooth Streaming がどのように動くのかを見ていきます。フォーマット、サーバー、クライアントの視点です。
Smooth Streaming フォーマット
Smooth Streaming はこの十年ほどの間では ASF 以外を採用した最初の Microsoft メディアフォーマットです。ISO/IEC 14496-12 ISO Base Media File Format に基づいており、MP4 ファイルの規定として知られています。なんで ASF でなく MP4 なんでしょうか? いくつかの理由があります。
Smooth Streaming フォーマットには２つのパートがあります。配信のフォーマットとディスクファイルのフォーマットです。Smooth Streaming ではビデオはディスクに全編が一つのファイルとして記録（ビットレートごとに一つ）され、クライアントに配信される段階で小さい断片の集まりとして順番に生成・配信されます。配信フォーマットは IIS から ク���イアントに送信される断片の構造を定義しています。ファイルフォーマットは一方でディスクに記録される単一ファイルのフォーマットを定義しています。幸運なことに、MP4 規約は内部的に断片の集まりとしてファイルを作成することを許可しています。 つまり Smooth Streaming において配信フォーマットはファイルフォーマットのサブセットと言えます。
この MP4 の「断片」と私が呼んでいるのは何でしょうか？MP4ファイルの基本単位は「ボックス」と呼ばれています。これらのボックスはデータもメタデータも含むことができます。MP4 の規約ではファイル中のデータやメタデータの保持方法については柔軟性があります。ほとんどのメディアシナリオではメタデータをデータよりも先に書きこみすることを行っており、これはプレイヤーのアプリケーションが実際に再生する前にビデオ/音声に関するより多くの情報を得ることができるからです。しかしながら、ライブストリーミングのシナリオでは全体のストリームに関するメタデータを先に書きこむことが単に不明なために困難になります。さらに言及すると、事前のメタデータが少なければ少ないほどオーバーヘッドも少ない、つまり 早く起動することができます。これらの理由から MP4 ISO Base Media File Format specification は MP4のボックスが断片として構成できるように定義されています。つまり、一つの長いメタデータとデータとしてではなく、連続した短いメタデータとデータのペアとして実行とともにファイルが書かれていくということが可能です。Smooth Streaming ファイルフォーマットは MP4 ファイル規約のこの特徴を利用しています。マイクロソフトでは Smooth Streaming ファイルという用語とともに 断片化したMP4ファイル あるいは (f)MP4 と呼ぶことがあります。
下記は Smooth Streaming ファイルの中身がどうなっているかの概要図です。
Smooth Streaming ファイルフォーマット
簡単に要約してしまうと、ファイルは ファイルを全般的な説明を含む ファイルレベルのメタデータ(’moov‘) で始まり、ペイロードの本体は実際には多くの断片のボックスとして含まれており、これらの断片にもより詳細な断片レベルのメタデータ(’moof‘)と実際のメディアデータ(’mdat‘) を含んでいます。この図では断片は２つしか書いていませんが、通常 Smooth Streaming ファイルは ビデオ/オーディオ 2秒分で断片を一つ持ちます。ファイルの最後部には‘mfra‘ インデックスボックスが配置され、ファイル中の簡単で正確のシークを可能にします。
Silverlight クライアントがビデオ タイムスライス を IIS Smooth Streaming サーバーに要求するとサーバーは単純に MP4 ファイル中の開始断片を探し、ファイル中からその該当断片を「持ちあげて」クライアントへの配信を始めます。このため、私たちは各断片を配信フォーマットと呼んでいます。このテクニックによって IIS サーバーに再書き込みを行うなどのオーバーヘッドを要求しないため、最適化された状態で配信が行われます。
MP4 断片をもっと詳細に見た図です。
Smooth Streaming 配信フォーマット
Smooth Streaming フォーマットは MP4 file format に基づいていると言っているのは ISO 規約に従っているとは言え、独自のボックス構成のスキーマを指定しますし、カスタムなボックスもいくつか定義しているからです。Smooth Streaming ファイルを “vanilla” MP4 ファイルと区別するために、私たちは新しい拡張子を使います。*.ismv (ビデオと音声) と *.isma (音声のみ) です。いつも IIS メディアチームに正確に何の略なのか聞くのをいつも忘れるんですが、私の推測では「IIS Smooth Streaming Media Video (Audio)」だと思っています。
Smooth Streaming メディアのアセット
ということで、一般的な Smooth Streaming のメディアアセットは以下のファイルで構成されます。
双方のマニフェスト ファイルのフォーマットは XMLベースです。サーバー マニフェスト ファイル フォーマットは特に SMIL 2.0 XML フォーマット規約に基づいています。
Smooth Streaming メディアアセットを含んだフォルダは下記の図のようになっているということになります。
Smooth Streaming メディア アセット を含んだフォルダー
この特定のケースではオーディオトラックは NBA_3000000.ismv ファイルに含まれています。
Smooth Streaming マニフェスト ファイル
Smooth Streaming 配信/ファイル フォーマット 規約はボックスの構造だけでなく、マニフェストのXML記述方法も定義します。マニフェストは XML ベースであるため、拡張性は非常に高いです。現在の Smooth Streaming フォーマット規約には以下のような機能が含まれています。
Smooth Streaming オンデマンド サーバー マニフェスト については ここ をご覧ください。
Smooth Streaming クライアント マニフェスト については ここ をご覧ください。
Smooth Streaming 再生：まとめ
マイクロソフトのアダプティブストリーミング プロトタイプ(NBC Olympics 2008で使われた) は物理的に長いビデオファイルを細かいファイルに分割する手法に依存していました。Web サーバーからこれらの塊を入手するにはプレイヤークライアントは単に論理的なシーケンス - 00001.vid, 00002.vid, 00003.vid - のような順番でアクセスするだけでした。
以前 そして この投稿で説明しているように、Smooth Streaming は もっと複雑なファイルフォーマットとサーバーのデザインを利用しています。ビデオはもう数千のファイルに分割されるのではなく、仮想的にファイルの内部で「断片」として分割（普通 ビデオ GOP 当たり１断片）されており、一つの MP4 ファイルに保管されています。これによってサーバーとクライアントにおける二つの大きなデザイン変更に関係しています。
Silverlight クライアントが Smooth Streaming サーバーに要求する最初のファイルは *.ismc クライアント マニフェストです。マニフェストはどのコーデックを使って圧縮されたか（Silverlight ランタイムはこの情報を使って正しいデコーダーを初期化し、再生のためのパイプラインを構築します。）、どのビットレートと解像度が存在するか、存在している断片のリストと開始時間あるいは長さを保持しています。
IIS7 Smooth Streaming では クライアントは RESTful なURL を用いて断片を要求することが期待されています。
http://video.foo.com/NBA.ism/QualityLevels(400000)/Fragments(video=610275114) http://video.foo.com/NBA.ism/QualityLevels(64000)/Fragments(audio=631931065)
URLで渡されている値はエンコードされたビットレート(例：400000) と協議で決められた時間単位（通常 100 ns）での断片のスタート時間オフセット(例：610275114) です。これらの値はクライアントマニフェストで得るものです。
このようなリクエストを受け取るにあたって、IIS7 Smooth Streaming コンポーネントは品質レベル（ビットレート）を対応する *.ism サーバーマニフェストで探し、ディスクに存在する実際の*.ismv あるいは *.isma ファイルにマップします。その後、該当の MP4 ファイルを読みにいき、‘tfra’ インデックスボックスの情報に基づいてどの断片ボックス(’moof’ + ‘mdat’) がリクエストの時間オフセットに適合するかを判断します。最後に、見つかった断片ボックスを抽出し、クライアントに単独のファイルとして配信します。これは全体デザインの中で非常に重要なポイントで、このことにより送信された断片/ファイルはネットワークの途中で自動的にキャッシュされるようになり、実際の配信サーバーが同じRESTful な URL を要求してきたクライアントに再度送信する負荷を軽減できます。
このように、サーバーからビデオ/音声の断片をリクエストするのは簡単です。しかし、アダプティブストリーミングを効果的であるとして根拠である動的なビットレートの切り替えはどうでしょうか？ Smooth Streaming 体験のこの部分は完全にクライアント側の Silverlight アプリケーションコードでの実装になります。サーバーはビットレートの切り替えプロセスには携わりません。クライアント側が断片をダウンロードする時間、バッファーの飽和度、レンダリングされたフレームレート、その他の要素を確認し、判断してより高い あるいは より低いビットレートを要求するかを決めるのです。エンコードを行うプロセスで同じソースであればすべてのビットレートのファイルが完全にフレーム単位で同期（同じ長さのGOP、ドロップしたフレームなし）がとれていれば、ビットレート間の切り替え自身は完全にシームレスで、そして Smooth です。
なかなか正確に訳すのが難しい文なんで、曖昧になってしまっている点があるかもしれません。特に fragment を断片と訳しているのが気持ち悪いのですが、全部 「塊」と置き換えてしまうとわかりやすいかもしれませんね。
メディア配信も REST なんですねぇ （*^_^*）
なお、新しく Media というタグを用意したので、Media の投稿だけみたい方は Media を左でクリックしてください。
スムーズストリーミングコンテンツであるというSignature（判別方法）は、ございますでしょうか。
そしてそれのスペックは？
私が Windows 8 フォーカスになってしまってからスムーズストリーミングに関して日本語の情報発信が停滞していますが、http://www.iis.net/learn/media はどんどん更新されています。基本的なスムーズストリーミングとそうでない動画の動きとしては MS で実装されているいい適用例である Channel9 の動きをみていただくと参考になると思います。channel9.msdn.com/.../TWC9-September-6-2013
今はAzure上で同じ技術が動作する www.windowsazure.com/.../media-services に注目が集まっています。