アダプティブ ビットレート ストリーミング (ABS) は、ビデオ ストリームのビットレートが利用可能な帯域幅に合わせて動的に調整される、メディアをストリーミングするための技術です。 これにより、バッファリングが排除され、ユーザーにより良い視聴体験が提供されます。 利用可能な帯域幅が高い場合はビデオ品質が高くなり、利用可能な帯域幅が低い場合はビデオ品質が低くなります。
ちょっと待って！ ここでは多くの重要な用語が飛び交っています。 これらすべてが頭から離れたとしても、心配する必要はありません。 このブログを読むと、アダプティブ ビットレート ストリーミングとは何かを明確に理解できるだけでなく、それが生まれた理由、仕組み、利点についても理解できるでしょう。 その間で生じるすべてのニュアンスについて説明します。
アダプティブ ビットレート ストリーミングについて詳しく説明する前に、そもそもなぜそれが作成されたのかを理解することが重要です。 アダプティブ ビットレート ストリーミングは、インターネットの誕生以来、インターネットを悩ませてきた問題、つまりビデオ バッファリングの解決策として生まれました。
YouTube でビデオを見たことがあるなら、おそらくそれを直接体験したことがあるでしょう。 バッファリングとは、再生を続ける前に、ビデオが一時停止して、さらにデータを読み込むことです。 これは通常、現在の「ビットレート」でビデオをストリーミングするのに十分な「帯域幅」がない場合に発生します。
さて、帯域幅とは何でしょうか? そしてビットレートとは何ですか? 簡単に言うと、帯域幅とは、一定期間内に XNUMX つのネットワーク ノード (デバイスとインターネット) 間で転送できるデータの量です (通常はビット/秒で測定されます)。 帯域幅は、インターネットからデバイスにビデオ データを運ぶパイプと考えることができます。 パイプの幅が広いほど、より多くのデータを伝送できるため、ビデオの再生がよりスムーズになります。 同様に、このフローのレートがビットレート (または「ビット レート」) です。
インターネットの初期には、アダプティブ ビットレート ストリーミングなどというものはありませんでした。 少なくとも私たちが知っている意味では、バッファリングさえありませんでした。 ビデオは再生する前に完全にダウンロードする必要がありました。
平均帯域幅の観点から見ると、 1994 年は 28.8 kbps でした。 かかったでしょう 少なくとも 92p (または 720 GB) の映画をダウンロードするには 1.2 時間かかります。 少なくともなぜですか？ なぜなら、ダウンロードが一時停止または途中で停止した場合 (または、インターネットでよく起こる重大なパケット損失が発生した場合)、最初からやり直す必要があるからです。 それなら驚くには値しないが NetflixはDVDレンタルサービスとしてスタートしました!
1995年には、 Macromedia が Netscape Navigator 用の Shockwave Player をリリースしました。 これは、Web ブラウザ上でビデオをストリーミングできる最初のメディア プレーヤーでした。 ブラウザベースのストリーミングにより、ユーザーはビデオを個別にダウンロードしなくても視聴を開始できます。 しかし、遅延はさまざまな理由で蔓延していました。 これにより、業界関係者は他のオプションを探すようになり、プログレッシブ ダウンロードこそが彼らが必要としていたものでした。 プログレッシブ ダウンロードがいつ最初に実装されたかは明らかではありませんが、その初期の実装の 1999 つに、XNUMX 年の Apple の QuickTime プレーヤーの Fast Start が含まれます。
プログレッシブダウンロードにより、よりスムーズな再生が可能になりました。 これは広く採用され、それを中心に独自のソリューションが登場し始めました。 ただし、いくつかの問題がまだ残っていました。
プログレッシブ ダウンロードにより、到着したビデオ フレームをレンダリングできるようになりました。 その結果、ビデオ全体をダウンロードすることなく再生を開始できるようになり、待ち時間が長くなる問題が解決されました。 遅いネットワークでは、ユーザーは再生を開始し、一時停止し、完全にロードして高品質の視聴体験を楽しむことができます。 一時停止せずにビデオを再生するのに十分なデータがある限り、帯域幅の低下が品質に影響を与えることはありません。
しかし、プログレッシブ ダウンロードには一連の課題がありました。 大きな課題は、大量の帯域幅を消費することでした。 ビデオの大部分が視聴されていない場合でも、ビデオ全体がダウンロードされます。 さらに、プログレッシブ ダウンロードでは、帯域幅、パケット損失、さらにはデバイスの仕様の突然の変化に対してはほとんど対処できませんでした。 これらの要因により、バッファリング、途切れ、一時停止などの再生の問題が発生する可能性があります。 最後に、ビデオが特定のビットレートでストリーミングされている場合、別のビットレートに切り替えて、中断したところからビデオが始まることを期待することはできません。
これらすべてのアヒルを並べて一石で攻撃するにはどうすればよいでしょうか? 業界の答えは、アダプティブ ビットレート ストリーミングでした。
アダプティブ ビットレート ストリーミングはゲームチェンジャーでした。 これは、私たちが今日住んでいるビデオのスムーズなストリーミングの世界への道を切り開きました。 アダプティブ ビットレート ストリーミングの仕組みを理解するには、マニフェスト ファイルとエンコーダという XNUMX つの重要な概念について理解することが重要です。
マニフェスト ファイルは、アダプティブ ビットレート ストリームの一部であるすべてのビデオ ストリーム (またはバリアント) に関する情報を含むテキスト ファイルです。 これには、解像度、コーデック、言語、フレーム レートなどの他のメタデータと、各セグメントをいつ再生するかを示すタイムスタンプも含まれます。 つまり、マニフェスト ファイルはビデオ ストリームのプレイリストのように機能します。 以下にその例を示します。
ご覧のとおり、各バリアントは特定のビットレートのメディア ファイルによって表されます。 EXT-X-STREAM-INF タグには、使用される帯域幅やコーデックなど、そのストリームに関する情報が含まれます。 ファイルの先頭に「#EXTM3U」タグがあることにも注目してください。 これは M3U8 プレイリストとして知られており、マニフェスト ファイルの一般的な形式です。 M3U8 ファイルでは、国際文字をサポートする UTF-8 文字エンコーディングが使用されることに注意してください。
マニフェスト ファイルがプレイリストである場合、エンコーダーは音楽 (この場合はビデオ ストリーム) を作成する機器です。 エンコーダーはソースビデオを取得し、それをさまざまなビットレートと解像度 (通常は 144p ～ 1080p の範囲) で XNUMX つ以上の出力ストリームにエンコードします。 これらのエンコードされたビデオ ファイルは、それぞれ XNUMX ～ XNUMX 秒の小さなチャンクに分割され、Web サーバーに保存され、クライアントが必要に応じてそこから取得できます。
各バリアントのビットレートは異なりますが、すべて同じコーデックを使用することに注意することが重要です。 これは、異なるコーデックには相互互換性がないためです。 ワインオープナーを使用してソーダのボトルを開けることができないのと同じように、あるバリアント セグメントに H.264 コーデックを使用し、別のサブセグメントに VP9 (もう XNUMX つの一般的なコーデック) を使用することはできません。
マニフェスト ファイルとエンコーダが何であるかがわかったので、アダプティブ ビットレート ストリーミングがどのように機能するかを見てみましょう。 わかりやすくするために例を使用します。 平均帯域幅 10Mbps の LTE 経由で携帯電話でビデオを見ているとします。 H.1080 コーデックを使用して 5Mbps でエンコードされた 264p ビデオの再生を開始します。 次に、プレーヤーはサーバーから対応するマニフェスト ファイルをフェッチします。これは次のようになります。
.webp)
ご覧のとおり、ビデオには 264 つのバリエーションがあり、それぞれ異なるビットレートでエンコードされていますが、同じコーデック (H.5) を使用しています。 次に、プレーヤーは、現在の帯域幅条件 (この場合は XNUMXMbps) に最もよく一致するバリアントから最初のセグメントをダウンロードして再生します。 ネットワーク状態の変化を検出するか、ユーザーが別の解像度に切り替えるまで、後続のすべてのセグメントに対してこの処理が継続されます。
たとえば、携帯電話が LTE カバレッジの低いエリア (平均帯域幅 3Mbps の 2G など) に移動すると、プレーヤーはバッファリングの問題を防ぐために、より低いビットレートのバリアントの 720 つからセグメントを取得するように自動的に切り替えます。 同様に、プレーヤー インターフェイス内から手動で 480p または XNUMXp 解像度に切り替えると、代わりにそれらのバリアントからセグメントのフェッチが開始されます。 LTE カバレッジが良好なエリアに戻ると、より高いビットレートのバリアントからのセグメントの取得に自動的に戻ります。
.webp)
アダプティブ ビットレート ストリーミングに使用される一般的なプロトコルは XNUMX つあります。 HTTPライブストリーミング（HLS） & HTTP 経由の動的アダプティブ ストリーミング (DASH)。 HLS はより広く採用されていますが、DASH はオープンソースの国際標準であるため人気が高まっています。 それぞれを詳しく見てみましょう。
HLS は、2009 年に Apple によって Mac OS X Snow Leopard 用の QuickTime X アプリケーションの一部として開発されました。それ以来、Google、HP、Microsoft などの多くの企業で採用されています。 このプロトコルは、次のようなストリーミング サーバーの代わりに通常の Web サーバーを使用します。 ワウザ, テユトまたは アドビメディアサーバーなどの他のストリーミング プロトコルには不可欠です。 RTMP またはRTSP。 このようなサーバーを追加すると、パフォーマンスが大幅に向上する可能性があることに注意してください。 ただし、それらをスキップしたい場合は、HLS ストリームを設定すれば、標準的な Web サーバーと CDN で十分です。
HLS を使用する最大の利点は、iOS、Android、Windows Phone、tvOS、macOS、Microsoft Silverlight など、すべての主要なプラットフォームで動作することです。 Apple はまた、Apple デバイスで他の主要なストリーミング プロトコルをサポートしないことで HLS の覇権を維持しています。 ただし、HLS は、ほとんどのメディア プレーヤーで十分にサポートされている、一般的な MPEG-2 Transport Stream (M2TS) コンテナー形式を使用します。
%20(2).webp)
DASH は、Motion Picture Experts Group (MPEG) によって開発され、ISO/IEC 23009 に基づいて標準化されたアダプティブ ビットレート ストリーミング プロトコルです。DASH は、HLS (M2TS) と同じコンテナ形式を使用しますが、ファイル構造が異なります。 このため、一部のメディア プレーヤーが両方のプロトコルをサポートすることが困難になります。 ただし、DASH 互換プレーヤーを使用するか、関連するプラグインをインストールするなど、これには回避策があります。
DASH は、MPD (メディア プレゼンテーション記述) として知られる共通のマニフェスト ファイル形式を使用して、複数のデバイスおよびネットワーク上で動作するように設計されました。 これにより、クライアントはネットワークの状態とデバイスの機能に基づいてビデオのビットレートを動的に適応させることができます。 また、MPEG Common Encryption (CENC) などの暗号化方式を使用したオンライン コンテンツ保護もサポートしています。
また、ご購読はいつでも停止することが可能です Teyutoの専門家に連絡する 独自のユースケースに基づいて必要な機能をより深く理解できるようになります。 これは、デジタル ビデオ ミックスに DASH 互換性が必要かどうかを情報に基づいて決定するのに役立ちます。
各プレーヤーが次にストリーミングするビットレートを決定する独自の基準を持っているため、現在ではいくつかの ABS アルゴリズムが使用されています。 ただし、それらはほとんどすべて、ビットレートとバッファ占有という XNUMX つの主要な機能を備えています。 ABS アルゴリズムの例には次のものがあります。
BOLA の主なアイデアは、現在のバッファ占有状況を使用して将来の再生のスムーズさを予測することです。 次に、平滑性項とペナルティ項の加重和であるコスト関数を最小化するようにビットレートが選択されます。 ここで、他のアルゴリズムとは異なり、BOLA は通常、ネットワーク帯域幅を予測しないことに注意する必要があります。 むしろ、現在のバッファ占有をプロキシとして使用して、次にどのビットレートをストリーミングするかを決定します。
GDSF は、現在のバッファ占有量とネットワーク帯域幅の最近の履歴の両方を使用して、次にストリーミングするビットレートを決定するレート適応アルゴリズムです。 主なアイデアは、最近の平均ネットワーク帯域幅を最大化しながら、バッファ占有を特定の目標レベルに維持することです。
ABS に関する文献では、機械学習ベースのアルゴリズムがいくつか提案されています。 これらのアルゴリズムはデータ (ネットワーク帯域幅、バッファ占有など) からモデルを学習し、このモデルを使用して将来の再生のスムーズさを予測します。 この予測に基づいて、高品質のエクスペリエンス (QoE) でスムーズな再生を保証するビットレートが自動的に選択されます。
アダプティブ ビットレート ストリーミングには、ユーザーとコンテンツ プロバイダーの両方にとって、いくつかの利点があります。
アダプティブ ビットレート ストリーミングの最大の利点の XNUMX つは、バッファリングがほぼ不要になることです。 これにより、インターネット速度が大幅に異なる可能性があるため、特にモバイル デバイスでのユーザーの視聴エクスペリエンスがよりスムーズになります。
もう XNUMX つの利点は、ユーザーがインターネット接続で処理できる最高品質のビデオを常に視聴できることです。 そのため、接続が遅い場合でも、全体を通して低品質のビデオで妥協する必要はありません。 ABS は、余裕があるときはいつでもビットレートを自動的に調整します。
アダプティブ ビットレート ストリーミングは、利用可能な帯域幅に基づいて必要な量のデータのみをストリーミングするため、データ使用量の大幅な節約につながる可能性があります。
ABS は全体的に優れた視聴エクスペリエンスを提供するため、視聴者のエンゲージメントと維持率の向上につながる可能性があります。 これは特にライブ ストリーミングに当てはまります。ライブ ストリーミングでは、ABS が再生の遅延を防ぐ大きな差別化要因となる可能性があります。
アダプティブ ビットレート ストリーミングは必要な量のデータのみをストリーミングするため、コンテンツ プロバイダーのインフラストラクチャ コストの削減につながります。 エッジ サーバーへの支出を削減でき、トラフィックのピーク期間に容易に対応できるようになります。
アダプティブ ビットレート ストリーミングを使用すると、コンテンツ プロバイダーはビデオ ストリームの品質をより詳細に制御できるようになります。 これにより、品質とファイル サイズのバランスをとることができ、ストレージと帯域幅のコストの大幅な節約にもつながります。
ABS を使用すると、コンテンツ プロバイダーは低帯域幅接続でもビデオにアクセスできるようになり、より幅広い視聴者にリーチできるようになります。 ビデオ プレーヤーは、一般的なネットワーク状況に基づいて適切なストリームを選択できます。
それで、これで完成です！ アダプティブ ビットレート ストリーミングは、バッファリングや中断を心配することなく、ビデオ ストリーミングの品質を向上させる優れた方法です。 これを使用すると、常にゲームの優位性を確保できます。
アダプティブ ビットレート ストリーミングと、ユースケースに基づいた最適な実装について詳しくは、 Teyutoの専門家に今すぐ連絡してください.
読んでよかったですか？