低遅延はメディアにおける普遍的な願望です。Wowza のような企業が低遅延ストリーミング テクノロジーを説明するのに最適なチャートを作成した場合、その企業に脱帽し、そのチャートを帰属表示と若干の修正を加えて使用する必要があります。このチャートを図 1 として示します。私が追加した強調表示された番号で指定された順序で説明しましょう。
1. 低遅延のアプリケーション
全員が同じ認識を持っていることを確認するために付け加えておきますが、ライブ ストリーミングのコンテキストにおける遅延とは、ガラスからガラスへの遅延を意味します。最初のガラスは実際のライブ イベントのカメラで、2 番目のガラスはあなたが見ている画面です。遅延とは、 がカメラに表示されてから携帯電話に表示されるまでの遅延です。レイテンシーに寄与する要因としては、(イベントでの) エンコード時間、クラウドへの転送時間、(エンコード ラダーを作成するための) クラウドでのトランスコード時間、配信時間、そして重要なことに、プレーヤーが再生を開始する前にバッファリングする秒数などの要因が挙げられます。
最上層には、一般的なアプリケーションとそのレイテンシー要件が表示されます。低遅延およびほぼリアルタイムの遅延が不足している人気のアプリケーションは、ギャンブル サイトとオークション サイトです。
テクノロジーの説明に入る前に、ライブ ストリームのレイテンシが低いほど、帯域幅の中断に対するストリームの回復力が低下することを理解してください。たとえば、デフォルト設定を使用すると、HLS ストリームは 15 秒以上中断された帯域幅を通じて再生されますが、その時点で復元された場合、視聴者は問題があったことに気付かない可能性があります。対照的に、低レイテンシーのストリームは、中断の直後に再生を停止します。したがって、低遅延の起動時間の利点と、再生の停止という欠点とを常にバランスさせる必要があります。低遅延が絶対に必要でない場合は、それを実現するために復元力を犠牲にする価値はないかもしれません。
ただし、レイテンシを次のように 3 つのカテゴリに分類すると便利です。
オーディオ + ビデオ + IT。私たちの編集者は、オーディオ/ビデオと IT の統合の専門家です。毎日の洞察、ニュース、専門的なネットワーキングを入手してください。今すぐ Pro AV を購読してください。
- あると便利- 速いほど常に良いですが、教育委員会の会議や高校フットボールの試合をライブストリーミングしている場合、特に多くの視聴者が低遅延で視聴している場合は、低遅延よりもストリームの堅牢性が重要であると判断する場合があります。ビットレート接続。
- 競争上の優位性- 場合によっては、低レイテンシが競争上の優位性をもたらすこともあれば、遅いレイテンシが競争上の不利を意味することもあります。グラフを見ると、ケーブル TV の一般的な遅延は約 5 秒であることがわかります。ストリーミング サービスがケーブルと競合している場合は、その範囲内に収まる必要があり、遅延が低いことである程度の競争上の優位性が得られます。
- リアルタイム通信- ギャンブル サイトやオークション サイト、またはその他のアプリケーションでリアルタイム通信が必要な場合は、低遅延を実現することが絶対に必要です。
カテゴリがわかったので、必要なレベルの低遅延を実現する最も効率的な方法を見てみましょう。
2/3 遅延が少ないのは嬉しい
数値 2 は、デフォルト設定を使用して展開された Apple HLS と MPEG-DASH の結果、約 30 秒の遅延が発生することを示しています。数字は単純です。10 秒のセグメント サイズを使用し、再生開始前にプレーヤー バッファーに 3 つのセグメントが存在する必要がある場合、30 秒になります。実際、Apple は数年前に要件を 10 秒から 6 秒に変更し、ほとんどの DASH プロデューサーは 4 ～ 6 秒のセグメントを使用しているため、デフォルトの数値は実際には 20 秒に近くなります。
それでも、3 番目の HLS Tuned と DASH Tuned では、約 6 ～ 8 秒の遅延が発生します。本質的に、チューニングとは、10 秒のセグメントを 2 秒のセグメントに変更することを意味し、同じ計算を適用すると、6 ～ 8 秒の遅延が実現します。したがって、レイテンシがあっても良い場合は、開発時間やコストをかけずに、あるいは配信可能性のリスクを大幅に増加させることなく、レイテンシを大幅に削減できます。
4. 競争上の優位性 - 低遅延 HTTP テクノロジー
競争上の優位性として低遅延が必要な場合、セグメント サイズを削減するだけでは効果がありません。真の低遅延テクノロジーを実装する必要があります。ここには 2 つのクラスがあります。DASH 用の低遅延 HLS や低遅延 CMAF などの HTTP テクノロジー、および WebSocket や WebRTC などの他のテクノロジーに基づくソリューション。
このクラスのアプリケーションを使用するほとんどのプロデューサーにとって、低遅延 HTTP テクノロジーは、手頃な価格、下位互換性、柔軟性、機能セットの最適な組み合わせを提供します。したがって、このセクションでは DASH の低遅延 HLS と低遅延 CMAF について説明し、次のセクションでは他のテクノロジーについて説明します。
図 2 に示すように、すべての HLS/DASH/CMAF ベースの低遅延システムは同じ基本的な方法で動作します。つまり、完全なセグメントがエンコードされるまで待機するのではなく、通常は 6 ～ 10 秒かかります (図 2 の上部)。の場合、エンコーダーは非常に短いチャンクを作成し、完成するとすぐに CDN に転送されます (図 2 の下部)。
たとえば、エンコーダが 6 秒のセグメントを生成していた場合、少なくとも 6 秒の遅延が発生することになります。再生が始まる前に視聴者が通常の 3 つのセグメントを受信する必要がある場合の 3 倍になります。ただし、エンコーダーが 200 ミリ秒ごとにチャンクをプッシュし、プレーヤーがすぐに再生を開始するように構成されている場合、レイテンシーははるかに小さくなるはずです。このスキーマの主な利点の 1 つは、下位互換性です。セグメントはまだ作成中であるため、低遅延スキーマと互換性のないプレーヤーでも、遅延は長くなりますが、セグメントを再生できるはずです。これらのセグメントは、ライブ ストリームからの VOD プレゼンテーションにも即座に利用できます。
これらの利点に加えて、低遅延 HTTP テクノロジは、WebRTC および WebSockets ベースのテクノロジでは一般的にサポートされていない、暗号化、広告挿入、字幕など、通常の遅延の兄弟の機能のほとんどをサポートします。既存のプレーヤーと配信インフラストラクチャを使用して、選択した低遅延テクノロジを実装できる可能性があり、開発コストやその他のテクノロジ コストを最小限に抑えることができます。
HTTP 低遅延テクノロジーの選択
HTTP アダプティブ ストリーミングには、HLS と DASH という 2 つの主要な標準に加えて、統一コンテナ形式である CMAF があります。Apple が低遅延 HLS (新しいタブで開きます)ソリューションを発表すると、すぐにいくつかの草の根の取り組みに取って代わられ、HLS に低遅延を実現するための最適なテクノロジになりました。この仕様はまだ比較的新しいものですが、WowzaやWMSPanelなどのテクノロジー プロバイダーによってNimble Streamer 製品ですでにサポートされています。
低遅延 DASH にはDVB 標準があり、DASH Industry Forum は、DASH のいくつかの低遅延モードを次の相互運用性ガイドラインに含めることを承認しました。これらすべての仕様に従って、エンコーダおよびプレーヤーの開発者とコンテンツ配信ネットワークは、すべての DASH/CMAF 低遅延アプリケーションが本格的に稼働できるよう、相互運用性を確保するために数年間取り組んできました。
一例として、Harmonic と Akamai は、NAB と IBC 2017 に遡って低遅延 CMAF を共同で実証し、遅延が 5 秒未満のライブ OTT 配信を示しました。それ以来、Harmonic は、低遅延 DASH 機能をアプライアンスベースの製品 (Packager XOS および Electra XOS) および SaaS ソリューション (VOS Cluster および VOS260) に統合してきました。他の多くのエンコーダおよびプレーヤーのベンダーも同様のことを行っています。
Low Latency HLS または Low Latency for DASH、またはその両方の実装を選択するかどうかに関係なく、既存の HLS および/または DASH 配信アーキテクチャからの移行は比較的シームレスで安価である必要があります。
5. リアルタイム通信
WebRTC は通常、エンコーダ、プレーヤー、配信インフラストラクチャを含む統合パッケージのエンジンです。WebRTC ベースの大規模ストリーミング ソリューションの例には、Phenix のReal Time 、 Limelight Realtime Streaming、CoSMo Softwareおよび Influxis の Millicast などがあります (図 3)。Wowza Streaming Engine、CoSMO Software、Red 5 Pro Serverなどのツールで WebRTC テクノロジにアクセスすることもできます。このクラスのテクノロジーの遅延時間は、ストリームの 71% で 0.5 秒 (Phenix)、500 ミリ秒未満 (Red5 Pro)、1 秒未満 (Limelight) の範囲です。2 秒未満の遅延が必要な場合は、WebRTC を検討する必要があります。
リアルタイム通信が必要な場合は、WebRTC または Websockets ベースのソリューションを実装する必要がある可能性があります。WebRTC はブラウザ間の通信用に策定されており、Android、iOS、Chrome OS、Firefox OS、Tizen 3.0、BlackBerry 10 上のすべての主要なデスクトップ ブラウザでサポートされているため、これらのプラットフォームではダウンロードせずに実行できます。名前が示すように、WebRTC は、ピアツーピアまたはサーバーツーピアで各視聴者にライブ ストリームを配信するためのプロトコルです。
WebSocket は、サーバーとクライアントの間の永続的な接続を作成および維持するリアルタイム プロトコルであり、どちらの当事者もデータ送信に使用できます。この接続はビデオ配信とその他の通信の両方をサポートするために使用できるため、アプリケーションで対話性が必要な場合に便利です。WebRTC 実装と同様、WebSocket を使用するサービスは通常、プレーヤーと CDN を含むサービスとして提供され、RTMP または WebRTC 経由でストリームをサーバーに転送できる任意のエンコーダーを使用できます。例としては、Nanocosmos のnanoStream クラウドや Wowza の超低遅延ストリーミング クラウドが挙げられます。Wowza は自社のソリューションの遅延が 3 秒未満であると主張していますが、Nanocosmos はガラスからガラスまでで約 1 秒であると主張しています。
その他の低遅延テクノロジー
低遅延を実現するためにさまざまなテクノロジーを使用する、「その他」と最もよく呼ばれる 4 番目のカテゴリーの製品があります。このカテゴリには、THEO Technologies High Efficiency Streaming Protocol (HESP) が含まれます。これは独自の HTTP アダプティブ ストリーミング プロトコルで、THEO によれば、他の低遅延テクノロジーと比較して帯域幅を約 10% 削減しながら、100 ミリ秒未満の遅延を実現します。HESP は標準のエンコーダーと CDN を使用しますが、パッケージャーとプレーヤーでのカスタム サポートが必要です (図 4)。HESP の詳細については、こちらからダウンロードできるホワイト ペーパーをご覧ください。
どの低遅延テクノロジーを実装するか、またその方法を決定する際に考慮すべき質問のリストを次に示します。
構築するか購入しますか?
テクノロジーを自分で実装する場合は、テクノロジーを選択する前に、以下にリストされているすべての質問に必ず答えてください。サービス プロバイダーを選択する場合は、それらを使用してさまざまなサービス プロバイダーを比較してください。
標準を選択しますか、それともパートナーを選択しますか?
上記では低遅延を実現するためのさまざまなテクノロジーの概要を説明しましたが、実装はサービス プロバイダーによって異なります。したがって、少なくとも最初は、すべての LL HLS 実装に ABR 配信が組み込まれるわけではありません。従来のブロードキャストのようなアプリケーションのほとんどは、低遅延の HLS/DASH/CMAF などの HTTP ベースの標準に移行する可能性が高く、一方、賭博やオークションなどの超低遅延を必要とするアプリケーションは、他のテクノロジーに引き寄せられるでしょう。いずれの場合も、サービス プロバイダーを選択するときは、実際にどのテクノロジーを実装しているかよりも、そのプロバイダーが技術的およびビジネス上の目標を達成できるかどうかを判断することが重要です。
規模を拡大できますか?またコストはどれくらいですか?
HTTP ベースのテクノロジーの利点の 1 つは、ほとんどの CDN を使用して標準価格で拡張できることです。対照的に、ほとんどの WebRTC および WebSocket ベースのテクノロジーでは、サービス プロバイダーが実装する専用の配信インフラストラクチャが必要です。このため、非 HTTP ベースのサービスは、HLS/DASH/CMAF よりも配信コストが高くなる可能性があります。サービス プロバイダーを比較する場合は、イングレス、トランスコーディング、帯域幅、VOD ファイルの作成、1 回限りまたはイベントごとの構成などを含む、イベントの基本コストを確認します。
実装関連の問題?
テクノロジーの実装と使用に関して次の質問をしてください。
- 視聴者の規模と地理的分布に応じた規模で達成可能なレイテンシはどれくらいですか?
- 品質制限はありますか- 一部のテクノロジーは、特定の最大解像度または H.264 プロファイルに制限される場合があります。
- パケットはファイアウォールを通過しますか? HTTP ベースのシステムは、ファイアウォールと親和性の高い HTTP プロトコルを使用します。他のユーザーは UDP を使用しますが、ファイアウォールを自動的に通過できない場合があります。UDP の場合、ブロックされた視聴者に配信するバックチャネルはありますか?
- どのようなプラットフォームがサポートされていますか? おそらくコンピューターとモバイルデバイスですが、STB、ドングル、OTT デバイス、スマート TV はどうでしょうか?
- システムは目標視聴者数に合わせて拡張できますか? CDN インフラストラクチャはプライベートですか? プライベートであれば、すべての関連市場のすべての関連視聴者に配信できますか? スケーリングにかかる予想コストはどれくらいですか?
- 独自のプレーヤーを使用できますか、それともシステムのプレーヤーを使用する必要がありますか? 独自の場合、どのような変更が必要で、それにはどれくらいの費用がかかりますか?
- モバイル再生には何が必要ですか? ストリームはブラウザで再生されますか、それともアプリが必要ですか? 必要な (または望ましい) アプリがある場合、SDK は利用可能ですか?
- システムはどのエンコーダを使用できますか? ほとんどの場合、クラウド トランスコーダへの RTMP 接続をサポートできるエンコーダを使用する必要がありますが、他のプロトコルが必要かどうかを確認してください。
- コンテンツを VOD に再利用できますか? それとも再エンコードが必要ですか? 妥当なエンコーディング ラダーにトランスコードするにはビデオ 1 時間あたり約 20 ドルかかるため、大した金額ではありませんが、頻繁なブロードキャストでは高価です。
- 冗長性のオプションとそのコストは何ですか? ミッション クリティカルなブロードキャストの場合、イベント中にシステム コンポーネントがダウンした場合にエンコード/ブロードキャスト ワークフローを複製する方法を知っておく必要があります。この冗長性はサポートされていますか?またコストはいくらですか?
どのような機能が、どのような規模で利用可能ですか?
さまざまなベンダーからさまざまな機能が提供されますが、これには以下が含まれる場合と含まれない場合があります。
- ABR ストリーミング- ストリームの数と、関連するビットレートまたは解像度の制限はありますか?
- DVR機能についてはどうですか? 視聴者はコンテンツを失わずに再生を停止および再開できますか。
- ビデオの同期- システムはすべての視聴者をストリーム内の同じポイントに同期できますか? ストリームは場所やデバイス上を移動する可能性があり、この機能がないと、一部の接続上のユーザーがオークションやギャンブルで有利になる可能性があります。
- どのようなコンテンツ保護が利用可能ですか? プレミアム コンテンツ プロデューサーの場合は、真の DRM が必要になる場合があります。認証やその他の同様の技術を使用して対処できる人もいます。
- 字幕は利用できますか? キャプションは一部の放送では法的に義務付けられていますが、一般的にはすべての放送にとって有益です。
- 広告の挿入やその他の収益化スキームについてはどうですか? テクノロジー/サービスプロバイダーはこれをサポートしていますか?
一般に、ストリーミング ショップが 5 ～ 6 秒台のブロードキャスト時間を達成または上回ることを目指している場合、標準ベースの HTTP テクノロジがおそらく最善の策です。これは、同じ機能セットのサポートに最も近いためです。コンテンツ保護、キャプション、収益化などを現在使用しています。はるかに低いレイテンシーを必要とするアプリケーションがある場合は、おそらく WebRTC または Websockets ベースのソリューション、または独自の HTTP テクノロジーが必要になります。いずれの場合も、上記の質問をすると、ニーズに最も適したテクノロジーやサービス プロバイダーを特定するのに役立ちます。