.webp)
HTTP ライブ ストリーミングは激動の時代に誕生しました。 2007 年の iPhone の発売により、スマートフォン戦争が始まりました。 それに伴い、コンテンツ消費にも地殻変動が起こりました。
.webp)
携帯電話はすでに普及していました。 ユーザーはデスクトップに縛られなくなりました。 外出先でもインターネットにアクセスできます。 スマートフォンがこの傾向をさらに加速させるのは必然だった。 そのため、コンテンツ プロバイダーは、この新たなモビリティに合わせてビデオを配信する必要がありました。
しかし、そこには大きな課題がありました。 Adobe の Flash Player は、当時のビデオ配信の王者でした。 ただし、フラッシュはモバイル デバイス向けに十分に最適化されていませんでした。 XNUMX つはバッテリーの消耗で、外出先でビデオを見たいユーザーにとっては大きな懸念事項でした。 また、Flash はタッチスクリーン用に微調整されておらず、特定のモバイル オペレーティング システムはまったくサポートされていませんでした。
.webp)
Apple は、新しい標準が必要であることにすぐに気づきました。 RTMPモバイル デバイス上のストリームと同様に、HTML5 仕様を利用して、帯域幅の使用効率を高めます。 そこで 2009 年に HTTP ライブ ストリーミング (HLS) を提案しました。 それ以来、ストリーミング プロトコルは、すべてのプラットフォームとブラウザでビデオを配信するための事実上の標準になりました。
この記事では、HLS とは何か、HLS ストリームがどのように機能するか、プロジェクトで HLS ストリームを使用する必要がある場合について詳しく説明します。
HTTP ライブ ストリーミングは、インターネット上でビデオおよびオーディオ コンテンツを配信するために Apple によって作成された適応型ビットレート通信プロトコルです。 XNUMX つの主要な Web 標準の XNUMX つであるハイパーテキスト転送プロトコル (HTTP) を使用して、サーバーとクライアントの間でデータを転送します。
HLS は、クロスデバイス、クロスプラットフォームのパフォーマンスに加えて、信頼性と拡張性を考慮して設計されています。 これらの特徴により、大規模なライブ イベントやビデオ オン デマンド (VOD) などのさまざまなストリーミング アプリケーションに最適です。
MPEG-DASH などの他の適応ビットレート技術と比較すると、HLS は、特定の解像度に対してビットレートが異なる複数のストリームを使用するという点で異なります。 逆に、DASH は、特定の解像度のビットレートに対して単一のストリームを使用します。 したがって、固定ネットワーク条件下では DASH の方が優れたパフォーマンスを提供しますが、現実の世界では HLS の方が優れています。
ネットワーク接続に基づいて異なるストリーム間を切り替える HLS の機能により、優れたストリーミング パフォーマンスが拡張されます。 インターネットの速度は、特に携帯電話ネットワークでは常に変化する傾向があるため、これにより、現実世界の状況において比類のないユーザー エクスペリエンスが提供されます。 HTTPベースのプロトコルであるため、 HLS はデバイス間で簡単に実装できます、コンテンツプロバイダーとプラットフォームの両方にとって魅力的な選択肢となっています。
HLS の仕組みは非常に簡単です。 解像度、ビットレートの組み合わせ (レンディション)、言語、コーデック、メタデータなどに関する情報を含むマスター プレイリスト (マスター マニフェストとも呼ばれます) がプレーヤーに送信されます。 これらの各レンディションには、名前、シーケンス、およびそれぞれの URL (URI) をリストした個別のプレイリスト (子マニフェストとも呼ばれます) があります。
.webp)
次に、プレーヤーはこれらのプレイリストをダウンロードし、再生を開始します。 ビデオの再生中、クライアントはデバイスのネットワーク状態に基づいてレンディションを切り替えます。 この面倒な作業はすべてバックグラウンドで実行され、中断のない再生が保証されます。
.webp)
上の画像は、マルチバリアント HLS プレイリストを表しています。 これは #EXTM3U タグで始まります。これは必須であり、拡張 M3U ファイルを表します。 #EXT-X-STREAM-INF は、次の URL (URI) が別のプレイリスト ファイル、つまり子マニフェストであることをプレーヤーに通知します。
#EXT-X-STREAM-INF タグには、BANDWIDTH (ビット/秒の上限ビットレート) や CODECS (カンマで区切られたオーディオとビデオの RFC-6381 ベースのフォーマット識別子) など、いくつかのパラメーターが含まれています。 CODECS パラメータはオプションですが、強くお勧めします。 これは、オーディオおよびビデオ ストリームにどのエンコーダが使用されているかを示します。 RESOLUTION (ピクセル単位の表示サイズ)、FRAME-RATE (最大フレーム レート)、および AVERAGE-BANDWIDTH (平均ビットレート) にも同じことが当てはまります。 HDCP 保護の場合、HDCP-LEVEL パラメータを使用することもできます。 TYPE-0 (HD 解像度の場合) と TYPE-1 (HD を超える解像度の場合) を使用するだけです。
これは、より高度なマルチバリアント プレイリストの別の例です。
この例では、追加のオーディオ レンディションの XNUMX つのグループ (audio-lo および audio-hi の GROUP-ID で表される) を含むプレイリストが表示されます。 すべてのメディア要素 (この場合、さまざまな言語のオーディオ ファイル) は、タグ EXT-X-MEDIA とそのタイプ (AUDIO、VIDEO、SUBTITLES、または CLOSED-CAPTIONS) で表す必要があります。
また、すべてのメディア選択グループの要素が同じ特性でエンコードされている必要があります。 たとえば、コーデックや最大帯域幅などが同じである必要があります。
HTTP ライブ ストリーミングには、オリジン サーバー、配信サーバー (エッジ)、クライアントの XNUMX 層アーキテクチャがあります。
オリジン サーバーは AV 入力を受信し、それを配布できる圧縮ファイルに変換します。 通常、これはメディア エンコーダとストリーム セグメンタで構成されます。 メディア エンコーダは、メディア ファイルを互換性のある形式にエンコードします。 次に、ストリーム セグメンタは、エンコードされたメディアを小さなセグメントに分割し、インデックス ファイルを作成します。 インデックス ファイルには、メディア セグメントのメタデータが含まれています。
配信サーバー (CDN) は、コンテンツをクライアントに配信する役割を果たします。 HTTP サーバーとメディア サーバーで構成されます。 HTTP サーバーはインデックス ファイルとメディア セグメントを保存します。 メディア サーバーはメディア ファイルをクライアントにストリーミングします。
クライアントは、配信サーバーにコンテンツを要求して受信する責任があります。 これは、HTTP クライアントまたはメディア プレーヤーで構成されます。 HTTP クライアントは、HTTP サーバーにインデックス ファイルを要求します。 次に、メディア プレーヤーはインデックス ファイルを使用してメディア サーバーにメディア セグメントを要求し、それらを再生します。
HTTP ライブ ストリーミングには、コンテンツ プロバイダーにとって頼りになる選択肢となる多数の機能が備わっています。 その主な機能のいくつかを見てみましょう。
HLS の最も優れた点の 45 つは、ライブ、オンデマンド、およびイベント プレイリストをサポートしていることです。 これは、同じプロトコルを使用して、サーバーに保存されている既存のビデオ ファイルだけでなくイベントもライブ ストリーミングできることを意味します。 ただし、HLS は遅延よりもビデオ品質を優先するため、ストリーミング プロトコルをエンドツーエンドで使用すると、ストリームに最大 XNUMX 秒の遅延が発生する可能性があります。 この課題は通常、別のプロトコル (たとえば、 RTMP）摂取用。 これは LL-HLS 拡張機能の一部であり、遅延を約 2 秒にまで短縮します。 XNUMX秒。
HLS のもう 4 つの優れた点は、すべての主要なブラウザーおよびプラットフォームと互換性があることです。 これには、Safari、Edge、Chrome、Firefox、Android、iOS、tvOS、Playstation XNUMX、Xbox Oneなどが含まれます。 したがって、デスクトップ、モバイル デバイス、スマート TV のいずれのユーザーにコンテンツを配信する場合でも、HLS が必要です。
HTTP ライブ ストリーミングは複数のビットレートもサポートします。 これは、さまざまなデバイスやインターネット速度に応じて、ビデオをさまざまなビットレートにエンコードできることを意味します。 その後、クライアントはネットワーク状況に基づいてこれらのレンディションを自動的に切り替え、シームレスなビデオ配信を保証します。 これにより、バッファリングや低品質のビデオ ストリームの兆候がなくなり、ユーザー エクスペリエンスが向上します。
HTTP ライブ ストリーミングは暗号化と認証もサポートしています。 これは、ビデオ ストリームを暗号化して不正アクセスから保護できることを意味します。 ユーザーがコンテンツにアクセスできるようになる前に、ユーザーを認証することもできます。 これは、ペイウォールの内側でコンテンツを配信したり、特定の国や地域へのアクセスを制限したりする場合に特に便利です。
HLS のもう XNUMX つの優れた点は、複数の言語をサポートしていることです。 つまり、さまざまな言語のバリアント プレイリストを作成でき、クライアントはユーザーの好みの設定に基づいてそれらを自動的に切り替えます。 そのため、英語、スペイン語、フランス語、その他の言語でコンテンツを配信したい場合でも、HLS が対応します。
クローズド キャプションは、聴覚障害のある人が音声コンテンツを理解できるようにする機能です。 HLS では、ビデオ ストリームにキャプションを埋め込むことができるため、クローズド キャプションがサポートされています。 これらのキャプションはビデオとともに画面に表示され、簡単にアクセスできるようになります。
字幕はクローズドキャプションに似ていますが、通常、視聴者が音声対話に慣れていない外国語の映画やテレビ番組に使用されます。 クローズド キャプションと同様に、HLS を使用すると、ビデオ ストリームに字幕を埋め込んで、ビデオ自体と一緒に画面に表示できるようになります。
音声説明は、視覚障害のある人のために画面上で何が起こっているかを説明する音声トラックの一種です。 HLS は、ビデオ ストリームに埋め込むことができるようにすることで、Descriptive Video Service (DVS) と呼ばれる音声説明トラックをサポートします。 DVS は属性 CHARACTERISTICS="public.accessibility.describes-video" でマークされている必要があります。
HLS とは何か、そして HLS がどのように機能するかを説明したところで、その主な利点のいくつかを見てみましょう。
前述したように、HLS の最も優れた点の XNUMX つは、すべての主要なブラウザーおよびプラットフォームと互換性があることです。 これは、同じプロトコルを使用して、デスクトップ、モバイル デバイス、スマート TV などのユーザーにコンテンツをストリーミングできることを意味します。 したがって、iPhone または Android デバイスのどちらでユーザーにコンテンツを配信したい場合でも、HLS は頼りになるストリーミング プロトコルです。
デジタル コンテンツをストリーミングする場合、品質が最も重要です。 現在、ユーザーは選択の余地がありません。 あなたのサイトにあるものが気に入らない場合は、簡単に次のサイトに移ることができます。 ここで HLS が真価を発揮します。 ストリーミング プロトコルは、アダプティブ ビットレート ストリーミングを使用して、ネットワーク状況に基づいてビデオ品質を自動的に調整します。 これにより、インターネット速度や接続品質に関係なく、ユーザーは常に優れた視聴体験を得ることができます。
デジタル コンテンツのストリーミングに関しては、コストが常に大きな懸念事項となります。 HTTP ライブ ストリーミングは、追加のハードウェアを必要としないため、非常にコスト効率の高いソリューションです。 必要なのは標準的な Web サーバーだけで、準備完了です。
HLS のもう XNUMX つの優れた点は、暗号化と認証をサポートしていることです。 これは、ビデオ ストリームを暗号化して不正アクセスから保護できることを意味します。 HLS を使用すると、Microsoft PlayReady、Google Widevine、Apple FairPlay などの標準的な DRM ソリューションを作成することもできます。 このため、HLS は、ペイウォールの内側で配信する必要があるコンテンツ、または特定の国/地域に制限して配信する必要があるコンテンツにとっても理想的な選択肢になります。
HTTP ライブ ストリーミングには多くの利点がありますが、独自のプロジェクトで使用する前に注意しておく必要がある欠点もいくつかあります。 その主な欠点をいくつか見てみましょう。
HLS の最大の課題の XNUMX つは遅延、つまりビデオ データがサーバーからクライアントに送信されるまでにかかる時間です。 一秒一秒が重要なライブ イベントをストリーミングしようとしている場合、これは問題になる可能性があります。 このレイテンシを短縮するのに役立つさまざまなソリューションが利用可能ですが (これについては後ほど説明します)、プロジェクトで HLS の使用を計画している場合は、この点に留意する必要があります。
HLS のもう 400 つの欠点は、低品質のビデオの場合は最低 8 kbps、HD 品質の場合は最大 XNUMX Mbps のインターネット速度が必要なことです。 これは、インターネットの通信範囲が狭い地域や、データ プランが限られているユーザーにとっては大きな問題となる可能性があります。
HLS を使用する場合の遅延を削減するのに役立つさまざまなソリューションが利用可能です。 そのうちのいくつかは次のとおりです。
Apple は 6 秒の長さを推奨していますが、セグメント サイズ (ターゲット期間) を小さくすると、遅延を大幅に短縮できます。 これは、クライアントがサーバーからセグメントが公開されるのを待つためです。 サーバーは、所定の目標期間が経過する前にそれを公開することはできません。 したがって、プレーヤーがセグメントをダウンロードする前に、すでに「ターゲット期間」秒だけ遅れています。 さらに、斑点のあるネットワークでもシームレスな配信を保証するために、複数のセグメントがバッファとして保持されます。 これには、すべてのセグメントのエンコード、パッケージ化、プレイリストのリスト化、ダウンロードが含まれ、セグメント サイズの 4 ～ 7 倍の遅延が発生します。
実際に利用可能になる前に、セグメントをアナウンスしてみることができます。 これは、#EXT-X-PRELOAD-HINT タグを設定して、次のストリームの最も可能性の高い場所を示すことによって行われます。
別の取り込みプロトコルを使用すると、サーバー側のエンコーディングがより高速なエンコーダーに転送され、優れた効率が実現します。 低遅延 HLS (LL-HLS) を使用することもできます。 LL-HLS は HLS プロトコルの一部ですが、いくつかの回避策があります。 遅延は (約 2 ～ 5 秒) です。
HTTP ライブ ストリーミングは、非常に多用途なストリーミング プロトコルです。 ライブイベントやオンデマンドコンテンツなど幅広い用途にご利用いただけます。 HLS を使用する必要がある状況をいくつか示します。
HLS は、中断のない優れた視聴体験をユーザーに提供することを目的として開発されました。 したがって、視聴者にコンテンツ視聴時に可能な限り最高のエクスペリエンスを提供したい場合は、HLS が最適です。
HTTP ライブ ストリーミングは、スポーツ、コンサート、会議などのライブ イベントのストリーミングに最適です。プロトコルは信頼性と拡張性を考慮して設計されているため、大規模なライブ イベントを問題なくストリーミングできます。 回避する必要がある唯一のことは遅延です。これにはいくつかの簡単な修正があります。
HLS の最も優れた点の XNUMX つは、すべての主要なブラウザーおよびプラットフォームと互換性があることです。 これは、同じプロトコルを使用して、異なるデバイスや異なる地理的地域のユーザーにコンテンツを配信できることを意味します。 したがって、コンテンツを世界中の視聴者に届けたい場合は、HLS が頼りになるストリーミング プロトコルとなるはずです。
HLS のもう XNUMX つの優れた点は、実装が非常に簡単であることです。 必要なのは標準的な Web サーバーだけで、すぐにコンテンツのストリーミングを開始できます。
HTTP ライブ ストリーミングには多くの利点がありますが、使用を避けるべき状況もいくつかあります。 HLS プロトコルを使用すべきではない状況をいくつか示します。
前述したように、HLS の最大の課題の XNUMX つは遅延、つまりビデオ データがサーバーからクライアントに送信されるまでにかかる時間です。 Web 会議やスポーツなどのライブ イベントをストリーミングしようとしている場合、これは問題になる可能性があります。 このレイテンシを短縮するのに役立つさまざまなソリューションが利用可能ですが、プロジェクトで HLS の使用を計画している場合は、この点に留意する必要があります。
HLS のもう 400 つの欠点は、低品質のビデオを再生するには最低 XNUMX kbps のインターネット速度が必要なことです。 これより少ないと、ストリーミングだけでなく、リップシンクをそのまま維持することにも問題が生じる可能性があります。 したがって、このような状況でユーザーにコンテンツを配信したい場合、HLS は最適な選択ではない可能性があります。
HTTP ライブ ストリーミングは、非常に多用途なストリーミング プロトコルです。 オールデバイス配信、優れた品質、コスト効率、プライバシーとセキュリティ、複数言語のサポート、クローズドキャプション、字幕、音声説明など、多くの利点があります。
遅延やインターネット速度の要件などのいくつかの欠点がありますが、これらの課題に対処するのに役立つさまざまなソリューションが利用可能です。 したがって、すべての主要なブラウザーおよびプラットフォームと互換性があり、優れた品質を提供し、実装が簡単なストリーミング プロトコルをお探しの場合は、HLS が最適な選択肢となるはずです。
読んでよかったですか？