Windows Home Server 担当の林のブログでも取り上げていますが、Windows Home Server のサブスクリプションでの提供が開始されています。すごく要望が多かったのを知っています。ぜひお試しください。
Power Pack 2 と MSDN、そして OneCare
TechNet サブスクリプション担当の杉田も相当 米国との調整で苦労していたのですが、林の力添えもあり、3/24 時点で公開が開始されています。
そして 次の大きな Update である Power Pack 2 に関しても英語版の提供が開始されており、日本語版はちょうどゴールデンウィークのころになっています。GWの仕事を一つ増やして申し訳ないんですが(>_<)、ぜひ適用しましょう！ Windows Update での提供となりますので、特に適用済み環境をお待ちいただく必要はありませんので Home Server の特徴を気に入っていただいた方はぜひお試しになってください。すごく便利ですよ！
林からいつも聞いているのですが、Windows Home Server は拡張が可能です。開発者の方にはぜひアドイン開発に手を染めていただきたいと思います。単なる NAS では実現できない可能性がここには広がっています。現在の Windows Home Server は Windows Server 2003 ベースです。ということは、企業開発で培ったノウハウを���庭に持ち込むことができるのです。また、家庭にある環境という意味ではビジネスで考えていたよりも多くの新しいシナリオが増えることになります。
林がブログで紹介しているここのサイトで色々とどういう開発をみんなしているのかを見れます。 http://forum.wegotserved.com/index.php?autocom=downloads
メディアストリーミング関係とか、家の中だからこその電源管理とか、ビジネスでは見られない Home Automation とか開発を試していただきたい領域が本当に多くあります。ぜひアドイン開発にチャレンジください！
ということで、Tech Fielders でも「輪」を広げていく活動をしていますが、実はすごく熱いユーザーが多い Windows Home Server でも Windows Live Group を使った「輪」ができつつあります。私もこのグループの一員です。林の下記の投稿に従って、われこそはという方はご参加くださいますよう、お願い申し上げます！！
新しいコミュニティサイトオープン！
よろしくお願いします。（*^_^*）
なかなか手が空かなくて書くのがすごーーく遅くなってしまったのですが、とてもうれしい声を参加者の方からいただくことができた素晴らしいイベントにすることができました。まずはご参加いただいた皆様に厚く御礼申し上げます。また、当日来れなかった方も TF セミナーは順次行われていますのでぜひいつかお越しくださいませ。（＾－＾）
序
Tech Fielders 構想は特に 高添、長沢 そして舟越 を中心に組立ててきた MSテクノロジーを扱っていただけている、あるいは興味がある 新しい技術者の「輪」を作り出すこと、そして現場に役立つ情報発信を行うことを大きな目標にまずはサイトを構築するところを実践してきました。そして、セミナー併設のライトニングトークなどですでに多くの社外の方の情報発信、あるいはインタビューなどを通じたテクノロジーを使用いただいた様子やノウハウなどの共有まで進んできました。ただ、本質的にはまだ「輪」を作り出していき、それを Tech Fielders というサイトからの強力な発信というところまではまだ行けていません。
さて、こんな中、この”集い”企画は 3/20 の新宿セミナールームが私たちのチームで確保できたところから始まります。そして、中心メンバーである高添の一声で実施に向けて歩き始めたのです。どんな内容にしようか、Back To The IT というマネージャーの方向けの試みも続きを考えていますし、Tech Fielders としてどういう情報発信やコミュニケーションを今 しようかということでみんなで悩みました。
破
「外の方に情報発信を一緒にしていただく前に、まずは MS 社内の活動を社外の方にお届けしよう、MS 社内の Tech Fielders メンバーがエバンジェリストだけじゃないんだというのをお伝えしよう！」そんな話に成長していきました。
色々な仕事がある中 時間を やりくりしながら、MCSには安納が、営業SEチームには高添が、サポート部隊には長坂と私が、開発チームには長坂がそれぞれ講師になっていただける方の調整が急ピッチで進められました。
MS のコンサルティングチームもすごい優秀なコンサルタントがいることを私たちはもちろん知っています（所属していたこともあります。）し、サポート（私はここが長いです。）や開発、そして営業 SE （高添はここ出身）のチームも日々頑張っていることはよく知っています。こんな中、どういう内容であれば参加いただいた皆さんにいつもと違う体験をしていただけるのか、講師の方にも休日に登壇していただいて有意義な時間を過ごしていただけるのか、それを必死にみんなで考え、講師の方にご相談し、準備が進んで行きました。基本線はみんな素の技術者としての一面を出してもらおう、そしていつもやっている仕事の一端を紹介してもらおうということで定まったのでした。
エバンジェリストが当日、誰一人としてセッションをせず、司会やスタッフになるのは初めてでしたし、いつも Flash ニュースレターでは登場しても セミナーの立会を担当する場合でないとなかなか前面に出ることのない、マーケティングメンバーも本格的な出場という意味では初めての試みでした。
そうして色々なロジ周りの話が進み、当日に向けての担当割り、準備が着々と行われていったのでした。
本当に手作り感満載な雰囲気を前日の会場設営でご覧いただきたいと思います。
急
さあ当日がやってきました！ 朝一番はマネージャークラスが勢揃いで若干の緊張感もありつつ、次第にメンバーが順番に揃っていき、本番を待つばかりへとどんどん準備が行われました。
長沢の素敵なポートレートを一枚！
開場、セッション開始です！！
まずは「とてもつなぎの言葉をいつもみたいにしゃべってしまわないようにすごく大変だった」と後日もらしていた高添の司会で本日の段取り紹介。。。
私の 上司の上司 と 上司の登場。。。私たちの PowerPro という取組みと Tech Fielders についてお話をさせていただきました。実はこのパート、途中で長沢と私が話しているんですが、そこは私は写真を当然とれていないのでカット。 （＾－＾）
そして MCS セッションの始まりです！
いやぁ 待鳥 も 佐々木 も最高に熱かった！ 最高でした。 マイクロソフトのコンサルタントがどういう人たちなのか、どういうマインドで仕事をしているのかというのが素で会場の皆さんに伝わっていたら本当にうれしく思います。私自身はこういう人たちと同じ会社で働けてよかったとすごく思いながら見てました。MS テクノロジー、特に早期導入の時の MCS の価値も伝わったでしょうか？ とても人柄が出ていた素晴らしいセッションでした。
～休憩時間～ 質問、質問、質問、そして準備で疲れ果てている人も。。。
さて午後の部でございます！！
まずは サポートで 米国へのエスカレーション（Fix の提供依頼を行う）のマネージャーである大高の登場です。 熱意ある内容で、QFE の説明をホワイトボードでしてくれました。
不覚にもダンプを開いて、原因調査の一例をデモしてくれたのですが、私が画面に見入ってしまい、その写真は一枚もなし、、、あらら。
次は 開発部門で IME を担当している 佐藤 の登場です。MS における開発プロセスや MS におけるテスティングというような私たちでも普段聞けないような話をしてくれました。黒シャツも画面に釘づけです。
そして、午後のセッション 第3部は私の元上司、企業様向けサポートの担当者チームの親分の一人、森永の登場です。 数年前までは一緒にお客様を訪問していたのですが、その時の森永節を生で聞けて実は一番うれしかったのは私だったのかもしれません。ドイツと日本のバグ報告に関する特異性の話などかなりの人が聞き入ってました。 （森永さん、ありがとうございました！！）
そして、私たちの部門以外からの登壇としては最後になりましたが、御代が登壇してくれました。アンケートを後日見たら、御代のトークの印象がすごく残っている人が多かったようで、話をすることを仕事にしている私たちもすごく勉強になるトークを展開してくれました。直接お客様に営業部隊として接することの苦悩など交えながら、すごく楽しい話をしてくれました。いやぁ 参りました、脱帽です。取材に入ってくれていた幾人かの人も相当パシャパシャしてました。
さて、懇親会に入る前に、、、私たちのチームでエバンジェリストではないメンバーがいつもやっているマーケティングの仕事について、普段前に出ないメンバーが前に出てくれました。
あれれ、そのままじゃんけん大会のはずがビデオ撮影していた上司が前に出て行きまして、、、 まずは松崎と小高が執筆者に名を連ねている SharePoint開発、 VSTO本プレゼントからでございます。
この本をご覧になりたい方は松崎の下記の投稿をにアクセスしてくださいませ。 http://blogs.msdn.com/tsmatsuz/archive/2009/01/26/info-sharepoint-book.aspx
「この本は松崎と小高 が。。。部屋にいないし。。。」というオチつきでした。
そして安納、田辺、長坂の監修していたリソキ です。 ひょっとして パー が多いか。。。
そして今回はデザイナー向け製品部のご協力によりなんと Expression Studio ！！ これも集いならではか。。。激戦でした。
そして終了、終了。。。懇親会へ
いやぁ 準備から実施まで長かった～～～～ でもやって良かった。すごく多くのお客様に喜んでいただけました。講師陣に感謝するとともにこれからも気を引き締めて次の「集い」でまた多くの人とお話できることを楽しみにしています。
今回は特別にいただいたいくつかのコメントも記載しておきます。
・日頃のエバンジェリストの方々とは違っていろいろな方々の話を聞けて良かったと思います。体制をよく理解できました。TFが私達と彼等とのよきハブとなってもらって頂きたい、MSさんの顔が見えてきました。情報の敷居を下げる事を楽しみにしています ・今回のセミナーも各種勉強会、コミュニティーに参加していない方にとってはPRが足りず知らなかったというケースも多かったのではないかと感じています。次回はさらに参加者の層が厚くなるとより良い意見や見解が出てくるのではないでしょうか ・世の流れとのリンクが見えてよかった（どんな位置で活動されているのかが良く分かりました） ・技術ではなく人間にフォーカスしたイベントで非常に興味深かったです ・技術的な話だけでなくとても面白いセミナーでした、どんなシステムもプログラムも人が作っているという当たり前の事に改めて気付かされるセミナーでした、誰かのために役に立つシステムを作る、そのことにマイクロソフトと私達技術者が共に働くのだ、という思いを強く持ちました ・めずらしいイベントですね、ほとんど営業さんとお話する機会がないのでよい機会です
本イベントに関わっていただいた多くの皆様、しゃべった人も、プレゼント渡した人も、プレゼント受け取った人も、残念ながら何も当たらなかった人も、特別にお越しいただいたプレス各社の皆様も、
本当にありがとうございました！！ 幸いなことに 次回の要望もありましたので またの機会にお会いできればと思います。
それでは、それでは。（●＾o＾●）
だいぶ時間が経ってしまったのですが、報告をしておこうと思います。
かなり「基本編」の言葉に合わせにいったつもりだったのですが、どうしても新しいことをしゃべりたがりな体が言うことを聞いてくれなかったので新しいことも結構話してしまいました。
中身は最終的に下記でお話をしました。
•IIS7 基礎知識 •IIS7 の基本的な足回り •WSS を使用した情報共有（WSS：Windows SharePoint Services） •メディアストリーミング •IIS7 で知っておくといいこと •まとめ
アンケート結果を拝見したところ、ストリーミングは興味が無いのでもっと前半をやってほしかったとか、WSSを気合い入れて聞きたかったとか、そんな中、ストリーミングの話は他で聞けないので良かったとか とても幅広いコメントをいただくこととなりました。
IIS.NETが一番 英語では情報が揃っている状況が続いていることに少し私も業を煮やしまして、結果 日本語の情報提供に少し進展がありそうです。TechNet に IIS TechCenter という日本独自発信のポータルを構築しています。また進捗があり次第 ここの状況はお知らせします。本セミナーの前半に期待が高いのはそういうオンラインの情報が日本語で少ないからだと思っているのでセミナーという形式だけでなく、広く多くの人が参照できる Webページへの情報提供で頑張っているところです。
さて、セミナー報告の投稿ですので、お話した内容のポイントをおさらいしておきたいと思います。時期が期末で集まっていただけるのが厳しかったので、またリピートでできればやりたいとも思っています。
・IIS7基礎知識
IISとはなんぞやから始まって、Windows Server 2008 の Edition の話、新機能の出荷方法に至るまでお話しました。IIS7を捉える時に大事なのは大きくまずは二つだと思っています。これはモジュール化であり、もう一つはメタベースに代わる新しい構成システムです。この二つをいつもスライドで御説明しました。
最後に出荷方法に絡めて、IIS Extensionの最新の状況をお伝えしました。
※この投稿の後にMIXでの発表内容の投稿もしますので、この表はあくまでもこのタイミングでの表だと思ってください。3/18の発表でまた状況が大きく変わってます。
•IIS7 の基本的な足回り
まずは下記を話しました。Apacheのドキュメントはよくできてます。いきなりまずは動かしたい人（つまりは せっかちな人）向けの手順がちゃんと載っているのですから。Apache に慣れている人向けにこんな表を作ってみたわけです。
入手方法、インストール方法、コマンドでインストールする方法、インストール済 コンポーネントを確認する方法、起動、終了、再起動 など基本的なことを説明しました。
さらに実は IIS でわかりにくいとフィードバックの多い、アプリケーションプール、サイト、アプリケーション、仮想ディレクトリの関係も説明し、Windows のプロセスとの関係なんかも説明しました。
（クリックすると拡大して見れます。）
IIS の環境設定で実は大事なのは設定をする行為が実は最終的に構成システムを司る各 .config ファイルに設定が保管されることです。また、構成変更のタイミングで構成情報のバックアップをとっておくことが非常に大事となっています。バックアップ・戻しはぜひ下記でやるようにしましょう。
appcmd add backup “任意”
appcmd restore backup “任意”
自動で構成情報の履歴がとられる仕組みもあるので、下記のコマンドでは手動で取得した以外のものも並びます。
appcmd list backup
この後は、GUI およびコマンドでの Web サイトの作成を説明しました。コマンドは載せておきます。
–管理者実行でコマンドプロンプトを開く
–cd c:\windows\system32\inetsrv
–appcmd add apppool /name:”Site2”
–md c:\Site2
–appcmd add site /name:"Site2" /bindings:http/*:8081: /physicalPath:”c:\Site2”
–appcmd set app “Site2/” –applicationpool:”Site2”
あとは Server Core での構成でした。
•Windows PowerShell をインストール
–DISM /online /get-features
–DISM /online /enable-feature /feature-name:MicrosoftWindowsPowerShell /feature-name:ServerManager-PSH-Cmdlets
•Windows PowerShell を起動して、機能のインストール紹介
–Import-Module servermanager
–$module = Get-Module servermanager
–$module.ExportedCmdlets
–Add-WindowsFeature
インストールの確認
•Wfetchツールを利用
–Server Core でも動きます
–単独あるいは IIS 6.0 Resource Kit
•Windows PowerShell を利用
–$x = New-Object System.Net.WebClient
–$x.OpenRead(“http://localhost”)
–$x.ResponseHeaders.GetValues(“Server”)
これらに加えて、ログの設定、Log Parserの紹介、カスタムエラーページ、失敗した要求トレース、RSCA（実行状態表示）の説明をしました。
WSS 以降はまた今度ということで。。。
実は今回は Live Meeting でビデオを撮影していたので、それを間もなく公開できる予定です。それも案内しますね。
Alex Zambelli さんのブログ http://alexzambelli.com/blog/
原文： Smooth Streaming FAQ
（独自翻訳 by 奥主：正確な表現は原文を参照ください。）
この FAQ はできるだけ最新にアップデートしていくのでブックマークしていただいて、時折 更新されたかチェックいただけると幸いです。
Q: Smooth Streaming ってなんですか? A: Smooth Streaming は HTTPベース アダプティブストリーミングのマイクロソフトの実装です。
Q: アダプティブストリーミングって何ですか？ A: 従来のメディアストリーミングのように動作しながらも実は HTTP プログレッシブダウンロードを活用しているハイブリッドなコンテンツ配信方法です。要約すると、サーバーからクライアントへの連続した小刻みなHTTPダウンロードです。従って、一つの長いダウンロードでもなく、固定ビットレートのストリームでもありません。コンテンツは複数のビットレートでエンコードされているのが普通で、とても小さな「塊」の連続として送信されます。クライアント側ではネットワークの帯域状況、CPUの性能に応じて、動的に要求するビットレートを違うもの（異なるサイズ、異なる画質）に切り替えることができます。これにより、常にその時点での最良のビデオ品質を受信することが可能になります。
Q: マイクロソフトはこの技術をどのように展開するのですか？新しいプラグインなどをインストールしないといけないんでしょうか？ A: これは Smooth Streaming を使って何をしようとしているかによります。
Q: Smooth Streaming が実際に動作しているのをどこかで見れないのですか？ A: SmoothHD.com にアクセスしてみてください。オンデマンドの Smooth Streaming のデモがご覧いただけます。高速回線（3MBps以上）であれば最高 720ｐ HD のビデオコンテンツをご覧いただけます。Smooth Streaming の再生のための前提条件は Silverlight 2 のブラウザープラグインがマシンにインストールされていることだけです。
Q: Smooth Streaming の出荷時期はいつごろですか？ A: Smooth Streaming extension for IIS7 のベータ版は既に download 可能です。このバージョンの Smooth Streaming extension はオンデマンドストリーミングだけサポートします。最終版のこの IIS7 extension は 2009年 Q2 に出荷予定となります。 注意：UIも含めて日本語で出荷する時期を指していません。
Q: Smooth Streaming は Windows メディアサービスや Windows メディアプレイヤーと互換性があるのですか？ A: いいえ、ありません。 Smooth Streaming をサービスするには Windows Server 2008 と IIS7 が必要です。また、 Smooth Streaming 再生は Silverlight アプリケーションでのみ可能になっています。
Q: このストリーミングの技術は Windows メディア MBR (multiple bit rate) ストリーミングと何が違うのですか？ A: Windows メディアサービスはクライアントにコンテンツを配信する上で RTSP や WMS HTTP のような従来のストリーミングプロトコルを使用します。これらのプロトコルで配信されたコンテンツはエンコードされた固定のビットレートでストリーミングされ、ネットワークの状態に合わせてタイムリーにかつ動的に変動させることが困難です。つまり、利用帯域が減少しているようなネットワークの状態を把握した時には既に遅しであり、逆にネットワークの状態が回復した際にもよりよい品質に回復させることもできません。
一方で Smooth Streaming では、細切れにした多数の HTTP ダウンロードをベースにしています。そのためクライアントはダウンロードのスピードを常に評価しつつ 順次ダウンロードするビ���トレートを途中でも指定できるのでネットワークの状態に適した配信を要求することができます。さらに、インターネットは元来 HTTP 通信を行うためのインフラとして発展してきたので Smooth Streaming は特別なキャッシュやプロキシーの機構・機材を必要としないので既に存在しているホスティング事業者やCDNサービスを提供している場合でも今までの仕組みを利用することができます。このことでスケーラビリティ、アクセス上の制限（ファイアウォールを気にしない）そして、リーチを最大化することが可能になります。
Q: Smooth Streaming は実際にビデオファイルを数千に分割するのですか？ A: いいえ、ディスク上で物理的に分割をするのではありません。Smooth Streaming ファイル形式に対応したエンコーダーは内部的に連続した断片を一つにまとめた MP4 形式のファイル (ビットレート毎に１つのファイル) である *.ismv あるいは *.isma の拡張子のついた実体と XML 形式のマニフェストになっている *.ism と *.ismc として出力します。Smooth Streaming の最小セットは従って、３つのファイルになります。普通にエンコードされた場合には通常 6-8 のファイルが含まれることになります。 Smooth Streaming クライアントが IIS7 サーバーにファイル内の時間軸上のどの部分かを指定してリクエストした際にMP4ファイルは仮想的にサーバーで断片（塊）に分割され、独立したファイルとして通信されます。このことで、クライアントのリクエストは（経路上で）キャッシュされ、スケーラビリティの確保と通信の最適化が行われます。
Q: Smooth Streaming を使うとすべてのお客様に HD ビデオを提供することが保証されるのでしょうか？ A: いいえ。Smooth Streaming は奇跡を起こせるわけではありません。HTTP 配信を拡張して活用する仕組みに過ぎません。HD ビデオの配信は引き続き利用されるコーデック（VC-1, H.264 など）の効率に依存します。例えば、ほとんどのビデオを取り扱っている専門家もご同意いただけると思いますが、720p/24 ビデオは 2Mbps 以下の回線では満足できる品質レベルで配信することは難しいです。ということで、2 Mbps のエンコードされたビデオは当然リアルタイムで配信するには 2 Mbps のネットワーク帯域が必要ということになります。そしてこれを IIS7 や Silverlight が劇的に変化させることはできません。そもそも 既知の方法で 2 Mbps データを リアルタイム配信するのに 1 Mbps で済む、そんな方法があるならもう既にみんな使ってますよね、その方法を。
Smooth Streaming がしてくれるのは、そうではなくて、コンテンツ提供者が HD ビデオを 受信することができる（十分なネットワーク帯域とCPU能力がある）お客様に対して、ストリーミング全体の品質を犠牲にすることなく、一番低い品質に合わせるのではなく、最適な配信です。言い換えると、Smooth Streaming でコンテンツを提供する方は、聴衆の多くがどのビットレートが最適かを推測する必要がもう無いということです。代わりに幅広いビットレートの種類を用意してエンコードしておけば、クライアント側の処理で最適なものを動的に選択し、スムーズな再生を提供できます。
Q: マイクロソフトは以前にもアダプティブストリーミングを実装しなかったのでしょうか？ A: マイクロソフトは NBC Olympics 2008 のビデオサイトでアダプティブストリーミングのプロトタイプを開発しました。Smooth Streaming はマイクロソフトがそれを製品化したものです。
Q: Move Networks 社 はどうなんでしょう? Smooth Streaming は Move Networks アダプティブストリーミングのプラグインを置き換えるものなんでしょうか? A: いいえ。プラットフォームを提供しているマイクロソフトはアダプティブストリーミングの方式としてSilverlightプラットフォームを提供しており、パートナー様が実際には Silverlight が接続する先のサーバーの配信方式は選択できるようになっています。Move Networks 社が 2008 年に 発表した のはプレイヤーのコンポーネントとして Silverlight を採用いただけることです。しかし、サーバーの配信方式は既存のテクノロジーを使用しており、 Smooth Streaming を使用しているわけではありません。
John Bocharov の言葉を借りると、“私の視点では、我々が Smooth Streaming で提供しているのはプラットフォームテクノロジーであり、一方で Move Networks 社は革新的な Silverlight のプラットフォームを活用いただいているサービス ソリューション プロバイダーです。 私はこの関係を競合するサービスとは思っていません。目的とするところは、Silverlight へ ストリーミングメディアを提供する素晴らしいサービスを提供する エコシステム の創造であって、Move Networks 社とそのサービスは現在も今後も、引き続き強力で 尊敬すべきこのエリアのプレイヤーです。
Q: Smooth Streaming は新しいコーデックに基づいているんでしょうか? A: いいえ。Smooth Streaming は業界標準である VC-1 や H.264 コーデック、WMA や AAC 音楽コーデックををサポートしています。
Q: 既存のコンテンツをすべて再エンコードしないと Smooth Streaming で使用できないのでしょうか? A: 残念ですが、その通りです。 Smooth Streaming は標準的なコーデックを使用するとは言え、異なるビットレートのファイル間で正確なタイムスライスの一致、あるいは GOP や エントリーポイントヘッダーが要求されます。従って、オリジナルに対してコンテンツを Smooth Streaming 用に再エンコードすることを推奨しています。
Q: なんで Smooth Streaming ファイルを所有している MP4 プレイヤーで再生できないんでしょうか。MP4ベースなのではないのですか？ A: Smooth Streaming ファイル、そして通信書式は特定の MP4 ボックス構造であり、ライブ配信も考慮に入れたムービーフラグメントを多く使います。ISO ベースメディアファイル書式の規定では、(MP4 ファイル書式の規定）様々の書式オプションを可能にし、展開時の柔軟性を提供しています。これにより、すべての開発者やコンテンツ提供者は MP4 実装におけるすべての規約事項を取り入れているわけではありません。結果、今 お使いの特定の MP4プレイヤーが すべての MP4 ムービーフラグメント（"moof"、"mdat"）に関する規約を実装しているわけではなく、特に Smooth Streaming のMP4 ボックス構造に対応しているわけではありません。
さらに、SMPTE より、MP4 Registration Authority にて、VC-1 が MP4 コンテナのストレージとして正式に承認されました。MP4 ファイル形式は 大きく H.264 ビデオと AAC 音声コーデックに紐づいており、多くの MP4 プレイヤーはこれらのコーデックのみを受け付けるようになっています。最後に、現時点では WMA Standard と Professional 音声コーデックはどの標準団体からもまだ MP4 内に格納する場合のコーデックとして正式な承認を得られていないのでお使いの特定プラットフォームでサポートされていない可能性もあります。
Q: Smooth Streaming は H.264/AAC をサポートしているんでしょうか? A: はい。しかし、H.264/AAC でエンコードされた Smooth Streaming コンテンツを Silverlight クライアントに配信するには Silverlight 3 が必要です。H.264/AAC サポートは Silverlight 3 の新しい再生機能になります。
Q: Smooth Streaming は DRM コンテンツの保護をサポートするんでしょうか? A: はい。書式自身は既に PlayReady DRM サポートを含んでいます。機能自身は 3rd パーティのエンコードを行うソフトウェアが PlayReady AES ストリーミング暗号化サポートを製品として実装することで実現していきます。
ある意味初めて PowerPro メインサイトの企画に本格的に関わったので報告と早めのお知らせです。
Microsoft スキルチャージ プログラム http://www.microsoft.com/japan/powerpro/skillcharge/default.mspx
書籍「ひと目でわかるIIS7.0」つきの Web サーバー構築 を導入するための一式をインターネットに実際に接続されていることを証明する URL の報告などを条件にご提供します。無いのはインターネットに接続したり、立てるための通信周りだけなのでそれはご自身でご用意いただく必要があります。
インターネットに接続するためにどういうことをやらないといけないのかという点がはじめての方は難しいと思いましたので「虎の巻」を用意しました。このブログをご覧いただいた方は私の書いたものだとピンとくると思います。
フォーラムに書き込みが増えるといいなぁと思いつつ、フォーラムのリンクも載せてもらいました。
台数が無くなってしまう前にご応募いただける方は私のこの投稿を見て速攻で申し込んでください。 ただ、3/16 からです！！！
インタビュー云々と書いてありますが、要は私がインタビューにお伺いさせていただきたいということです、ぶっちゃけ。 「ひと目でわかるIIS7.0」は翻訳本ではないので学習するには本当にいい一冊だと思います。これは私も技術的なご質問を筆者にいただいて、色々な観点で携わった本でもあるので Kit に入れることを私が提案したのでした。。。
お申し込み お待ちしてます！！！！
以前 ご紹介しましたインプレス ITさんの インストールマニアックスで続報です。 http://tedia.jp/installmaniax/2008/
マイクロソフト本社ツアーが完了し、皆さん無事に帰国なさいました。（*^_^*）
上記のインストールマニアックスのサイトでレポートも出ているほか、他にも掲載があります。
同行なさった インプレスIT 田中さんのブログ http://d.hatena.ne.jp/hdkworks/
米国側の担当が書いているブログ Japanese LAMP Engineers Visit Redmond http://port25.technet.com/archive/2009/03/10/japanese-lamp-engineers-visit-redmond.aspx
PORT25 はマイクロソフトのオープンソースコミュニティ活動を発信するサイトとして2006年にオープンし、現在すごくアクセスのあるサイトになっています。ここにこのサイトのコンセプトが書いてありますが、No Marketing と断言するなどとても技術者指向のサイトになっており、相互運用関連の情報など結構拾いものな情報がここにはあると思っています。よろしければこれを機会にこのサイト（英語ですけど<(_ _)>）もご愛顧いただけると幸いです。
ご登録いただいた皆様、ありがとうございます！ 順調に参加者の数が増えていてうれしい状況です。まだ登録が可能ですのでご参加の登録、お待ちしています。
Tech Fielders セミナー 東京 [マイクロソフト製品で作る Web インフラ 基本編]http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032403036&Culture=ja-JP
さて、 3/20 の TF イベントにご参加される方がすごく多い（もう満員御礼）ですが、その影で実は 3/16 に初ものを導入しようとしています。私のこのセッションは Office Live Meeting を使ってライブ中継を行う予定です。
弊社のセミナーは日本ではなかなかまだライブ中継をするセッションは実施できていないんです。そんな中、経済状況などの背景で我々も思っているほど東京以外の場所でセミナーを実施できていない状況でもあり、東京で実施しているセミナーを中継できないかなぁと思っています。
ということで、、、
ということで「東京」でやっているのを中継しているだけですので、どちらからでもご参加いただけます！ でも初めての試みなんで何かトラブルが発生したら本当に申し訳ありません。先に謝っておきます。 その場合でも資料はご提供しますし、フォローアップでビデオをどこかに公開します。
こちらにご参加いただく場合には、事前に Live Meeting のクライアントをインストールいただく必要がありますので登録上の説明をよくお読みになってください。30分前から開場するようにしますからこちらで表示しているスライドと流している音楽が聞こえるかを確認しておくと本番もスムーズに接続できます。
原文： Smooth Streaming Architecture
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 を左でクリックしてください。
原文： The Birth of Smooth Streaming
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/
IIS の開発チームで Windows Media Service ・ IIS Media Pack を担当している Chris Knowlton が彼の下記のブログの中で紹介している Alex Zambelli（米国本社のエバンジェリスト）に連絡をとりました。是非 日本語でブログの内容を翻訳して掲載したいと連絡したところ、快諾を得られましたので何回かに分けて彼の書いているブログ投稿を日本語でお届けします。私も勉強になりました。リンク先は英語のままですが、ご容赦ください。
Smooth Streaming – What, Why, When, Where, and How
原文： A Brief History of Multi-Bitrate Streaming
マルチビットレート ストリーミングの簡単な歴史
私が前回投稿をしてからだいぶ時間が経ってしまいました。多分 Silverlightメディアに関してのマイクロソフトの発表で意義深いものは IBC (Silverlight 3 での H.264/AAC サポートを発表) 以来のものとしては IIS と Expression に関連するものだと思います。Expression エンコーダのチームは Service Pack 1 for Encoder 2 を10月に発表し、2.5と呼んでいいくらい新しい機能を搭載しています。Silverlight 2 テンプレート、デバイス向けの H.264/AAC 簡易エンコーディング、サーバーへの WebDAV 経由の発行、そして最も重要なのは 新しい Smooth Streaming フォーマットでのオンデマンド エンコーディングです。SP1 リリースについては Expression Encoder Team と James Clarke のブログで確認ください。
IIS メディアチームはその間、IIS Media Pack 1.0 をリリースしました。IIS7（Windows Server 2008）用の無償ダウンロードで 、IISへメディア機能を追加するものです。この最初のメディアパックのリリースは bitrate throttling と web playlists を含みます。しかし、もっとビッグなニュースが飛び込んできたのは 10月 28日 に Digital Hollywood でアナウンスした、Media Services 2.0 for IIS7 は新しい HTTP ベースのアダプティブ ストリーミング テクノロジーである Smooth Streaming が含まれるというものでした。この新しいテクノロジーをプロモーションするために私たちはショーケース Web サイト - SmoothHD.com – を Akamai Technologies 社とのパートナーシップのもとで構築しました。Akamai 社はさらに Smooth Streaming に基づいた最初のメディア配信サービス - Akamai AdaptiveEdge Streaming for Microsoft Silverlight を提供します。テクノロジーが良ければ良いほど、製品名が長くなりますね。
IIS media extensions についてのさらなる詳細については Chris Knowlton、Vishal Sood、あるいは John Bocharov の素晴らしいブログを読んでください。
このように多くのアダプティブストリーミングの話が最近行われていますが、高い確率で迷子になったり、混乱してしまうことも多いと思います。アダプティブ ストリーミングってなんだろう？Smooth Streaming って何だろう? MBR ストリーミングと関係があるんだろうか? Windows Mediaと互換性があるんだろうか？Windows メディアサービスと連動して動くのだろうか? Silverlight でサポートされているんだろうか？Move Networks はこれのどこに当てはまるのか？
そこで新しいテクノロジーの技術的な詳細に飛び込む前にまず一歩下がってマイクロソフトのマルチビットレート ストリーミング の歴史とどうやって Smooth Streaming にたどり着いたのかを説明しましょう。
メディアストリームをクライアント側の状態に合わせようとした最初の試みは “stream thinning” と呼ばれ、Microsoft がNetShow Services 3.0 や Windows Media Player 6.1 の一部として 1998 に公開したものでした。”Stream thinning” は自動的に利用可能帯域が下がるようなネットワークの状況を把握し、レスポンスのビデオフレームレートを減少させるものでした。さらに厳しい状況ではビデオの配信を取りやめて音声だけをストリームするように動作できました。
マルチビットレートスロットリングが最初に形を成したのは1999年で、Windows Media Technologies 4.0 (Windows NT 4.0) と Windows Media Player 6.4の一部としてでした。ASF ファイル書式は一つのファイル内に複数のビデオと音声のトラックを保持することができ、Windows Media ストリーミング プロトコルはブロードキャスト中にストリームを切り替える機能を持っていました。このテクノロジーは一般的に Multiple Bit Rate ASF、あるいは 単にMBR と呼ばれています。
2002年にマイクロソフトは Windows Media 9 シリーズをリリースしました。Windows Media Services 9 (Windows Server 2003) と Windows Media Player 9 はさらに改善された MBR テクノロジーを提供し、これは Intelligent Streaming と呼ばれました。Intelligent Streaming は帯域の検知、ストリームの減退、MBR ASF と Windows Media プレイヤー中の改善されたイメージ処理の組み合わせたものでした。Intelligent Streaming はもちろんWindows Media Encoder 9などのツールを使ってメディアがMBR ASFファイルとしてエンコードされている必要がありました。
このテクノロジー自身はよくデザインされたものでしたが、実装そのものは残念ながらいくつかの制限を抱えていました。ストリーミングしかできない（プログレッシブダウンロードができない）上に Windows Media サーバーからのみ配信できました。各種エンコーダは複数のビデオストリームに関連性があるように要求しなかったので、もちろんフレームレベルでの関連性はもちろんなく、ストリーム間での切り替えがシームレスに行なえるようにはなっていなかったのです。メディアがストリーミングで届けられていることとストリーミングのプロトコルが固定のレートで機能するため、正確に利用されるクライアント帯域値を予測することが特にそれをリアルタイムに行なうことは不可能です。ネットワーク状態の悪化が検知されたころにはもう既に遅しという状況になりました - プレイヤーは何度か再バッファリングを試みた後、ようやくビットレートをダウングレードしました。WMP のコードはその潜在能力をフルに発揮することはありませんでした。MBR ストリーミングはこのように要件にうまく適合した人もいれば、不十分だった人もいるという状況です。
一方で、、、ここ数年間のストリーミングメディア業界においての一つのトレンドは従来のストリーミングプロトコル(RTSP, MMS, RTMP など)から単純なHTTPダウンロードへの回帰です。証拠？YouTubeをご訪問ください。
なんでなんでしょう？この業界のトレンドにはいくつかの強力な理由があります。
メディア配信を想定してデザインされたストリーミングプロトコルですが、インターネット自身はHTTPをベースに構築され、HTTPの配信に関して最適化されていることがポイントなのです。インターネット全体をストリーミングプロトコルに適用するよりもむしろメディア配信の方法をインターネットに合わせる方向に進んだのは当然の帰結だったのでしょう。
Move Networks は戦略的な Microsoft Silverlight パートナーですが、機会を活用し、早くに新しいメディア配信サービスを提供しはじめ、adaptive streaming という新しいハイブリッド形式のメディアストリーミングのパイオニアになりました。彼らは HTTP ベースのメディア配信が大きな規模で実現できることを2008年に繰返し証明してみせました。オンデマンド配信 (ABC, ESPN, Discovery) そして ライブ配信 (Democratic National Convention) 双方でその例があります。 マイクロソフトも NBC Olympics でHTTPベースのアダプティブストリーミングの実装をプロトタイプして同様に証明をしました。
それではアダプティブストリーミングとは何で、従来のストリーミングと何が違うのか、今後の投稿で解説したいと思います。私の次の投稿にご期待ください。
独自翻訳（その１）でした。(*^_^*)