- エンタープライズIT / AV
オンライン動画配信の仕組みが変わった：
映像のエコシステムでは、競合する技術が長く平和的に共存することはめったにありません。
1970年代後半から1980年代にかけての、今では有名なビデオ戦争（ビデオテープの規格についての争い）は、業界が一つの技術に傾く速さと、それが競合他社に与える壊滅的な影響を示しました。1975年に業界が一斉にVHSに投票してから、3年も経たないうちにVHSがベータを追い抜いてしまいました。その後、1999年から2004年にかけての市場の変化では、VHSの売上はDVDに抜かれ、その後すぐに小さくなってしまいました。
From Beta to VHS to DVD: Case studies in how suddenly the video ecosystem can tip.
Sources: Business History Review, Nexus Research.
オンラインメディアも同様の大きな変化を経験しています。2010年1月、オンライン動画のたった10%がH.264圧縮形式を使用してエンコードされていましたが、2年も経たないうちに、その数は80%にまで増加しました(MeFeedia)。
これらの「事象の地平面（イベントホライズン）」では、市場の惰性が、時が来たメディアテクノロジーに屈しました。そして2015年、業界は次のノーリターン・ポイントに近づいています。
この10〜12年の間に、オンライン動画は、人々の楽しみ方、学生の学習方法、企業のコミュニケーション方法に欠かせないものとなりました。世界の消費者向けインターネット・トラフィックの3分の2以上は、すでに動画で構成されていると推定されており（Cisco ）、大企業ではすでに、従業員1人あたり月に14時間以上の動画をストリーミングしていると言われています（Gartner社）。
メディア配信技術は4つのフェーズに分かれて進化してきました。
オンラインメディアストリーミング技術の進化
1.HTTPダウンロード
動画ファイルがオンラインで共有されるようになった当初は、HTMLページや画像、文書などのウェブコンテンツと同じ配信メカニズムであるHTTP（Hypertext Transfer Protocol）を使って配信されていました。
当初は、動画を再生するためには、動画全体をダウンロードする必要がありました。 download and play と呼ばれるこのプロセスには、いくつかの重大な欠点がありました。まず、ダイアルアップの速度が28〜56kbpsであったため、ユーザーはほとんどの場合、再生に長い時間を要していました。第2に、複数の同時視聴者に効率的に対応する仕組みがありませんでした。また、限られた帯域幅は、動画の未視聴セグメントでしばしば無駄な時間がかかってしまうこともありました。たとえば、ユーザーが10分間の動画をクリックして最初の3分間しか見なかった場合、残りの7分間はネットワーク上で無駄にダウンロードされることになります。
Appleは、プログレッシブHTTPダウンロードとして知られる Fast Start のサポートをリリースし、HTTPベースの動画ダウンロードの問題点に対処しました。この方法では、重要なメタデータをメディアファイルの先頭に配置し、ファイル全体をダウンロードする前に動画の再生を開始することができます。プログレッシブダウンロードは現在も使用されていますが、2000年代初頭には、 ストリーミング と呼ばれる新しいタイプのオンライン動画配信用に構築された、カスタムプロトコルとサーバーに取って代わられました。
プログレッシブHTTPダウンロードにより、起動時間は改善されましたが、無駄な帯域幅やスケールの制限がありました。
2.カスタム・ストリーミング・プロトコル
オンラインで共有される他のコンテンツに比べて、動画ファイルは巨大です。iPhoneの動画は1分で80〜120MBものディスクスペースを占めます。同じ容量であれば、平均的なサイズのWord文書を250〜350個保存することができます(Microsoft)。
このため、帯域幅の限られたネットワーク上で動画ファイルを配信することは困難でした。そこで、ウェブや企業ネットワークで動画が普及するにつれ、メディア企業やソフトウェアベンダーが動画ストリーミング用のカスタムプロトコルを開発し始めました。RealNetworks社とNetscape社は、Real Time Streaming Protocol （RTSP）の開発と標準化に協力。マクロメディアを買収したアドビは、Flashベースの動画ストリーミング用にRTMP（Real Time Messaging Protocol）を導入し、マイクロソフト社は、Windowsアプリケーション用に、第3のストリーミングプロトコルであるMicrosoft Media Server (MMS)を開発しました。
RTSP、RTMP、MMSは、いずれも動画を特殊なケースとして扱っています。彼らは、従来のHTTPサーバーに加えて、プロトコル固有のストリーミングサーバーを配置し、「オーバーレイ・ネットワーク」を構築しました。ユーザーが動画再生のリクエストを出すと、そのリクエストはストリーミングサーバーに送られ、ストリーミングサーバーはユーザーの動画プレーヤーとの持続的な（または「ステートフル」な）接続を開きます。
ストリーミングプロトコルをカスタマイズするには、専用のサーバーやファイアウォールの設定、個別のキャッシュインフラが必要でした。
カスタム・ストリーミング・プロトコルは、HTTPプログレッシブダウンロードの課題の多くを克服しました。動画はネットワーク上で配信される際にバッファリング、処理、再生されるため、ユーザーは最小限の帯域幅の浪費で動画を途中で放棄することができます。また、ランダムアクセスにも対応しており、視聴者はビデオのどの位置からでも再生を開始することができます。ストリーミングサーバーからクライアントへの持続的な接続により、より予測可能なレイテンシー（遅延時間）を実現しています。また、いずれの場合も、これらのオーバーレイネットワークは、企業がプライマリWANトランスポートから動画トラフィックをオフロードするのに役立ち、ビデオの混雑がより優先度の高い情報やトランザクションデータの配信を妨げる可能性を低減しました。
しかし、RTMP、RTSP、MMSには限界がありました。これらのプロトコルは、動画を特殊なデータタイプとして扱うため、動画配信のコストと複雑さが増していました。まず、これらのプロトコルでは、企業ネットワーク全体に専用のサーバーを個別に配置する必要があり、ハードウェアとソフトウェアのインフラコストがかかります。第2に、ストリーミング・プロトコルは、配信メカニズムとキャッシング・メカニズムの間に拘束力があります。このため、企業は2つの別々のキャッシング技術（HTTPベースのトラフィック用と動画用）をサポートする必要があり、ネットワーク管理の複雑さが事実上2倍になります。3つ目は、RTMP、RTSP、MMSでは、管理者が通信用に追加のネットワークポートを開く必要があったことです（それぞれ1935、554、1755）。これにより、ネットワークの攻撃対象が拡大し、企業のファイアウォールによってプロトコルがブロックされる可能性が高くなります。最後に、カスタム・ストリーミング・プロトコルは、モバイル機器との互換性がないことが多いです。例えば、RTMPの再生にはFlashが必要ですが、このフォーマットはiOSデバイスではサポートされていないという難点があります。iOSのエコシステム以外でも、モバイルクライアントは頻繁に接続が中断されたり、IPアドレスが変更されたりします。そのため、1つのイベント中に何度もRTMP接続をやり直さなければならないことがありました。
3.マルチキャスト動画ストリーミング技術
マルチキャストが、オンライン動画配信の中でも特に重要な段階であったという主張は、この技術が企業や消費者のインターネット上でクリティカルマスに達しなかったことを考えると、寛大なものであると言えます。しかし、2000年代半ばには、動画用マルチキャストに強い関心が寄せられており、一部の企業ネットワークではこの技術が残っているため、議論の余地があります。
マルチキャストとは、送信者が同じデータを複数の受信者に同時に配信することができるネットワーク技術である。概念的には、ラジオを聴くのと似ています。ラジオを聴くときに、一人一人に個別の信号を送るのではなく、すべてのリスナーに一つのラジオ信号を送ります。適切に実装されたマルチキャストは、データ配信に驚くほどの効率をもたらしました。これをきっかけに、映像配信にマルチキャストを利用することが注目されました。
マルチキャストを使用すれば、理論的には、従来の のユニキャストによる の伝送に必要な帯域幅の何分の一かで、企業ネットワーク全体にライブ映像を配信することができます。そのため、企業は、ネットワーク・インフラをアップグレードするのではなく、帯域幅に制約のあるネットワークから追加のROIを得るための手段として、マルチキャストに注目していました。
ユニキャスト送信（左）は、接続された各クライアントに固有のストリームを送信するが、マルチキャスト（右）は、すべての加入クライアントが共有する単一のストリームを送信するものである。
残念ながら、マルチキャストのインフラ要件は、ほとんどの組織にとって実現不可能なものでした。マルチキャストを使って映像（またはデータ）を配信するためには、配信元、配信先、接続するネットワークインフラのすべてが、このプロトコルに対応していなければなりません。具体的には、企業ネットワーク内のすべてのルータ、ハブ、スイッチ、ファイアウォールがマルチキャストに対応していなければなりません。このような同質的なインフラの要件は、現実的ではなく、また回復力もありませんでした。
例えば、マルチキャスト通信が失敗した場合、代替手段として従来のユニキャスト通信を行うことが一般的でした。ほとんどの場合、このユニキャスト通信には、データキャッシングなどのWAN高速化などのネットワーク最適化の効果はなく、マルチキャストが唯一の最適化の手段となっていました。
また、マルチキャストは均質なネットワーク環境を必要とするため、企業や一般消費者のオンラインコミュニケーションの主流となっているネットワークトポロジーとは根本的に相容れないものでもありました。インターネットは、さまざまなネットワーク速度、接続タイプ、サービス品質（QoS）、エンドポイントデバイスに対応しています。その基盤となっているのがHTTPであり、このような異質な環境で動作するように特別に構築されたステートレスでメディアに依存しないプロトコルです。同様に、企業のファイアウォールの内側にあるネットワークも、ますます異質なものになっています。また、BYOD（Bring-Your-Own-Device：自分のデバイスを持ち込むこと）のトレンドにより、従業員はさまざまな機能やネットワーク要件を備えたタブレットやスマートフォンを持ち歩いています。また、業界の統合が進み、新たに買収したロンドンの支店とシアトルのホームオフィスが同じネットワーク・アーキテクチャを使用する可能性はますます低くなっています。
要約すると、マルチキャストは映像配信にとって、高望みではあるが現実的ではない願望でした。この10年間で、この技術への関心は着実に低下しています。
マルチキャストへの関心度、2004年～2015年ソースはこちらGoogle Trends
4.最新のHTTPストリーミング
2008年、マイクロソフトはSmooth Streamingを発表しました。Smooth Streamingは、HTTPと既存のネットワークインフラを利用しながら、カスタム・ストリーミング・プロトコルの多くの利点を提供する、ハイブリッドな動画配信方法です。Smooth StreamingはABR（Adaptive Bitrate）配信にも対応しており、視聴者は起動やシーク時間が短縮され、バッファリングが最小限に抑えられ、よりスムーズな再生が可能になりました。
アダプティブ・ビットレート・ストリーミングは、クライアントの接続速度に応じて動画の品質を動的に調整することで、起動やシーク時間の短縮、バッファリングの最小化、スムーズな再生を実現します。
HTTPベースのストリーミングは瞬く間に勢いを増し、市場のリーダーたちはこの技術にいち早く投資しました。2009年には、AppleがHTTP Live Streaming（HLS）を発表し、市場に参入しました。2010年には、アドビがHTTP Dynamic Streaming（HDS）を発表し、カスタム・ストリーミング・プロトコルからの脱却を図りました。さらに2010年以降は、Microsoft、Google、 Adobe、Netflix、エリクソン、サムスンなどの大手ストリーミング企業やメディア企業が、HTTPによるアダプティブ・動画・ストリーミングのオープンスタンダードであるMPEG-DASHの開発に協力しています。
Smooth Streaming、HLS、HDS、DASH などの技術革新により、HTTP ベースの動画配信が復活し、企業がネットワーク上で動画を配信する方法が大きく変わりました。
オンライン動画ストリーミングについてはこちら
最新のホワイトペーパー、 Modern Video Streaming in the Enterprise:Protocols, Caching, and WAN Optimization では、動画ストリーミングプロトコルを最新のものにする7つの特徴を含め、モダンストリーミングへの移行を推進する技術的な変化について深く考察しています。
また、既存のネットワークインフラを利用して、よりスケーラブルでコスト効率の高い動画配信を実現するために、Modern Streamingが企業にもたらす新たな機会についても紹介します。