ストリーミング メディアのダイナミックな状況では、最適なプロトコルを選択することがシームレスな視聴体験を提供する鍵となります。利用可能なプロトコルの中で、HTTP-FLV (Flash Video over HTTP) は、より確立された HLS (HTTP Live Streaming) よりも注目を集め、人気を集めています。このブログでは、HTTP-FLV について説明し、その機能、パフォーマンス、HLS と比較して人気が高まっている理由について詳しく説明します。
ストリーミング プロトコル入門: 知っておくべき基礎知識
メディアのプロであれば、Appleのエコシステムで広く採用されているため、HLS（HTTPライブストリーミング）についてよくご存知かもしれません。HLSは、オンラインビデオやオーディオメディアをインターネット経由で視聴者にストリーミングするための主要な標準の1つです。 バード.tvHLS は現在、ストリーミング プロトコルの世界的な使用状況でトップにランクされています。
ただし、ネットワーク技術の継続的な進歩と高品質のライブ ブロードキャストの需要の高まりにより、これらのプロトコルのランキングは変化する可能性があります。たとえば、HTTP-FLV は見落とされがちなストリーミング プロトコルです。注目すべき事実は、Douyin、TikTok などを含む多くのメディア大手が、インタラクティブ エンターテイメント セグメントにとって極めて重要な超低遅延エクスペリエンスを求めて HTTP-FLV を採用していることです。
この変化が起こっている理由をよりよく理解するには、ライブ ストリーミングの品質向上という観点から、HTTP-FLV と HLS の主な違いを詳しく調べる必要があります。
HLS (HTTP ライブストリーミング) とは何ですか?
HLS（HTTP Live Streaming）は、Apple が開発し、2009 年に導入されたプロトコルです。QuickTime Streaming Server に代わるものとして、また RTMP などの既存のプロトコルの制限に対処するために作成されました。それ以来、HLS はアダプティブ ビットレート ビデオ ストリーミングの最も広く採用されている標準となり、さまざまなネットワーク条件に適応し、デバイス間の互換性を確保することで、信頼性が高くシームレスな視聴体験を提供しています。
HLS は、当時のインターネット速度によって引き起こされたパフォーマンスの問題に対処する必要性から生まれました。これには、さまざまなネットワークやデバイスの状況に対応し、高い信頼性と互換性を備えたプロトコルが必要でした。これを実現するために、HLS は短い接続を利用してビデオ コンテンツを伝送することでライブ ストリーミング プロセスを変更しました。
簡単に言うと、HLS はコンテンツを小さな部分に分割し、各セグメントのリクエストを作成して、それらを順番に再生します。大きなセグメントによって転送時間が長くならないように、HLS はこれらのセグメントをさらに小さなチャンクに分割し、プレイリスト ファイル (M3U8 形式) にパッケージ化して、解析のためにクライアントに送信します。クライアントはプレイリストを使用して、個々のチャンクを要求して再生します。
M3U8 ファイルにパッケージ化されたすべての TS ファイル (トランスポート ストリーム セグメント) が送信されると、サーバーは引き続き今後のメディア コンテンツをスライスしてパッケージ化し、クライアントが新しいメディア コンテンツを要求するのを待機します。
短い接続によってもたらされる信頼性と適応性に加えて、HLS は、アダプティブ ビットレート ビデオ ストリーミングで広く採用されている標準として、デバイス間の互換性とスケーラビリティにも優れています。
- クロスデバイス互換性 – HLS は、互換性のあるビデオ プレーヤー (HTML5 など) を実行するすべてのクライアント デバイスでコンテンツを再生できることを保証します。つまり、HLS は iOS、Android、スマート TV、ほとんどの Web ブラウザーなど、幅広いデバイスでサポートされています。この幅広い互換性により、ストリーミングの多目的な選択肢となります。
- スケーラビリティ – HLS は標準の HTTP サーバー上で動作し、コンテンツ配信ネットワーク (CDN) と簡単に統合してコンテンツを世界中に配信できるため、バイラル視聴者の急増や大規模なライブ視聴者にも対応できます。
短い接続が HLS にもたらす利点にもかかわらず、このアプローチには依然としていくつかの欠点があります。チャンクまたはセグメントの長さは通常 2 ～ 6 秒であり、一度に複数の小さなセグメントをバッファリングする必要があるため、遅延は最終的に数十秒に達する可能性があります。ここで、新しい接続方法である永続的な接続が役立ちます。
HTTP-FLV とは何ですか?
HTTP-FLV 送信では、一度接続を確立して維持し、その間にサーバーは小さなサイズのファイルをクライアントに継続的に送信します。このプロセスは、クライアントまたはサーバーが切断されるまで継続されます。HTTP-FLV ライブ ストリーミング プロトコルは、FLV ファイルの小さなサイズを利用して、中断のないネットワーク接続を介してビデオ コンテンツを転送し、クライアントが常にコンテンツを再生できるようにします。
本質的に、HTTP-FLV は低遅延ストリーミングを提供するように設計されており、遅延が重要な要素となるリアルタイム アプリケーションに最適です。これは、即時のフィードバックが重要なライブ イベント、オンライン ゲーム、インタラクティブ ストリームにとって特に重要です。
ただし、ライブ ストリーミングではレイテンシーだけが要因ではありません。ライブ ストリーミングにおける究極のユーザー エクスペリエンスは、初期読み込み時間、レイテンシー、バッファリングという 3 つの主要な指標によって決まります。したがって、ここでは 2 つの異なるライブ ストリーミング プロトコルがこれら 3 つの側面にどのように影響するかを比較することに焦点を当てます。
ライブストリーミングにおける HLS と HTTP-FLV のパフォーマンス比較
比較に入る前に、ライブ ストリーミング中のユーザー エクスペリエンスに大きな影響を与えるいくつかの重要な要素を定義しましょう。
初期読み込み時間: ライブ ストリームを要求した後、ビデオの最初のフレームがクライアントの画面に表示されるまでの時間。この時間を短縮すると、待機時間が最小限に抑えられ、ユーザー エクスペリエンスが向上します。
レイテンシー: ライブ イベントが実際に発生してからクライアントの画面に表示されるまでの遅延。言い換えると、コンテンツがキャプチャされてから視聴者が視聴するまでの時間差です。遅延が短いことは、リアルタイムのインタラクションにとって非常に重要です。
バッファリング: クライアントのバッファリングされたコンテンツが不足したために再生が中断または一時停止します。これらの中断の頻度と期間は、ストリーミング品質の重要な指標です。
それでは、次の要素に基づいて HLS と HTTP-FLV を比較してみましょう。
初期読み込み時間
HLS: HLS はセグメント化されているため、再生を開始する前にクライアントが複数のセグメントをダウンロードしてバッファリングする必要があります。これにより、特に低帯域幅のシナリオでは、初期読み込み時間が長くなる可能性があります。通常、リクエスト中にエラーが発生すると、初期バッファリングと遅延が発生する可能性があります。
HTTP-FLV: HTTP-FLV では、サーバーとの接続を 1 回確立するだけで済み、その後はサーバーが継続的にコンテンツをクライアントに送信します。クライアントは、サーバーにリクエストを繰り返し送信することなく、コンテンツを受信して再生するだけで済みます。これにより、接続が確立されるとすぐにクライアントがビデオの受信と再生を開始するため、初期読み込み時間が短縮されます。
レイテンシ（遅延）
HLS: トランスポート層では、HLS はビデオをセグメント化してパッケージ化する必要があります。パッケージ化が完了したら、再生用の実際のビデオ コンテンツを受信するために、さらに 2 つのリクエストが必要です。HLS は初期フレーム時間を短縮するように最適化されていますが、固有の二重リクエスト メカニズムは、HTTP-FLV の単一リクエスト時間に匹敵することはできません。
HTTP-FLV: HTTP-FLV では、単一の接続が確立され維持されるため、サーバーは継続的にビデオ コンテンツをクライアントにストリーミングできます。この永続的な接続により、遅延が大幅に短縮されるため、即時のフィードバックが重要なリアルタイム ブロードキャストに最適です。
バッファリング
HLS: ビデオ コンテンツをセグメント化してパッケージ化するプロセスには、本質的に追加の時間が必要です。送信フェーズでは、各セグメント (通常は 2 ～ 3 セグメント時間) を処理してパッケージ化する必要があります。さらに、クライアントは TS セグメントを要求する前に、まず M3U8 プレイリストを受信する必要があります。さらに、CDN レイヤーでは、M3U8 ファイルをキャッシュする必要があり、余分な時間オーバーヘッドが追加されます。全体として、HLS では、ライブ コンテンツを処理して送信するために、追加の送信時間とキャッシュ時間が発生します。
HTTP-FLV: FLV のファイル サイズが小さく、ネットワーク接続が 1 つだけなので、HTTP-FLV では、送信のオーバーヘッドとして 1 回の接続の待ち時間のみが必要です。これにより、ビデオ コンテンツを可能な限り最短の送信時間で送信できます。
全体的なユーザー エクスペリエンスに影響を与える主要な指標を分析すると、HLS の初期の送信ロジックがやや時代遅れで、送信プロセス中に高い時間コストが発生することが明らかになります。HTTP-FLV は、初期読み込み時間、待ち時間、バッファリングの 3 つの指標すべてにおいて HLS を上回っています。
HTTP-FLVの利点の前提条件と制限
HTTP-FLV はライブ ストリーミング体験において明らかな利点がありますが、一定の前提条件と制限があります。
- CDN アーキテクチャの変更: HTTP-FLV は多くの CDN で HTTP 経由でネイティブにサポートされていないため、最適なパフォーマンスを確保するには CDN アーキテクチャを変更する必要があります。たとえば、CDNetworks はすでにこのようなアーキテクチャ調整を行っています。
- クロスデバイス互換性: HTTP-FLV は、HLS ほど堅牢なデバイス間の互換性を提供しません。レイテンシの短縮には優れていますが、この利点はデバイスのサポートが制限されるという代償を伴います。ただし、HTTP-FLV の低レイテンシは、特に即時のフィードバックによってユーザー エクスペリエンスが向上するアプリケーションにおいて、ユーザー維持と収益性を高める新たな機会を提供します。
しかし、これらの制限にもかかわらず、HTTP-FLV が提供する低遅延により、視聴者のエンゲージメントにとって遅延が最小限であることが重要なエンターテイメント ライブ ストリーミング シナリオで非常に人気があることは認めざるを得ません。
ストリーミングプロトコルの今後の動向
ライブ ストリーミングにおけるリアルタイムのインタラクションと即時のフィードバックに対する需要の高まりにより、低遅延プロトコルが継続的に進化しています。永続的な接続メカニズムを備えた HTTP-FLV は、すでに有力な候補となっています。
しかし、今日説明した2つのプロトコルは、CDNetworksがサポートする低遅延プロトコルのサブセットにすぎないことに注意することが重要です。イベントグレードの低遅延ライブストリーミングテクノロジーを必要とするメディア企業にとって、 CDNetworksの低遅延ストリーミングソリューションWebRTC を利用する は、より優れた選択肢となるかもしれません。一方、OTT 業界に関しては、HLS のデバイス間の互換性が大きな利点となります。
これは重要な点を強調しています。つまり、「最良」のプロトコルは存在せず、特定のニーズに最適なものが存在するだけです。コストと利益、そして企業ブランディングとユーザー エクスペリエンスのバランスを取ることが、最適なプロトコルを選択する鍵となります。
いずれにせよ、信頼性が高く堅牢なストリーミングサービスプロバイダーを選択することが、メディア業界にとって最も便利な選択肢です。CDNetworksを例に挙げてみましょう。CDNetworksは、幅広いライブプロトコルをサポートするだけでなく、2,800を超えるCDNを誇っています。 PoP (Points of Presence) を世界中に展開し、優れたパフォーマンスと優れた顧客サービスを提供します。これらの特性により、CDNetworks は市場での競争力の維持を目指すメディア企業にとって魅力的な長期パートナーとなっています。
この詳細な分析を通じて、ストリーミングメディア分野におけるHTTP-FLVとHLSのアプリケーション、利点、欠点について検討し、ニーズに合ったストリーミングプロトコルをよりよく理解して選択できるようにしました。このブログが貴重な洞察を提供できたことを願っています。さらに質問がある場合や追加の議論が必要な場合は、お気軽にお問い合わせください。 コンタクト 私たち。
