Loading article…
アダプティブビットレートストリーミングは、コンピュータネットワーク上でマルチメディアをストリーミングする際に使用される技術です。
過去には、ほとんどのビデオやオーディオのストリーミング技術は、RTSPを使用したRTPなどのパケット化されたステートフルなシングルビットレートのストリーミング プロトコルを使用していましたが、今日の適応型ストリーミング技術はほぼ完全にHTTPに基づいており、[ 1 ]大規模な分散 HTTP ネットワーク上で効率的に動作するように設計されています。
アダプティブビットレートストリーミングは、ユーザーの帯域幅、CPU の能力、デバイスの種類 (スマートフォン、デスクトップコンピュータ、スマート TVなど) をリアルタイムで検出し、それに応じてメディアストリームの品質を調整することで機能します。[ 2 ]これには、単一のソースメディア (ビデオまたはオーディオ) を複数のビットレートでエンコードするエンコーダの使用が必要です。プレーヤークライアントは、利用可能なリソースに応じて、異なるエンコードのストリーミングを切り替えます。[ 3 ] [ 4 ]これにより、バッファリングが非常に少なくなり、起動時間が速くなり、ハイエンド接続とローエンド接続の両方で良好なエクスペリエンスが提供されます。[ 5 ]
より具体的には、アダプティブ ビットレート ストリーミングは、ソース コンテンツが複数のビット レートでエンコードされる HTTP 経由のビデオ ストリーミング方式です。異なるビット レートのストリームはそれぞれ、数秒の小さな部分に分割されます。[ 3 ] [ 4 ]まず、クライアントは、利用可能なストリーム セグメントとそのそれぞれのビット レートを記述したマニフェスト ファイルをダウンロードします。ストリームの開始時に、クライアントは通常、最も低いビット レートのストリームからセグメントを要求します。クライアントが、ダウンロードしたセグメントのビット レートよりもネットワーク スループットが大きいと判断した場合、より高いビット レートのセグメントを要求します。その後、クライアントがネットワーク スループットが低下したと判断した場合、より低いビット レートのセグメントを要求します。クライアント内のアダプティブ ビットレート (ABR) アルゴリズムは、ネットワークの現在の状態に基づいて、どのビット レート セグメントをダウンロードするかを決定するという重要な機能を実行します。 ABRアルゴリズムにはいくつかの種類があり、商用利用されています。スループットベースのアルゴリズムは、最近のダウンロードで達成されたスループットを意思決定に使用します（例：dash.jsのスループットルール）。バッファベースのアルゴリズムは、クライアントの現在のバッファレベルのみを使用します（例：dash.jsのBOLA [ 6 ]）。ハイブリッドアルゴリズムは、両方のタイプの情報を組み合わせます（例：dash.jsのDYNAMIC [ 7 ]）。
公共インターネット経由でライブまたはオンデマンドでコンテンツを配信する必要のあるビデオストリーミングサービス（オーバーザトップメディアサービスとも呼ばれる）は、バッファリングの中断を最小限に抑えながら消費者に最高品質の体験を提供するために、アダプティブビットレート技術を使用します。コンテンツ配信ネットワークを使用してHTTP経由で配信される場合、アダプティブビットレートストリーミングは、数百万人の視聴者に同時にストリーミングビデオコンテンツをサポートするように簡単に拡張できます。[ 8 ] Netflix、Disney、NBC Universal、 Warner Bros. Discovery 、Apple、Google、Amazonなどが運営する世界最大のストリーミングサービスはすべて、長年にわたってアダプティブビットレート技術を積極的に使用しており、ハイエンドストリーミングプロバイダーの標準的な慣行となっています。[ 9 ] [ 10 ]
従来のサーバー主導型アダプティブビットレートストリーミングは、メディアサーバーが各ユーザーのネットワークと再生条件の変化に自動的に適応するため、ストリーミングメディアの消費者に可能な限り最高の体験を提供します。[ 11 ]メディアおよびエンターテイメント業界もアダプティブビットレートストリーミングの恩恵を受けています。ビデオスペースが拡大するにつれて、コンテンツ配信ネットワークとビデオプロバイダーは、顧客に優れた視聴体験を提供できるようになります。アダプティブビットレート技術は追加のエンコードを必要としますが、ワークフロー全体を簡素化し、より良い結果を生み出します。
HTTP ベースの適応型ビットレート ストリーミング技術は、従来のサーバー主導の適応型ビットレート ストリーミングよりも多くの利点があります。まず、ストリーミング技術はRTPベースの適応型ストリーミングとは異なりHTTP上に構築されているため、パケットはファイアウォールやNATデバイスを通過する際に問題がありません。次に、HTTP ストリーミングは完全にクライアント主導であるため、すべての適応ロジックはクライアントにあります。これにより、サーバーとクライアント アプリケーション間の永続的な接続の必要性が軽減されます。さらに、サーバーは各クライアントのセッション状態情報を維持する必要がないため、スケーラビリティが向上します。最後に、HTTP キャッシュやサーバーなどの既存の HTTP 配信インフラストラクチャをシームレスに採用できます。[ 12 ] [ 13 ] [ 14 ] [ 15 ]
スケーラブルなCDN は、インターネットの視聴者にメディア ストリーミングを配信するために使用されます。CDN は、オリジン サーバーでソースからストリームを受信し、それを多数またはすべてのエッジ キャッシュ サーバーに複製します。エンド ユーザーがストリームを要求すると、「最も近い」エッジ サーバーにリダイレクトされます。これは、libdash [ 16 ]と、ヨーロッパ、アジア、米国に複数のミラーを持つ Distributed DASH (D-DASH) データセット[ 17 ]を使用してテストできます。HTTP ベースの適応型ストリーミングを使用すると、エッジ サーバーは、ライセンス費用が安価または無料のシンプルな HTTP サーバー ソフトウェアを実行できるため、高価なメディア サーバー ライセンス ( Adobe Flash Media Streaming Server など) と比較して、ソフトウェア ライセンス コストを削減できます。HTTP ストリーミング メディアの CDN コストは、HTTP Web キャッシュ CDN コストと同程度になります。
DVD Forum は2002 年 10 月に、東芝とPhoenix Technologiesが共同議長を務める WG1 特別ストリーミンググループを設立しました[ 18 ]。このグループには、 Microsoft、Apple Computer、DTS Inc.、Warner Brothers、20th Century Fox、Digital Deluxe、Disney、Macromedia、Akamaiが参加しました。このグループは、DVD over IP として知られる DVD コンテンツのオンライン配信方法の開発と標準化を担当し、これは拡張 DVD フォーマット仕様 ( DVD-ENAV )の不可欠な部分となりました[ 19 ] 。指定された DVD-ENAV ストリーミング方法の 1 つは、MPEG-1および MPEG-2 DVD TS セクターを、HTTP サーバーを使用してプレーヤーに提供できる 2 KB の小さなファイルにパックすることを説明していました。MPEG-1 セグメントは低帯域幅のストリームを表し、MPEG-2 セグメントは高ビットレートのストリームを表していました。付属の XML スキーマは、ビットレート、言語、および URL サーバーのシンプルなプレイリストを提供しました。ただし、仕様では動的なビットレート切り替えは提案も定義もされていませんでした。
SProxyと呼ばれる初期のHTTPウェブサーバーベースのストリーミングシステムは、2006年にヒューレット・パッカード研究所で開発され、展開されました。[ 20 ] [ 21 ]これは、HTTP範囲リクエストを使用してコンテンツを小さなセグメントに分割する方法を示しました。SProxyは、ファイアウォールの広範な展開により最高のインターネット浸透率を獲得し、ユーザーが終了前にストリーミングセッションを終了することを選択した場合に不要なトラフィック送信を削減することで、セグメントベースのストリーミングの有効性を実証しました。
最新のアダプティブ ビットレート ストリーミング over HTTP は、Move Networks によって 2004 年から 2006 年にかけて開発され、ABC Networksが新しい HD ビデオ ストリーミング Web サイトのストリーミング ソリューションとして採用した 2007 年に世界的に注目を集めるようになりました。[ 22 ] [ 23 ]当初は Quantum Streaming という名前だった ABR 技術は、Move Simulcode (ビデオ エンコーディング)、Move Publish (コンテンツの公開、保存、デジタル著作権管理)、Move Play (プレーヤー)、Move Monetize (視聴データ分析) を含む Move Media Services という製品群に組み込まれました。[ 24 ] Move Networks の ABR 技術は、 NAB の週刊テクノロジー ニュースレターで次のように説明されました。 [ 23 ]
同社のシステムは、専用のメディアサーバーではなく、標準的なWebサーバーからビデオをストリーミング配信し、標準的なWebページで使用されるのと同じHTTPプロトコルを採用しています。ビデオストリームは、Move NetworksがQuantum Streamingと呼ぶシステムによって短い断片に分割され、小さな単位でキャッシュされます。このシステムは、インターネットの混雑やパケットロスによる悪影響を回避することを目的としています。プレーヤーは、ネットワークの状態と各メディア利用者のローカル環境に基づいて、ストリームの品質を自動的に調整します。
— 「高解像度インターネットストリーミングビデオ」、NAB TV TechCheck（2007年7月）
2010年10月、Move Networksは、2004年4月に提出した仮特許出願に基づき、適応型ビットレートストリーミングの発明に関する特許（米国特許番号7818444）を取得しました。[ 25 ] [ 26 ]
Move NetworksがHTTPベースのABRストリーミングが従来のパケット化されたストリーミングプロトコルに代わる実行可能な商用ソリューションであることを実証した後、HTTPベースのABRの実装はすぐに他の企業にも登場した。
Dynamic Adaptive Streaming over HTTP (DASH)、別名 MPEG-DASH は、国際標準である唯一の適応型ビットレート HTTP ベースのストリーミング ソリューションです[ 27 ]。MPEG -DASH 技術はMPEGの下で開発されました。DASH に関する作業は 2010 年に開始され、2011 年 1 月にドラフト国際標準となり、2011 年 11 月に国際標準となりました。[ 27 ] [ 28 ] [ 29 ] MPEG-DASH 標準は、 2012 年 4 月にISO/IEC 23009-1:2012として発行されました。
MPEG-DASH は、 Adobe Systems HTTP Dynamic Streaming、Apple Inc. HTTP Live Streaming (HLS)、およびMicrosoft Smooth Streamingに関連する技術です。[ 30 ] DASH は、3GPP Release 9 の Adaptive HTTP Streaming (AHS) とOpen IPTV Forum Release 2の HTTP Adaptive Streaming (HAS) に基づいています。 [ 31 ] MPEG との協力の一環として、3GPP Release 10 は、無線ネットワークで使用するために DASH (特定のコーデックと動作モード付き) を採用しました。[ 31 ]
アダプティブストリーミングソリューションを標準化する目的は、AppleのHLS、MicrosoftのSmooth Streaming、AdobeのHDSなど、特定のベンダーに特化した他のソリューションとは異なり、そのソリューションが普遍的に機能することを市場に保証することにある。
利用可能な実装としては、HTML5 ベースのbitdash MPEG-DASH プレーヤー[ 32 ]、bitmovin GmbH のオープンソース C++ ベースの DASH クライアント アクセス ライブラリlibdash [ 16 ] 、アルペン アドリア大学クラーゲンフルトの情報技術研究所 (ITEC) の DASH ツール[ 3 ] [ 33 ]、Telecom ParisTech の GPAC グループのマルチメディア フレームワーク[ 34 ]、およびDASH-IFのdash.js [ 35 ]プレーヤーなどがあります。
HTTP Live Streaming (HLS) は、 Apple Inc.がQuickTime XおよびiOSの一部として実装した HTTP ベースのメディア ストリーミング通信プロトコルです。HLS は、ライブ コンテンツとビデオ オンデマンドコンテンツの両方をサポートします。HLS は、メディア ストリームまたはファイルを短い断片 (メディア セグメント) に分割し、MPEG-TSまたは断片化された MP4ファイルとして保存することで機能します。これは通常、パッケージャーとも呼ばれるストリームまたはファイル セグメンテーション アプリケーションを使用して、複数のビットレートで実行されます。このようなセグメンテーション 実装の 1 つは Apple によって提供されています。[ 36 ] Google の Shaka Packager [ 37 ]のような無料のオープンソース製品や、Unified Streaming [ 38 ]などのさまざまな商用ツールなど、追加のパッケージャーが利用可能です。セグメンテーション アーは、メディア チャンクを記述する M3U8 形式のプレイリスト ファイルのセットを生成する役割も担います。各プレイリストは特定のビットレートに特化しており、そのビットレートのチャンクへの相対 URL または絶対 URL が含まれています。クライアントは、利用可能な帯域幅に応じて適切なプレイリストを要求する役割を担います。
HTTPライブストリーミングはiPhone 3.0以降のバージョンに標準搭載されている機能です。[ 39 ]
Apple は、情報提供依頼書 (Request for Comments)としてIETFにソリューションを提出しました。[ 40 ]これは正式にRFC 8216として承認されました。サーバー実装 (セグメンター) とクライアントプレーヤーの両方について、多数の独自およびオープンソースのソリューションが存在します。
HLS ストリームは、 m3u8というプレイリスト URL フォーマット拡張子、または application/vnd.apple.mpegurl という MIME タイプで識別できます。 [ 41 ]これらの適応型ストリームはさまざまなビットレートで利用可能になり、クライアント デバイスはサーバーとやり取りして、確実に配信できる最適なビットレートを取得します。
HLSの再生は、macOS/iOSのSafariやネイティブアプリ、Windows 10のMicrosoft Edge、AndroidのExoPlayer、Rokuプラットフォームなど、多くのプラットフォームでサポートされています。多くのスマートテレビもHLSをネイティブでサポートしています。ChromeやFirefoxなどの他のプラットフォームでHLSを再生するには、通常、ブラウザ/JavaScriptプレーヤーの実装が必要です。hls.js、video.js http-streaming、BitMovin、JWPlayer、THEOplayerなど、多くのオープンソースおよび商用プレーヤーが利用可能です。
HTTPダイナミックストリーミングとは、再生中に品質やサイズが異なるさまざまなストリームを動的に切り替えることで、ストリーミングビデオをユーザーに効率的に配信するプロセスです。これにより、ユーザーは自身の帯域幅とローカルコンピュータのハードウェア（CPU）がサポートできる最高の視聴体験を得ることができます。ダイナミックストリーミングのもう1つの大きな目標は、このプロセスをユーザーにとってスムーズかつシームレスにすることです。つまり、ストリームの品質をアップスケールまたはダウンスケールする必要がある場合でも、連続再生を中断することなく、スムーズでほとんど気づかれない切り替えが行われます。[ 42 ]
Flash Player と Flash Media Server は、従来のRTMPプロトコルだけでなく、Apple や Microsoft の HTTP ベースのソリューションと同様にHTTP上での適応型ビットレート ストリーミングをサポートしていました。 [ 43 ] HTTP 動的ストリーミングは Flash Player 10.1 以降でサポートされています。[ 44 ] HTTP ベースのストリーミングには、Web ブラウザーが通常使用するポート以外にファイアウォール ポートを開放する必要がないという利点があります。また、HTTP ベースのストリーミングでは、ビデオ フラグメントをブラウザー、プロキシ、CDNでキャッシュできるため、ソース サーバーへの負荷が大幅に軽減されます。
Smooth Streaming は、HTTP を介してクライアントにメディアを適応的にストリーミングできるようにするIIS Media Services 拡張機能として開発されました。 [ 45 ] [ 46 ]メディアストレージ形式はISO ベースメディアファイル形式に基づいており、Microsoft によって Protected Interoperable File Format 仕様として公開されました。[ 47 ] Microsoft は、適応ビットレート HTTP ストリーミングの標準化に向けた 3GPP 、 MPEG 、 DECE組織の取り組みに積極的に関与し、最終的にDASH標準の公開につながりました。Microsoft は、 SilverlightおよびWindows Phone 7用の Smooth Streaming Client ソフトウェア開発キットと、Apple iOS、Android、Linux などの他のクライアントオペレーティングシステムで使用できる Smooth Streaming ポーティングキットを提供しました。[ 48 ] 2010 年 11 月にリリースされた IIS Media Services 4.0 では、Live Smooth Streaming H.264/AAC ビデオを Apple HTTP Adaptive Streaming 形式に動的に再パッケージ化し、再エンコードの必要なく iOS デバイスに配信できる機能が導入されました。 2009年から2013年にかけて、マイクロソフトはSmooth Streamingを使用してSilverlightクライアントにライブおよびオンデマンドの1080p HDビデオを配信することに成功しました。2010年には、NVIDIAと提携して、NVIDIA 3D Visionテクノロジーを搭載したPCに1080p立体視3Dビデオをライブストリーミングするデモンストレーションも行いました。[ 49 ]
2013年、マイクロソフトはメディアサービス製品の提供をクラウドに移行し、Azure Media Servicesの中核コンポーネントとしてSmooth Streamingのサポートを継続しました。[ 50 ]しかし、MPEG DASHとHLSが業界標準として開発および採用されたことにより、その10年の終わりまでに、Smooth Streamingはマイクロソフトが推奨する適応型ストリーミング技術としての地位を徐々に失いました。2023年6月、マイクロソフトはAzure Media Servicesの廃止を2024年6月に発表しました。この発表ではSmooth Streamingという名前は明示的に言及されていませんでしたが、事実上、アクティブなマイクロソフト製品でのSmooth Streamingのサポート終了を意味していました。[ 51 ]
CMAFは、HLSとMPEG-DASHの両方の配信に使用されるプレゼンテーションコンテナフォーマットです。そのため、HTTPベースのストリーミングメディアの配信を簡素化することを目的としています。2016年にAppleとMicrosoftによって提案され、2018年に正式に公開されました。[ 52 ]
近年、適応型ビットレート ストリーミングにおける自己学習アルゴリズムの利点が学術界で研究されている。初期の自己学習アプローチのほとんどはサーバー側で実装されているが[ 53 ] [ 54 ] [ 55 ] (例えば、強化学習や人工ニューラル ネットワークを使用したアドミッション コントロールの実行)、より最近の研究は自己学習 HTTP 適応型ストリーミング クライアントの開発に焦点を当てている。文献では、SARSA [ 56 ]またはQ 学習[ 57 ]アルゴリズムを使用した複数のアプローチが提示されている。これらのアプローチすべてにおいて、クライアントの状態は、とりわけ、現在の認識されたネットワーク スループットとバッファ充填レベルに関する情報を使用してモデル化される。この情報に基づいて、自己学習クライアントは次のビデオ セグメントに選択する品質レベルを自律的に決定する。学習プロセスは、品質レベル、切り替え回数、ビデオ フリーズ回数などに基づいて、ユーザー体験品質 (QoE)を表すフィードバック情報を使用して制御される。さらに、マルチエージェントQ学習は、複数の適応型ストリーミングクライアント間のQoEの公平性を向上させるために適用できることが示された。[ 58 ]
HTTP ベースの適応型ビットレート技術は、従来のストリーミング技術よりも運用がかなり複雑です。文書化された考慮事項には、追加のストレージとエンコードのコスト、グローバルな品質の維持の課題などがあります。また、複雑な適応型ビットレートロジックと複雑な TCP フロー制御ロジックの競合に関する興味深いダイナミクスもいくつか見つかっています。[ 12 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ]
しかし、これらの批判は、実際にはHTTP配信の経済性と拡張性によって相殺されています。HTTPを使用しないストリーミングソリューションでは、専用のストリーミングサーバーインフラストラクチャを大規模に展開する必要があるのに対し、HTTPベースのアダプティブビットレートストリーミングでは、インターネット上で他のすべてのコンテンツを配信するために使用されるのと同じHTTPウェブサーバーを活用できます。
上記の方法で使用されるデジタル著作権管理には、明確に定義された単一のオープンスタンダードが存在しないため、制限付きコンテンツや時間制限付きコンテンツをあらゆるデバイスやプレーヤーに100%互換性のある方法で配信することはできません。これは、あらゆるストリーミングプロトコルでデジタル著作権管理が採用されている場合にも共通する問題です。