アダプティブビットレートストリーミング

アダプティブ ビットレート ストリーミングは、コンピュータ ネットワーク経由でマルチメディアをストリーミングする際に使用される技術です。

過去には、ほとんどのビデオやオーディオのストリーミング技術はRTPやRTSPなどのストリーミングプロトコルを利用していましたが、今日の適応型ストリーミング技術はほぼ完全にHTTP ^[1]に基づいており、大規模な分散HTTPネットワーク上で効率的に動作するように設計されています。

アダプティブビットレートストリーミングは、ユーザーの帯域幅とCPU容量をリアルタイムで検出し、それに応じてメディアストリームの品質を調整することで機能します。^[2]単一のソースメディア（ビデオまたはオーディオ）を複数のビットレートでエンコードするエンコーダを使用する必要があります。プレーヤークライアント^[3]は、利用可能なリソースに応じて、異なるエンコードのストリーミングを切り替えます。^{[4]これにより、}バッファリングがほとんどなくなり、起動時間が短縮され、ハイエンドとローエンドの両方の接続で優れたエクスペリエンスが実現します。^[5]

より具体的には、アダプティブ ビットレート ストリーミングは、ソース コンテンツが複数のビット レートでエンコードされる、HTTP 経由のビデオ ストリーミングの方法です。異なるビット レートのストリームはそれぞれ、数秒の小さな部分に分割されます。^[6]セグメント サイズは特定の実装によって異なりますが、通常は 2 秒から 10 秒です。^{[4] [6]}まず、クライアントは、利用可能なストリーム セグメントとそれぞれのビット レートを記述したマニフェスト ファイルをダウンロードします。ストリームの起動時に、クライアントは通常、最も低いビット レートのストリームからセグメントを要求します。クライアントは、ネットワーク スループットがダウンロードしたセグメントのビット レートよりも大きいことを検出した場合、より高いビット レートのセグメントを要求します。その後、クライアントは、ネットワーク スループットが低下したことを検出した場合、より低いビット レートのセグメントを要求します。クライアントのアダプティブ ビットレート (ABR) アルゴリズムは、ネットワークの現在の状態に基づいて、どのビット レートのセグメントをダウンロードするかを決定するという重要な機能を実行します。いくつかのタイプのABRアルゴリズムが商用利用されています。スループットベースのアルゴリズムは、意思決定に最近のダウンロードで達成されたスループットを使用します（例：dash.jsのスループットルール）、バッファベースのアルゴリズムはクライアントの現在のバッファレベルのみを使用します（例：dash.jsのBOLA ^[7]）、ハイブリッドアルゴリズムは両方のタイプの情報を組み合わせます（例：dash.jsのDYNAMIC ^[8]）。

ポストプロダクション会社、コンテンツ配信ネットワーク、スタジオは、より少ない人員とリソースで消費者に高品質のビデオを提供するために、アダプティブビットレート技術を使用しています。特にアダプティブビットレートストリーミング用の複数のビデオ出力を作成することは、消費者に大きな付加価値をもたらします。^[9]この技術が適切に機能していれば、エンドユーザーまたは消費者のコンテンツは中断することなく再生され、気付かれない可能性もあります。メディア企業は長年にわたりアダプティブビットレート技術を積極的に使用しており、基本的にハイエンドのストリーミングプロバイダーの標準的な方法となっています。高解像度フィード（低解像度から始まり、徐々に解像度を上げていきます）をストリーミングするときにバッファリングがほとんど発生しません。

従来のサーバー駆動型アダプティブビットレートストリーミングでは、メディアサーバーが各ユーザーのネットワークや再生条件の変化に自動的に適応するため、ストリーミングメディアの消費者に最高の体験を提供します。^[10]メディアおよびエンターテイメント業界もアダプティブビットレートストリーミングの恩恵を受けています。ビデオスペースが拡大するにつれて、コンテンツ配信ネットワークとビデオプロバイダーは顧客に優れた視聴体験を提供できます。アダプティブビットレートテクノロジーでは追加のエンコードが必要になりますが、全体的なワークフローが簡素化され、より良い結果が得られます。

HTTP ベースのアダプティブ ビットレート ストリーミング技術は、従来のサーバー駆動型アダプティブ ビットレート ストリーミングに比べて、さらなる利点があります。まず、ストリーミング技術はHTTP上に構築されているため、RTPベースのアダプティブ ストリーミングとは異なり、パケットはファイアウォールやNATデバイスを問題なく通過できます。次に、HTTP ストリーミングは完全にクライアント駆動型であるため、すべてのアダプティブ ロジックはクライアント側にあります。これにより、サーバーとクライアント アプリケーション間の永続的な接続の必要性が軽減されます。さらに、サーバーは各クライアントのセッション状態情報を維持する必要がないため、スケーラビリティが向上します。最後に、HTTP キャッシュやサーバーなどの既存の HTTP 配信インフラストラクチャをシームレスに採用できます。^{[11] [12] [13] [14]}

スケーラブルなCDN は、インターネットの視聴者にメディア ストリーミングを配信するために使用されます。CDN は、オリジン サーバーでソースからストリームを受信し、それを多数またはすべてのエッジ キャッシュ サーバーに複製します。エンド ユーザーがストリームを要求すると、「最も近い」エッジ サーバーにリダイレクトされます。これは、libdash ^[15]と、ヨーロッパ、アジア、米国に複数のミラーがある Distributed DASH (D-DASH) データセット^[16]を使用してテストできます。HTTP ベースのアダプティブ ストリーミングを使用すると、エッジ サーバーでライセンス コストが安価または無料のシンプルな HTTP サーバー ソフトウェアを実行できるため、高価なメディア サーバー ライセンス (Adobe Flash Media Streaming Server など) と比較してソフトウェア ライセンス コストが削減されます。HTTP ストリーミング メディアの CDN コストは、HTTP Web キャッシュ CDN コストとほぼ同じになります。

HTTP経由のアダプティブ ビット レートは、2002 年 10 月に DVD フォーラムの WG1 スペシャル ストリーミング グループで作成されました。このグループの共同議長は東芝とPhoenix Technologiesが務め、専門家グループにはMicrosoft、Apple Computer、DTS Inc.、Warner Brothers、20th Century Fox、 Digital Deluxe 、Disney、MacromediaおよびAkamaiが参加しています。^{[疑わしい–議論] [要出典]} このテクノロジは元々 DVDoverIP と呼ばれ、DVD ENAV ブックの不可欠な要素でした。^[17]この概念は、MPEG-1 および MPEG-2 DVD TS セクターを 2KB の小さなファイルに格納し、HTTP サーバーを使用してプレーヤーに提供することから生まれました。MPEG-1 セグメントは低帯域幅のストリームを提供し、MPEG-2 は高ビット レートのストリームを提供しました。元の XML スキーマは、ビット レート、言語、および URL サーバーの単純なプレイリストを提供しました。最初の実用的なプロトタイプは、ドイツのフィリンゲンにあるハーマンカードン研究所でフェニックス テクノロジーズによって DVD フォーラムに発表されました。 ^{[引用が必要]}

アダプティブビットレートストリーミングは2006年にMove Networksによって導入され^[18]、現在はAdobe Systems、Apple、Microsoft、Octoshapeによって開発・利用されています。^[19] 2010年10月、Move Networksはアダプティブビットレートストリーミングの特許を取得しました（米国特許番号7818444）。^[20]

Dynamic Adaptive Streaming over HTTP (DASH) は MPEG-DASH とも呼ばれ、国際標準となっている唯一の適応型ビットレート HTTP ベースのストリーミングソリューションです^{[21] MPEG-DASH 技術は}MPEG の下で開発されました。DASH の作業は 2010 年に開始され、2011 年 1 月に国際標準草案、2011 年 11 月に国際標準となりました。^{[21] [22] [23]} 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に関連する技術です。^{[24] DASHは、} 3GPP Release 9のAdaptive HTTP streaming (AHS)とOpen IPTV Forum Release 2のHTTP Adaptive Streaming (HAS)に基づいています。 ^[25] MPEGとの協力の一環として、3GPP Release 10では、ワイヤレスネットワークでの使用にDASH（特定のコーデックと動作モードを使用）を採用しています。^[25]

アダプティブ ストリーミング ソリューションを標準化する目的は、Apple の HLS、Microsoft の Smooth Streaming、Adobe の HDS など、特定のベンダーに特化した他のソリューションとは異なり、ソリューションが普遍的に機能することを市場に保証することです。

利用可能な実装としては、HTML5ベースのbitdash MPEG-DASHプレーヤー^[26]、bitmovin GmbHのオープンソースC++ベースのDASHクライアントアクセスライブラリlibdash ^[15] 、アルペンアドリア大学クラーゲンフルト校の情報技術研究所（ITEC）のDASHツール^{[3] [27]、} Telecom ParisTechのGPACグループのマルチメディアフレームワーク^{[28] 、および}DASH-IFのdash.js ^[29]プレーヤーがあります。

HTTP ライブ ストリーミング (HLS) は、 Apple Inc.がQuickTime XおよびiOSの一部として実装した HTTP ベースのメディア ストリーミング通信プロトコルです。HLS は、ライブ コンテンツとビデオ オンデマンドコンテンツの両方をサポートします。メディア ストリームまたはファイルを短い断片 (メディア セグメント) に分割し、MPEG-TSまたは断片化された MP4ファイルとして保存します。これは通常、ストリームまたはファイル セグメンター アプリケーション (パッケージャーとも呼ばれます) を使用して複数のビットレートで実行されます。このようなセグメンターの実装の 1 つが Apple によって提供されています。^{[30] Google の Shaka Packager [31]}などの無料 / オープン ソース製品や、Unified Streaming ^[32]などのさまざまな商用ツールなど、追加のパッケージャーが利用可能です。セグメンターは、メディア チャンクを記述する M3U8 形式のプレイリスト ファイル セットも作成します。各プレイリストは特定のビットレートに固有であり、そのビットレートのチャンクへの相対 URL または絶対 URL が含まれています。クライアントは、使用可能な帯域幅に応じて適切なプレイリストを要求する必要があります。

HTTPライブストリーミングはiPhone 3.0以降のバージョンの標準機能です。^[33]

Appleは、その解決策をIETFに情報要求書として提出し、検討を求めている。^{[34]これは}RFC 8216として正式に承認された。サーバー実装（セグメンター）とクライアントプレーヤーの両方に対して、 多数の独自仕様およびオープンソースの解決策が存在する。

HLSストリームは、プレイリストURL形式拡張子m3u8またはMIMEタイプapplication/vnd.apple.mpegurlで識別できます。^[35]これらの適応型ストリームは、さまざまなビットレートで利用可能であり、クライアントデバイスはサーバーと対話して、確実に配信できる最適なビットレートを取得します。

HLS の再生は、Safari や macOS / iOS のネイティブ アプリ、Windows 10 の Microsoft Edge、Android の ExoPlayer、Roku プラットフォームなど、多くのプラットフォームでサポートされています。多くのスマート TV も HLS をネイティブでサポートしています。Chrome / Firefox などの他のプラットフォームで HLS を再生するには、通常、ブラウザー / JavaScript プレーヤーの実装が必要です。hls.js、video.js http-streaming、BitMovin、JWPlayer、THEOplayer など、多くのオープン ソースおよび商用プレーヤーが利用可能です。

「HTTP ダイナミック ストリーミングは、再生中にさまざまな品質とサイズの異なるストリームを動的に切り替えることで、ストリーミング ビデオを効率的にユーザーに配信するプロセスです。これにより、帯域幅とローカル コンピューターのハードウェア ( CPU ) がサポートできる最高の視聴体験がユーザーに提供されます。ダイナミック ストリーミングのもう 1 つの主な目的は、このプロセスをユーザーにとってスムーズかつシームレスにすることです。これにより、ストリームの品質のアップスケールまたはダウンスケールが必要な場合でも、連続再生を中断することなく、スムーズでほとんど気付かない切り替えが可能になります。」^[36]

最新バージョンのFlash PlayerとFlash Media Serverは、AppleとMicrosoftのHTTPベースのソリューションと同様に、従来のRTMPプロトコルとHTTPを介したアダプティブビットレートストリーミングをサポートしており、 ^[37] HTTPダイナミックストリーミングはFlash Player 10.1以降でサポートされています。^[38] HTTPベースのストリーミングには、Webブラウザが使用する通常のポート以外にファイアウォールポートを開く必要がないという利点があります。 HTTPベースのストリーミングでは、ビデオフラグメントをブラウザ、プロキシ、CDNでキャッシュできるため、ソースサーバーの負荷が大幅に軽減されます。

Smooth Streaming は、HTTP 経由でクライアントにメディアをアダプティブ ストリーミングできるようにするIIS Media Services 拡張機能です。 ^[39]形式仕様はISO ベースのメディア ファイル形式に基づいており、Microsoft によって Protected Interoperable File Format として標準化されています。^[40] Microsoft は、アダプティブ ビット レート HTTP ストリーミングを標準化するための3GPP、MPEG、およびDECE組織の取り組みに積極的に関与しています。Microsoft は、 SilverlightおよびWindows Phone 7用の Smooth Streaming Client ソフトウェア開発キットと、Apple iOS、Android、Linux などの他のクライアント オペレーティング システムで使用できる Smooth Streaming Porting Kit を提供しています。^[41] 2010 年 11 月にリリースされた IIS Media Services 4.0 では、ライブ Smooth Streaming H.264/AAC ビデオを Apple HTTP Adaptive Streaming 形式に動的に再パッケージ化し、再エンコードせずに iOS デバイスに配信できる機能が導入されました。Microsoft は、Silverlight クライアントへの Smooth Streaming によるライブおよびオンデマンドの 1080p HD ビデオの配信に成功しました。 2010年には、マイクロソフトはNVIDIAと提携し、NVIDIA 3D Visionテクノロジーを搭載したPCに1080pの立体3Dビデオをライブストリーミングするデモも行いました。^[42]

CMAFはHLSとMPEG-DASHの両方の配信に使用されるプレゼンテーションコンテナフォーマットです。したがって、HTTPベースのストリーミングメディアの配信を簡素化することを目的としています。2016年にAppleとMicrosoftによって提案され、2018年に正式に公開されました。^[43]

QuavStreams Adaptive Streamingは、Quavliveが開発したマルチメディアストリーミング技術です。ストリーミングサーバーは、異なるビットレートと解像度でエンコードされた各ビデオの複数のバージョンを持つHTTPサーバーです。サーバーは、現在利用可能な帯域幅に応じて、エンコードされたビデオ/オーディオフレームをあるレベルから別のレベルに切り替えて配信します。制御は完全にサーバーベースであるため、クライアントは特別な追加機能を必要としません。ストリーミング制御はフィードバック制御理論を採用しています。^{[44]現在、QuavStreamsは、FLVコンテナに多重化されたH.264 / MP3コーデックとWEBMコンテナに}多重化されたVP8 / Vorbisコーデックをサポートしています。

Uplynkは、単一の非独占的アダプティブストリーミングフォーマットを使用してクラウドでビデオをエンコードすることにより、iOS、Android、Windows Mac、Linux、Rokuなどの複数のプラットフォームに、さまざまなブラウザの組み合わせでHDアダプティブビットレートストリーミングを提供します。さまざまなプラットフォームやデバイス用に複数のフォーマットをストリーミングして保存するのではなく、Uplynkは1つのフォーマットのみを保存してストリーミングします。この技術を配信に使用した最初のスタジオはディズニー-ABCテレビグループで、ABCプレーヤー、ABCファミリー、ウォッチディズニーアプリのウェブ、モバイル、タブレットストリーミングアプリ、およびライブウォッチディズニーチャンネル、ウォッチディズニージュニア、ウォッチディズニーXDのビデオエンコードに使用しました。^{[45] [46]}

近年、アダプティブ ビットレート ストリーミングにおける自己学習アルゴリズムの利点が学術界で調査されてきました。初期の自己学習アプローチのほとんどはサーバー側で実装されていますが^{[47] [48] [49] (}強化学習や人工ニューラル ネットワークを使用してアドミッション コントロールを実行するなど)、最近の研究では自己学習 HTTP アダプティブ ストリーミング クライアントの開発に焦点が当てられています。文献では、SARSA ^[50]またはQ 学習^[51]アルゴリズムを使用した複数のアプローチが紹介されています。これらのアプローチのすべてにおいて、クライアントの状態は、特に、現在のネットワーク スループットとバッファー充填レベルに関する情報を使用してモデル化されます。この情報に基づいて、自己学習クライアントは、次のビデオ セグメントに選択する品質レベルを自律的に決定します。学習プロセスは、体感品質 (QoE)を表すフィードバック情報を使用して制御されます(品質レベル、切り替え回数、ビデオ フリーズ回数などに基づく)。さらに、マルチエージェントQ学習を適用することで、複数の適応型ストリーミングクライアント間のQoE公平性を改善できることが示されました。 ^[52]

HTTPベースの適応ビットレート技術は、従来のストリーミング技術に比べて運用がはるかに複雑です。文書化された考慮事項には、追加のストレージとエンコードのコスト、およびグローバルに品質を維持することの課題などがあります。また、複雑な適応ビットレートロジックと複雑なTCPフロー制御ロジックの競合の相互作用に関して、興味深いダイナミクスがいくつか発見されています。^{[11] [53] [54] [55] [56]}

しかし、これらの批判は、実際には HTTP 配信の経済性とスケーラビリティによって上回られています。非 HTTP ストリーミング ソリューションでは、専用のストリーミング サーバー インフラストラクチャを大規模に導入する必要がありますが、HTTP ベースのアダプティブ ビット レート ストリーミングでは、インターネット経由で他のすべてのコンテンツを配信するために使用されるのと同じ HTTP Web サーバーを活用できます。^{[引用が必要]}

上記の方法で使用されるデジタル著作権管理には明確に定義されたオープン スタンダードがないため、制限付きコンテンツや時間制限のあるコンテンツをあらゆるデバイスやプレーヤーに配信するための 100% 互換性のある方法はありません。これは、あらゆるストリーミング プロトコルで採用されているデジタル著作権管理にも問題があります。

一部の実装で使用される、ファイルを小さなファイルに分割する方法 ( HTTP Live Streamingで使用されるものなど) は、マニフェスト ファイルでトラック番号とビット レートのみを示し、異なるビット レートの複数のビデオ トラックを持つ可能性がある単一のビデオ アセット ファイルから HTTP クライアントがバイト範囲を要求できるため、不要であると考えられます。ただし、このアプローチでは、任意の単純な HTTP サーバーでチャンクを提供できるため、CDN との互換性が保証されます。Microsoft Smooth Streamingなどのバイト範囲を使用する実装では、ビデオ アセット チャンクの要求に応答するために、 IISなどの専用の HTTP サーバーが必要です。

• 複数の記述コーディング
• 階層的変調– ストレージとオーサリングの要件を削減する代替手段

• ビデオの次の大物：アダプティブ ビットレート ストリーミング 2010 年 6 月 19 日、Wayback Machineにアーカイブ