%20(1).webp)
2009 年に Apple は HTTPライブストリーミング（HLS） インターネット上でライブおよびオンデマンドのオーディオおよびビデオ コンテンツをストリーミングする方法として。 それは今です 最も広く使用されているビデオストリーミングプロトコル すべての主要なブラウザとデバイスをサポートしており、世界中で利用できます。
このブログでは、LL-HLS が作成された理由、LL-HLS とは何なのか、LL HLS と HLS との違い、その顕著な特徴、LL-DASH に対する対抗策、および留意すべきいくつかの点について詳しく説明します。それを実行しながら。
上で説明したように、HLS は、HTTP を使用してインターネット上でビデオおよびオーディオ コンテンツを配信するストリーミング メディア配信プロトコルです。 これは、OTT サービス プロバイダーやその他の主要なブラウザーやデバイスで使用される非常に人気のあるプロトコルです。
一方、ll hls は、低遅延ストリーミング用に最適化された HLS のバリアントです。 これにより、ユーザーが再生を開始してからコンテンツを見たり聞いたりするまでの時間 (「遅延」と呼ばれる) が短縮されます。 これは、数秒の遅延でも視聴者の体験を損なう可能性があるライブ ストリームでは特に重要です。
hls と hls low latency の主な技術的な違いは、どちらもストリーミングの処理に使用するプロトコルです。 HTTP ライブ ストリーミングでは、セグメント全体がダウンロードされるのを待ってからストリーミングする独自のバッファリング メカニズムが使用されます。 視聴者はビデオ コンテンツを楽しむ前にセグメント全体がダウンロードされるまで待たなければならないため、これは遅延に影響を与える可能性があります。
hls の低遅延ストリーミングではサーバー プッシュが使用され、遅延の削減に貢献します。 これは、サーバーがビデオのセグメントを受信側にプッシュすることを意味します。 ビデオの最初のセグメントがダウンロードされるとすぐに、ビデオの再生が開始されます。 視聴者は他のセグメントがダウンロードされている間にビデオを視聴できるため、最終的に遅延が軽減されます。
低遅延 hls はチャンク転送エンコーディングを使用するため、遅延が短縮されます。 したがって、HLS の低遅延は通常 2 ～ 5 秒程度ですが、HLS の場合は 6 ～ 30 秒です。 これにより、HLS 低遅延ストリーミングは、遅延が重要なライブ ストリーミング アプリケーションにとってより良い選択肢となります。
さて、本題に入りましょう。
LL-HLS の前身である HLS は、高品質のコンテンツをデバイスやプラットフォーム間で大規模にストリーミングするために開始されました。 ただし、そのスケール指向のストリーミング アーキテクチャには、遅延という代償が伴いました。 初心者のために説明すると、遅延とは、（カメラで）ビデオが作成されてから（ユーザーのデバイスで）最終的に再生されるまでにかかる時間であり、「ガラスからガラスへの遅延」とも呼ばれます。 その間に、このビデオ ストリームは、再生前にエンコード (オーディオとビデオの両方)、セグメント化、パッケージ化、リスト化、ダウンロード、配信、デコード、リップシンク、およびバッファリングする必要があります。 ストリーミング プロトコル (HLS など) は、この面倒な作業をすべて処理します。
HLS は品質と互換性の点で優れた成果を上げましたが、長年にわたり、その開発は常に遅延に関して妥協していました。 そして、それは理にかなっていました。 当時は遅延は問題ではありませんでした。 しかし、もうそうではありません。 ソーシャル メディアとライブ ストリーミングの出現により、人々はリアルタイムのコンテンツを求めるようになりました。 彼らはこれ以上長く待ちたくないのです。 ここで、30 ～ 50 秒の遅延は耐えられません。
Apple (HLS を保守している) が最終的に低遅延ストリーミング用に最適化されたソリューションを考案することは当然のことです。 それで、彼らはそうしました！ 2019年のWWDCでは、 Apple が低遅延 HLS または LL-HLS を発表。 これは、既存の HLS 仕様に基づいて構築されており、低遅延 (5 秒未満) を実現するためにいくつかの変更が加えられています。 LL-HLS が品質や互換性を損なうことなくこれをどのように行うかを見てみましょう。
LL-HLS は、既存の HLS 仕様にいくつかの大きな変更を加えます。 これらの変更には次のものが含まれます。
LL-HLS では、セグメントがさらに部分 (HLS 部分セグメント) に分割され、個々のファイル サイズが小さくなります。 これにより、セグメント全体がダウンロードされる前でも再生を開始できるようになります (セグメントが完全になるまで待機する必要がある HLS とは対照的です)。
プレイリストは LL-HLS で更新され、HLS と比較して転送コストが低くなります。 これは、クライアントですでに利用可能なプレイリストの関連部分を更新するデルタ更新を提供するようにサーバーに要求することによって行われます。
プレーヤーの HTTP GET リクエストには、LL-HLS の「配信ディレクティブ」を含めることができます。 これらは、プレイリスト応答内の将来のセグメントを要求する特別なクエリ パラメーターです。 その後、サーバーは、指定されたセグメントが使用可能になるまで、このリクエストをブロックします。 プレイリストのポーリングが不要になり、その結果、サーバーとネットワーク帯域幅が解放されます。
待ち時間をさらに短縮するために、LL-HLS にはプリロード ヒントが導入されています。 これらはプレイリスト内の特別なタグで、再生に必要になる前でもセグメントのフェッチを開始するようにプレーヤーに指示します。 そのため、必要なときに遅延なくセグメントをすぐに再生できます。
LL-HLS は、ビットレート適応時のラウンドトリップ数を最小限に抑えます。 これは、マルチバリアント プレイリスト内のすべてのメディア プレイリストに EXT-X-RENDITION-REPORT タグを追加することによって行われます。 これらのタグは、現在のメディア プレイリスト内の最後のメディア シーケンス番号やパートなどの情報を提供します。 このようにして、クライアントはまったく新しいメディア プレイリストをフェッチしなくても、サーバーに必要な部分をリクエストできます。
それらの間には、ユースケースにどちらが適しているかを決定する前に知っておくべき重要な違いがいくつかあります。
LL-HLS と HLS の相違点と類似点をいくつか示します。
これまで見てきたように、LL-HLS と HLS の最大の違いは遅延です。 LL-HLS を使用することで、Apple は通常の HLS (遅延が約 5 秒である) と比較して、大幅に (30 秒未満に) 短縮することに成功しました。この遅延は、HD ケーブル TV ストリーミングの遅延よりもさらに低いです。その結果、LL-HLS はユーザーにほぼリアルタイムの視聴エクスペリエンスを提供するため、特定のユースケースで遅延が重要な場合には、LL-HLS を優先する必要があります。
LL-HLS ストリームと HLS ストリームの間に品質に目立った違いはありません。 どちらも高品質のビデオ ストリーミングを大規模に提供します。 ただし、LL-HLS は、ネットワーク帯域幅が狭い状況には最適ではありません。
HLS と LL-HLS の両方の最も優れた点の XNUMX つは、すべての主要なブラウザーおよびデバイスとの互換性です。 いくつかの LL-HLS をサポートする一般的なブラウザには次のものがあります。 AVPlayer (iOS)、Exoplayer (Android)、THEOPlayer、JWPlayer、HLS.js、VideoJS、および AgnoPlay。 したがって、他のプロトコルとは異なり、視聴者がストリームを視聴できるかどうかを心配する必要はありません。
通常の HLS の導入は、LL-HLS よりも安価です。
LL-HLS の実装は、追加機能 (プリロード ヒントやレンディション レポートなど) があるため、HLS よりも複雑です。 したがって、実装する前に、その仕組みをよく理解する必要があります。
ここで、低遅延ストリーミングに LL-HLS を使用する利点と欠点をいくつか見てみましょう。
低遅延ストリーミングに LL-HLS を使用する利点は次のとおりです。
名前から明らかなように、LL-HLS は遅延を考慮して設計されました。 ストリーミング プロトコルは、ほぼリアルタイムのガラスからガラスへの視聴エクスペリエンスを提供します。 特定のシナリオでは、LL-HLS を使用すると、2 秒未満の遅延も達成できます。 これにより、スポーツライブ、ニュース、ゲームストリーミングなど、一秒一秒が重要なライブストリームに最適です。
LL-HLS を使用するもう 264 つの利点は、遅延のために品質が犠牲にならないことです。 通常の HLS と同じコーデック (H.265 や H.XNUMX など) を使用し、必要なネットワーク条件下で高品質のビデオ ストリーミング エクスペリエンスを提供します。
ほとんどのストリーミング プロトコル、特に低遅延を伴うプロトコルの課題は、拡張が難しいことです。 LL-HLS の場合はそうではありません。 これは HLS 上に構築されており、標準の HLS パッケージを使用しているため、実装と拡張が非常に簡単になります。 その結果、手間をかけずに何千人もの同時ユーザーを関与させることができます。
LL-HLS の最も優れた点の XNUMX つは、iOS、Android、macOS、Windows、tvOS などを含むすべての主要なブラウザーやデバイスと互換性があることです。 この互換性により、ライブ ストリームを視聴できるかどうかを心配することなく、より多くの視聴者にライブ ストリームを届けることができます。
LL-HLS は新しいストリーミング プロトコルであるため、以前のものほど広範なサポートは受けていません。 これにより、特定の情報を検索したり、プロトコルの展開中に発生する可能性のある問題のトラブルシューティングが困難になる可能性があります。
LL-HLS を使用するもう XNUMX つの欠点は、追加機能のため、通常の HLS と比較して実装が複雑であることです。 すでに述べた主要な回避策とは別に、LL-HLS には、場合によっては非常に困難になる可能性のあるいくつかの最適化があります。
低遅延ストリーミングには追加のインフラストラクチャが必要となるため、LL-HLS の実装にかかるコストも通常の HLS よりも高くなります。 ただし、ユースケースでリアルタイムのコンテンツ配信が必要な場合は、このコストに見合う価値があります。
LL-HLS は WebRTC ともよく比較されますが、唯一公平に比較できるのは LL-DASH との比較です。
XNUMX つのストリーミング プロトコルの簡単な比較は次のとおりです。
LL-HLS は Apple 独自のプロトコルである HTTP ライブ ストリーミング (HLS) を使用しますが、LL-DASH はオープン標準の Dynamic Adaptive Streaming over HTTP (DASH) を使用します。
LL-HLS は Apple デバイス専用に設計されています。 ただし、HLS プレーヤーとの下位互換性があるため、クロスプラットフォームおよびクロスデバイスのサポートも受けられます。 LL-DASH は Apple デバイスではサポートされていません。
LL-HLS と LL-DASH の遅延は同等です。 ただし、ユースケースと必要な計算に応じて、どちらの遅延も長くなる場合もあれば短くなる場合もあります。
LL-HLS の「パーツ」は (セグメント全体の小さなファイルまたはバイト範囲として) 個別にアドレス指定可能ですが、LL-DASH の「チャンク」 (または「フラグメント」) は個別にアドレス指定できません。 これは、LL-DASH では、クライアントは、先行するチャンクを送信する前に、サーバーがセグメントを完全にエンコードするのを待つ必要がないことを意味します。
HLS および DASH プロトコルでは、クライアントは定期的な間隔 (たとえば 10 秒) でサーバーをポーリングし、新しいコンテンツを取得するために更新をチェックします。 ただし、LL-HLS と LL-DASH の両方で、クライアントからのポーリングなしでプレイリストを更新することは可能です。 一方、LL-HLS は配信ディレクティブ (_HLS_msn= 、_HLS_part= 、& _HLS_skip=YES|v2)、LL-DASH は、プレーヤーが新しいチャンクを理解するためにマニフェストの更新に依存しません。
.webp)
LL-HLS プロトコルと LL-DASH プロトコルの両方で、コンテンツ保護には MPEG-CENC (Common Encryption) 標準が使用されます。 これらのプロトコルは両方とも Common Media Application Format (CMAF) もサポートしています。コーデックに関しては、LL-DASH はコーデックに依存しませんが、LL-HLS はエンコードに特定のコーデックのみを許可します。
どちらのプロトコルもアダプティブ ビットレート ストリーミングを提供します。 これらは、視聴者の再生エクスペリエンスを中断することなく、ネットワーク状況の変化に基づいてプレーヤーが複数のレンディションを自動的に切り替えるのに役立ちます。 ただし、LL-HLS は、異なるビットレートと解像度の複数のストリームがあるという点で異なります。 LL-DASH には、特定のビットレートと解像度のストリームが XNUMX つだけあります。
LL-HLS が LL-DASH に対して持つもう 4 つの利点は、コンテンツ保護メカニズムに関連しています。つまり、エンコーダーが有効な署名を持つ暗号化ファイルを生成したかどうかをどうやって知ることができるでしょうか。 これを確認するために、HLS プロトコルは EXT–X–KEY タグを使用しますが、DASH は MP4 ファイル内の PSSH ボックス、または MP3 の外側にある xlink と呼ばれる個別の init セグメントに依存します。どちらの方法も追加のネットワーク ラウンドトリップを必要とするため、ライブ ストリーミング イベント中に大幅な遅延が発生する可能性があります。 この問題に対処し、物事をよりシンプルかつ効率的にするために、Apple は KEY ID と IV の値を m8uXNUMX プレイリストに直接組み込むことで、プレイヤーがセグメントをダウンロードする前にそれらを検証できるようにするソリューションを考案しました。追加のリクエスト/レスポンスは必要ありません。
すべての主要なブラウザおよびデバイスと互換性のあるプロトコルを探している場合、LL-HLS は低遅延ストリーミングに最適な選択肢です。 ただし、その実装は通常の HLS に比べて複雑であることに留意することが重要です。
助けが必要な場合は、 お気軽にお問い合わせください.
読んでよかったですか？