- エンタープライズIT/AV
オンラインビデオストリーミングの仕組みが変わった
ビデオのエコシステムでは、競合する技術が長く平和的に共存することは稀である。
1970年代後半から1980年代にかけての、今となっては有名なビデオテープのフォーマット戦争は、業界がある技術に傾くスピードの速さと、それが競合他社に与える壊滅的な影響を実証した。1975年に業界がVHSに投票したとき、この技術がベータマックスを追い越すのに3年もかからなかった。その後の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）を使って配信された。HTTPは、HTMLページ、画像、文書、その他のタイプのウェブベースのコンテンツで使われているのと同じ配信メカニズムである。
当初は、再生する前にビデオをまるごとダウンロードしなければならなかった。ダウンロード再生と呼ばれるこのプロセスには、いくつかの欠点があった。第一に、ダイヤルアップの速度が28kbpsから56kbpsであったため、ユーザーはほとんど常に長い再生遅延に遭遇することになった。第二に、複数の同時視聴者に効率的に対応する仕組みがなかった。最後に、限られた帯域幅が、未視聴の動画セグメントで浪費されることが多かった。たとえば、ユーザーが10分のビデオをクリックして、最初の3分しか見なかった場合、残りの7分はネットワーク経由で余計にダウンロードされたことになる。
アップルは、プログレッシブHTTPダウンロードとしてより一般的に知られているFast Startのサポートをリリースしたときに、HTTPベースのビデオダウンロードの問題のいくつかに対処した。このアプローチでは、重要なメタデータをメディアファイルの先頭に配置し、ファイル全体がダウンロードされる前に動画の再生を開始できるようにした。プログレッシブ・ダウンロードは現在でも使用されているが、2000年代初頭には、ストリーミングと呼ばれる新しいタイプのオンライン・ビデオ配信用に構築されたカスタム・プロトコルやサーバーに取って代わられた。
プログレッシブHTTPダウンロードは起動時間を改善したが、それでも帯域幅の浪費とスケールの制限に悩まされた。
2.カスタムストリーミングプロトコル
オンラインで共有される他のタイプのコンテンツに比べて、ビデオファイルは巨大です。iPhoneの動画は、1分間に80MBから120MBものディスク容量を消費します。これと同じ容量の中に、平均的なサイズのWord文書（マイクロソフト）を250から350個保存できる。
この特性により、帯域幅に制約のあるネットワーク上でビデオファイルを配信することが困難になっていた。そのため、動画がウェブや企業ネットワークで普及するにつれ、メディア企業やソフトウェアベンダーは動画ストリーミング用のカスタムプロトコルを開発し始めた。RealNetworksとNetscapeは、Real Time Streaming Protocol（RTSP）の開発と標準化で協力した。AdobeはMacromediaの買収を通じて、Flashベースのビデオストリーミング用にReal Time Messaging Protocol（RTMP）を実装した。マイクロソフトは第3のストリーミング・プロトコルであるマイクロソフト・メディア・サーバー（MMS）を開発し、さまざまなウィンドウズ・アプリケーションで使用した。
RTSP、RTMP、MMSはすべて、ビデオを特別なケースとして扱った。彼らは、プロトコル固有のストリーミング・サーバーが従来のHTTPサーバーと並存する「オーバーレイ・ネットワーク」を構築した。ユーザーがビデオ再生のリクエストを開始すると、そのリクエストはストリーミング・サーバーにルーティングされ、ストリーミング・サーバーはユーザーのビデオプレーヤーへの持続的（または「ステートフル」）接続をオープンする。
カスタム・ストリーミング・プロトコルには、専用のサーバー、ファイアウォールの設定、個別のキャッシュ・インフラが必要だった。
カスタムストリーミングプロトコルは、HTTPプログレッシブダウンロードの多くの課題を克服しました。動画は、ネットワーク上で配信される際にバッファリング、処理、再生されるため、ユーザーは帯域幅の無駄を最小限に抑えながら、動画の途中で再生を断念することができます。ランダムアクセスがサポートされているため、視聴者は動画のどのポイントからでも探して素早く再生を開始することができます。ストリーミング・サーバーからクライアントへの持続的な接続は、より予測可能なレイテンシーを提供した。また、どのような場合でも、これらのオーバーレイ・ネットワークは、組織がプライマリWANトランスポートからビデオ・トラフィックをオフロードするのに役立ち、ビデオの輻輳がより優先順位の高い情報やトランザクション・データの配信を危険にさらす可能性を低減した。
しかし、RTMP、RTSP、MMSに制限がなかったわけではない。これらのプロトコルは、ビデオを特殊なデータタイプとして扱うため、ビデオ配信のコストと複雑さを増大させた。第一に、これらのプロトコルは、企業ネットワーク全体に専用のサーバーを個別に配置する必要があり、ハードウェアとソフトウェアのインフラコストが増加した。第二に、ストリーミング・プロトコルは、配信とキャッシングのメカニズム間にバインディングを生じさせる。このため、企業は2つの別々のキャッシング技術（HTTPベースのトラフィック用とビデオ用）をサポートする必要があり、ネットワーク管理の複雑さが実質的に倍増した。第三に、RTMP、RTSP、およびMMSは、管理者が通信用に追加のネットワーク・ポート（それぞれ1935、554、および1755）を開く必要があった。このため、ネットワークの攻撃対象が拡大し、プロトコルが企業のファイアウォールでブロックされる可能性が高まった。最後に、カスタム・ストリーミング・プロトコルは、モバイル・デバイスと互換性がないことが多かった。例えば、RTMPは再生にFlashを必要とするが、このフォーマットはiOSデバイスではサポートされていないことで有名だ。iOSのエコシステム以外にも、モバイルクライアントは頻繁に接続が中断され、IPアドレスが変更される。そのため、アクティブなRTMP接続を1つのイベント中に何度も再確立する必要がある。
3.マルチキャスト・ビデオ・ストリーミング技術
マルチキャストがオンライン・ビデオ配信の明確な段階であったという主張は、この技術が企業でも消費者インターネットでもクリティカル・マスに達しなかったことを考えると、寛大なものである。しかし、2000年代半ばには、動画配信のマルチキャストに強い関心が寄せられ、一部の企業ネットワークではこの技術が存続している。
マルチキャストは、送信者が同じデータを同時に複数の受信者に配信することを可能にするネットワーク技術だった。概念的には、ラジオを聴くのに似ている。チューニングしている各人に固有の信号を送信するのではなく、単一の無線信号をすべてのリスナーに送信する。マルチキャストが適切に実装されれば、データ配信に驚くほどの効率性が生まれた。このため、ビデオ配信にマルチキャストを使うことに関心が集まった時期があった。
マルチキャストを使用すれば、理論的には、従来のユニキャスト 伝送に必要な帯域幅のほんの一部を使用して、企業ネットワーク全体にライブビデオを配信することができます。その結果、企業はネットワーク・インフラをアップグレードするよりも、帯域幅に制約のあるネットワークからさらなるROIを得る方法として、マルチキャストに注目することが多くなりました。
ユニキャスト伝送（左）は、接続された各クライアントに固有のストリームを送信し、マルチキャスト（右）は、すべてのサブスクライブ・クライアントが共有する単一のストリームを送信する。
残念ながら、マルチキャストのインフラ要件により、ほとんどの組織では実現不可能でした。マルチキャストを使用してビデオ（または任意のデータ）を配信するには、ソース、受信者、接続するネットワーク・インフラストラクチャのすべてが、このプロトコルをサポートする必要がありました。具体的には、企業ネットワーク内のすべてのルーター、ハブ、スイッチ、ファイアウォールがマルチキャストに対応していなければならなかった。このような均質なインフラという要件は、実用的でも回復力もありませんでした。
例えば、マルチキャスト通信が失敗した場合、フォールバックは通常、従来のユニキャスト通信であった。ほとんどの場合、このユニキャスト伝送は、データ・キャッシュやその他のWAN高速化技術などのネットワーク最適化の恩恵を受けていなかった。
さらに、マルチキャストは均質なネットワーキング環境を必要とするため、現在でもビジネスや消費者のオンライン・コミュニケーションを支配しているネットワーク・トポロジーとは根本的に相容れないものだった。インターネットは、さまざまなネットワーク速度、接続タイプ、サービス品質（QoS）、エンドポイントデバイスに対応するように構築されている。その基盤はHTTPで、この異種環境で動作するように特別に構築されたステートレスでメディアに依存しないプロトコルです。同様に、企業のファイアウォールの背後にあるネットワークは、ますます異種混在になっています。BYOD（Bring-your-own-device）のトレンドは、従業員がさまざまな機能とネットワーク要件を持つさまざまなタブレットやスマートフォンを携帯していることを意味します。また、業界の統合が進んでいるため、ロンドンに新しく設立された支社がシアトルの本社と同じネットワーク・アーキテクチャを使用する可能性はますます低くなっている。
要約すると、マルチキャストはビデオ配信のための高尚だが非現実的な願望であった。過去10年間、この技術に対する関心は確実に低下している。
マルチキャストへの関心（2004年～2015年）。出典：Google Trends。
4.最新のHTTPストリーミング
2008年、マイクロソフトは、HTTPと既存のネットワークインフラを活用しながら、カスタムストリーミングプロトコルの多くの利点を提供する動画配信のハイブリッドアプローチであるSmooth Streamingを発表しました。Smooth Streamingはまた、アダプティブ・ビットレート（ABR）配信をサポートし、視聴者に高速起動とシーク時間、最小限のバッファリング、よりスムーズな再生体験を提供しました。
アダプティブ・ビットレート・ストリーミングは、クライアントの接続速度に応じてビデオ品質を動的に調整することで、高速な起動とシーク時間、最小限のバッファリング、スムーズな再生体験を提供します。
HTTPベースのストリーミングは瞬く間に勢いを増し、他の市場リーダーもいち早くこの技術に投資した。2009年、アップルはHTTPライブストリーミング（HLS）を発表し、市場に参入した。2010年にはAdobeがHTTP Dynamic Streaming（HDS）をリリースし、カスタムストリーミングプロトコルからの脱却を図った。そして2010年以降、マイクロソフト、グーグル、アドビ、ネットフリックス、エリクソン、サムスンなど、主要なストリーミング・メディア企業が、HTTP経由のアダプティブ・ビデオ・ストリーミングのオープンスタンダードであるMPEG-DASHで協力している。
Smooth Streaming、HLS、HDS、DASHのような技術革新は、HTTPベースの動画配信を復活させ、企業がネットワーク上で動画を配信する方法を激変させた。
オンライン・ビデオ・ストリーミングの詳細
私たちの最新のホワイトペーパーでは 企業における最新のビデオストリーミング：プロトコル、キャッシュ、WAN最適化ビデオ・ストリーミング・プロトコルをモダンにする7つの特徴など、モダン・ストリーミングへの移行を推進する技術的なシフトについて詳しく見ていく。
また、既存のネットワーク・インフラを利用して、よりスケーラブルでコスト効率の高いビデオ配信を実現するモダンストリーミングの新たな可能性についても紹介する。