- 企業向けIT・AV
オンライン動画配信の仕組みは変化した
動画業界において、競合する技術が長期間にわたって平和的に共存することは稀である。
1970年代後半から1980年代にかけて起きた、今や有名なビデオテープ規格戦争は、業界がいかに迅速に特定の技術に傾倒し、それが競合他社にどれほど壊滅的な打撃を与えるかを如実に示した。1975年に業界が総意でVHSを選択すると、わずか3年足らずでVHSはベータマックスを追い抜いた。 その後、1999年から2004年にかけての市場の変化の中で、VHSの売上はDVDに追い抜かれ、やがてその差は急速に拡大していった。
ベータからVHS、そしてDVDへ：映像業界の生態系がいかにして突然変化しうるか――その事例研究出典：『Business History Review』、Nexus Research。
オンラインメディアも同様の劇的な変化を経験してきた。2010年1月時点では、オンライン動画のうちH.264圧縮形式でエンコードされていたものはわずか10%に過ぎなかった。それから2年も経たないうちに、その割合は80%にまで急増した（MeFeedia）。
こうした転換点の一つひとつにおいて、市場の慣性は、その時が到来したメディア技術の前に屈した。そして2015年、業界は次の「後戻りできない地点」に近づきつつある。
ここ10年から12年の間に、オンライン動画は人々の娯楽、学生の学習、そして企業のコミュニケーションにおいて不可欠なものとなりました。世界の消費者向けインターネットトラフィックの3分の2以上がすでに動画で占められていると推定されており（シスコ）、大企業では従業員1人あたり月間14時間以上の動画をストリーミングしていると言われています（ガートナー）。
この間、メディア配信技術は4つの段階を経て進化してきました。
オンライン・メディア・ストリーミング技術の進化
1. HTTPダウンロード
動画ファイルが初めてオンラインで共有された当初、それらはハイパーテキスト転送プロトコル（HTTP）を用いて配信されていました。これは、HTMLページや画像、文書、その他のウェブコンテンツと同じ配信方式です。
当初、動画を再生するには、まず動画をすべてダウンロードする必要がありました。この「ダウンロード＆プレイ」と呼ばれる方式には、いくつかの顕著な欠点がありました。第一に、28～56 kbpsというダイヤルアップ回線の速度では、ユーザーはほぼ常に再生開始までの長い待ち時間に直面することになりました。第二に、複数の視聴者が同時にアクセスした場合に効率的に対応する仕組みがなかったのです。 さらに、限られた帯域幅が、視聴されない動画のセグメントに無駄に使われることがよくありました。例えば、ユーザーが10分間の動画をクリックして最初の3分間しか視聴しなかった場合、残りの7分間はネットワークを介して不必要にダウンロードされてしまうことになります。
Appleは、Fast Start（一般にプログレッシブHTTPダウンロードとして知られる）のサポートをリリースした際、HTTPベースの動画ダウンロードに関するいくつかの課題に対処しました。この手法では、重要なメタデータをメディアファイルの先頭に配置することで、ファイル全体がダウンロードされる前に動画の再生を開始できるようにしました。プログレッシブダウンロードは現在も使用されていますが、2000年代初頭には、ストリーミングと呼ばれる新しい形式のオンライン動画配信のために構築された独自のプロトコルやサーバーによって、その役割の大部分が代替されるようになりました。
プログレッシブHTTPダウンロードにより起動時間は改善されたものの、依然として帯域幅の無駄遣いやスケーラビリティの限界という課題が残っていた。
2. カスタムストリーミングプロトコル
オンラインで共有される他の種類のコンテンツと比べると、動画ファイルは容量が非常に大きい。iPhoneで撮影した1分間の動画は、80～120MBものディスク容量を占有することがある。同じ容量であれば、平均的なサイズのWord文書（Microsoft）を250～350通保存することができる。
この特性のため、帯域幅に制約のあるネットワーク上で動画ファイルを配信することは困難でした。そこで、ウェブや企業内ネットワークでの動画の利用が普及するにつれ、メディア企業やソフトウェアベンダーは、動画ストリーミング専用のプロトコルの開発に着手しました。RealNetworksとNetscapeは、Real Time Streaming Protocol（RTSP）の開発と標準化に共同で取り組みました。また、AdobeはMacromediaの買収を通じて、Flashベースの動画ストリーミング向けにReal Time Messaging Protocol（RTMP）を実装しました。 マイクロソフトは、さまざまなWindowsアプリケーションで使用するための3つ目のストリーミングプロトコルであるMicrosoft Media Server（MMS）を開発した。
RTSP、RTMP、MMSはいずれも、動画を特別なケースとして扱っていました。これらは、プロトコル固有のストリーミングサーバーが従来のHTTPサーバーと並列して配置される「オーバーレイネットワーク」を構築していました。ユーザーが動画の再生リクエストを送信すると、そのリクエストはストリーミングサーバーに転送され、サーバーはユーザーの動画プレーヤーに対して持続的（または「ステートフル」）な接続を確立しました。
カスタムストリーミングプロトコルには、専用のサーバー、ファイアウォールの設定、および独立したキャッシュインフラストラクチャが必要でした。
カスタムストリーミングプロトコルにより、HTTPプログレッシブダウンロードが抱えていた課題の多くが克服されました。動画はネットワーク経由で配信される過程でバッファリング、処理、再生が行われるため、ユーザーは再生途中で動画を中断しても、帯域幅の無駄を最小限に抑えることができました。 ランダムアクセスがサポートされたため、視聴者は動画内の任意の箇所にスキップして、すぐに再生を開始できるようになりました。ストリーミングサーバーからクライアントへの持続的な接続により、遅延がより予測可能になりました。そしていずれの場合も、これらのオーバーレイネットワークは、組織が主要なWANトランスポートから動画トラフィックをオフロードするのに役立ち、動画による輻輳が、優先度の高い情報やトランザクションデータの配信を妨げるリスクを低減しました。
しかし、RTMP、RTSP、MMSにも限界はあった。これらのプロトコルは動画を特殊なデータ型として扱っていたため、動画配信のコストと複雑さを増大させていた。第一に、これらのプロトコルでは、企業ネットワーク全体に専用のサーバー群を別途導入する必要があり、ハードウェアおよびソフトウェアのインフラコストが増加した。 第二に、ストリーミングプロトコルは配信メカニズムとキャッシュメカニズムを密接に結びつけてしまいました。これにより、組織は2つの別々のキャッシュ技術（1つはHTTPベースのトラフィック用、もう1つは動画用）をサポートする必要が生じ、事実上、ネットワーク管理の複雑さが倍増しました。第三に、RTMP、RTSP、およびMMSでは、通信のために管理者が追加のネットワークポート（それぞれ1935、554、1755）を開く必要がありました。 これにより、ネットワークの攻撃対象領域が拡大し、プロトコルが企業のファイアウォールによってブロックされる可能性が高まりました。最後に、カスタムストリーミングプロトコルは、多くの場合、モバイルデバイスと互換性がありませんでした。例えば、RTMPは再生にFlashを必要としましたが、このフォーマットはiOSデバイスではサポートされていないことで知られています。iOSエコシステム以外にも、モバイルクライアントでは接続の中断やIPアドレスの変更が頻繁に発生します。そのため、単一のイベント中に、アクティブなRTMP接続を何度も再確立する必要が生じることがよくありました。
3. マルチキャスト動画ストリーミング技術
マルチキャストがオンライン動画配信における独自の段階であったという主張は、この技術が企業向けでも一般消費者向けインターネットでも普及の臨界点に達しなかったことを考えれば、かなり大げさな言い方だ。とはいえ、2000年代半ばには動画向けマルチキャストに対して強い関心が寄せられており、一部の企業ネットワークでは現在もこの技術が利用されているため、議論する価値はある。
マルチキャストとは、送信者が同じデータを複数の受信者に同時に配信できるネットワーク技術でした。概念的には、ラジオを聴くことと似ています。個々のリスナーに個別の信号を送るのではなく、単一のラジオ信号がすべてのリスナーに送信されるのです。適切に実装されれば、マルチキャストはデータ配信において驚異的な効率化をもたらしました。これにより、動画配信におけるマルチキャストの利用に関心が集まる時期が訪れました。
マルチキャストを利用すれば、企業は理論上、従来のユニキャスト伝送 に必要な帯域幅のほんの一部で、社内ネットワークを介してライブ映像を配信することが可能になります。その結果、企業はネットワークインフラをアップグレードする代わりに、帯域幅に制約のあるネットワークからさらなる投資対効果（ROI）を引き出す手段として、マルチキャストに注目することが多くなりました。
ユニキャスト送信（左）では、接続されたクライアントごとに個別のストリームを送信しますが、マルチキャスト（右）では、登録しているすべてのクライアントで共有される単一のストリームを送信します。
残念ながら、マルチキャストに必要なインフラ要件のため、多くの組織では導入が困難でした。マルチキャストを使用して動画（あるいはその他のデータ）を配信するには、送信元、受信先、そして接続するネットワークインフラのすべてが、このプロトコルに対応している必要がありました。具体的には、企業ネットワーク内のすべてのルーター、ハブ、スイッチ、ファイアウォールがマルチキャストに対応していなければなりませんでした。このような均一なインフラを要求する仕様は、実用的でもなければ、耐障害性にも欠けていました。
例えば、マルチキャスト通信の試みが失敗した場合、通常は従来のユニキャスト送信に切り替わることになっていました。ほとんどの場合、マルチキャストが実装されていた唯一の最適化手法であったため、このユニキャスト送信では、データキャッシュやその他のWAN高速化技術といったネットワーク最適化の恩恵を受けることができませんでした。
さらに、マルチキャストは均一なネットワーク環境を必要としたため、現在も企業や一般消費者のオンライン通信において主流であるネットワークトポロジーとは根本的に相容れないものでした。インターネットは、幅広いネットワーク速度、接続タイプ、サービス品質（QoS）、エンドポイントデバイスに対応するように構築されています。その基盤となっているのはHTTPであり、これはこの異種混在環境下で機能するように特別に設計された、ステートレスでメディア非依存のプロトコルです。同様に、企業のファイアウォール内にあるネットワークも、ますます異種混在化が進んでいます。 BYOD（Bring Your Own Device）の普及により、従業員は機能やネットワーク要件の異なる様々なタブレットやスマートフォンを持ち歩くようになっています。また、業界の統合が進むにつれ、ロンドンに新設された支社が、シアトルの本社と同じネットワークアーキテクチャを採用する可能性はますます低くなっています。
要するに、マルチキャストは動画配信において、高邁ではあるものの非現実的な理想に過ぎなかった。過去10年間、この技術への関心は着実に低下している。
マルチキャストへの関心、2004年～2015年。出典：Google Trends。
4. 現代のHTTPストリーミング
2008年、マイクロソフトは「Smooth Streaming」を導入しました。これは、HTTPや既存のネットワークインフラを活用しつつ、カスタムストリーミングプロトコルの多くの利点を提供するハイブリッド型の動画配信手法です。Smooth Streamingはアダプティブ・ビットレート（ABR）配信にも対応しており、視聴者に対して、より速い起動時間とシーク時間、最小限のバッファリング、そしてよりスムーズな再生体験を提供しました。
アダプティブ・ビットレート・ストリーミングは、クライアントの接続速度に応じて動画の画質を動的に調整することで、起動や早送りの時間を短縮し、バッファリングを最小限に抑え、スムーズな再生体験を実現します。
HTTPベースのストリーミングは急速に普及し、他の市場をリードする企業もいち早くこの技術への投資に乗り出した。2009年、AppleはHTTP Live Streaming（HLS）の導入によりこの市場に参入した。 2010年、アドビはHTTP Dynamic Streaming（HDS）のリリースに伴い、独自のストリーミングプロトコルから重点を移行させた。そして2010年以降、マイクロソフト、グーグル、アドビ、ネットフリックス、エリクソン、サムスンをはじめとする主要なストリーミングおよびメディア企業は、HTTP経由の適応型ビデオストリーミングのためのオープンスタンダードであるMPEG-DASHの共同開発に取り組んでいる。
Smooth Streaming、HLS、HDS、DASHといった革新的な技術により、HTTPベースの動画配信が再び注目を集めるようになり、企業がネットワークを通じて動画を配信する方法にも大きな変革がもたらされました。
オンライン動画配信について詳しく知る
当社の最新のホワイトペーパーでは、 企業における最新のビデオストリーミング：プロトコル、キャッシュ、およびWAN最適化ここでは、モダン・ストリーミングへの移行を牽引する技術的な変化についてさらに詳しく見ていきます。これには、ビデオストリーミングプロトコルを「モダン」たらしめる7つの特徴も含まれます。
また、モダン・ストリーミングが組織にもたらす新たな可能性についても検討します。具体的には、既存のネットワークインフラを活用して、よりスケーラブルでコスト効率の高い動画配信を実現する方法についてです。