予測できないパブリック インターネット接続により、ビデオ エンジニアは非常にイライラする追い詰められます。多くの場合、信頼性の高いバッファリングのための高いレイテンシか、深刻な視覚的アーティファクトのどちらかを選択する必要があります。通常、パケット損失が多発すると、このような許容できない視覚的エラーが発生します。こうした構造上の妥協は、重要なライブブロードキャスト中の視聴体験を台無しにします。現在、ファーストマイル コントリビューションでは標準 RTMP は廃止されつつあります。構造的に、不安定な携帯電話ネットワーク上で一貫したパフォーマンスを発揮するのは困難です。現在、最新のブロードキャスト ワークフローは完全に Secure Reliable Transport (SRT) プロトコルに依存しています。 SRT は、予測できない伝送ルート上でビデオ パケットがどのように移動するかを再定義します。
ハードウェアベースの Live Streaming Encoder は SRT を完全に利用します。ブロードキャストの信頼性をまったく犠牲にすることなく、1 秒未満の遅延を実現します。この最新のインターネット プロトコルの基礎となるアーキテクチャを学びます。さらに、今日必要な正確な評価基準の概要を説明します。プロ仕様のエンコーディング ハードウェアをアップグレードする場合、これらの正確な基準が非常に重要になります。
SRT は、TCP ベースの配信を UDP ベースのフレームワークに置き換え、自動再送要求 (ARQ) を利用して失われたパケットを従来のプロトコルよりも速く回復します。
構成可能なレイテンシ バッファにより、エンジニアは実際の往復時間 (RTT) に基づいて速度と信頼性のバランスを正確に調整できます。
SRT 対応のライブ ストリーミング エンコーダにアップグレードすると、ファーストマイルへの貢献における高価な専用衛星ネットワークや MPLS ネットワークへの依存が軽減されます。
SRT エンコーダを評価するには、プロトコルのサポートを超えて、ハードウェア アクセラレーション (HEVC/H.265) とファイアウォール トラバーサル機能を評価する必要があります。
従来のブロードキャスト プロトコルは、伝送制御プロトコル (TCP) メカニズムに大きく依存しています。 TCP は常に厳格なパケット確認応答を要求します。単一のデータ パケットが途中でドロップすると、TCP はビデオ ストリーム全体をただちに停止します。欠落したデータが正常に再送信されるまで頑固に待機します。この厳格なフレームワークにより、ライブ イベント中に予測できない深刻な遅延スパイクが発生します。 RTMP は、これらの壊滅的なヘッドオブラインブロッキングの問題に深く悩まされています。 RTMP を使用した携帯電話接続でのスムーズな再生は保証できません。
標準ユーザー データグラム プロトコル (UDP) は純粋な伝送速度を提供します。インターネット上で継続的にパケットを送信します。受信者からの配信確認を待つことはありません。ただし、標準の UDP にはネイティブのエラー修正がまったくありません。常にフレーム落ちが発生します。ネットワークの輻輳が接続に発生すると、深刻なマクロブロッキングが発生します。標準の UDP では、ブロードキャスト品質のフィードを保証できません。速度を優先して信頼性を完全に放棄します。
レイテンシは、さまざまなライブ ブロードキャスト セクターにわたって運用上の多大なペナルティをもたらします。エンジニアは、これらの財務コストと運用コストを慎重に評価する必要があります。視聴者の期待が高まるにつれて、ビジネスへの影響は飛躍的に増大します。次の特定の操作上の遅延ペナルティを考慮してください。
リモート プロダクション フィードの遅延により、正確なマルチカメラ ライブ スイッチングが妨げられます。
同期が取れていないリモートインタビューは、ニュースセグメントの自然な会話のタイミングを破壊します。
ライブベッティングアプリでは大幅な遅延が発生し、アクティブな参加者がすぐに離れてしまいます。
オーディオとビデオのドリフトは、一か八かの企業活動中にブランドの信頼に重大なダメージを与えます。
最新の放送設定では、非常に具体的な成功基準が求められます。エンジニアリングの最終目標には、予測可能な遅延を達成することが含まれます。私たちは 2 秒以内の配達時間を厳密に目指しています。私たちは、標準の管理されていないパブリック インターネット接続を介してこの困難な偉業を達成しなければなりません。エンジニアはあらゆる場所で信頼性の高いパフォーマンスを必要とします。高価な専用ファイバー回線や衛星トラックへの依存は積極的に避けなければなりません。
SRT は、その基礎となるベース層として標準の UDP を使用します。この堅牢な基盤により、遅い接続ハンドシェイクが完全に排除されます。 TCP では、基本的な通信を確立するだけでも、時間のかかる複数の往復が必要になります。 SRT は、この煩わしいオーバーヘッドを完全に除去します。これにより、行頭のブロックが永久に回避されます。データはエンコーダーから宛先サーバーまで自由かつ継続的に流れます。
自動再送要求 (ARQ) と前方誤り訂正 (FEC) を比較する必要があります。 ARQ は、高度にインテリジェントなデータ回復メカニズムとして機能します。受信機は受信パケット シーケンスを継続的に監視します。パケットが失われた場合、受信側はただちに対象を絞った再送信を要求します。特定の欠落データ チャンクのみを要求します。逆に、FEC は冗長データを盲目的かつ継続的に送信します。 FEC は、大量の帯域幅オーバーヘッドを不必要に消費します。 ARQ は全体的に使用する帯域幅がはるかに少なくなります。実際のパケット損失イベントにのみ反応します。
エンコーダは、すべてのメディア パケットに正確なタイムスタンプを適用します。デコーダはこれらの正確なタイムスタンプを利用して、ビデオ ストリームを完全に再構築します。意図した正確なペースでビデオを再生します。ネットワークのジッターが最終的な表示タイミングに影響を与えることはなくなりました。視聴者は、公衆インターネットのルートの変動に関係なく、信じられないほどスムーズな動きを確認できます。
SRT は、魔法のように真の「ゼロ レイテンシ」を提供するわけではありません。代わりに、意図的に数学的に計算されたバッファ ウィンドウを利用します。この特定のバッファは重要な技術的目的を果たします。通常、エンジニアはこのウィンドウをネットワーク RTT の 3 倍または 4 倍に設定します。この慎重に計画されたバッファにより、ARQ 再送信に十分な時間が確保されます。欠落したパケットは、フレームが画面上に表示される前に安全に到着します。このアーキテクチャは、遅延を最小限に抑えながら、完全なビジュアルを保証します。
RTMP には、複雑な複数ステップのハンドシェイク プロトコルが必要です。デバイス間の基本的な通信チャネルを確立するために貴重なミリ秒が無駄になります。 SRT は代わりに、非常に合理化された接続プロセスを使用します。ほぼ即座に認証と接続が行われます。重要な初期ストリーム起動時の貴重なセットアップ時間を節約できます。
RTMP は、単一のパケットがドロップされるとブロードキャスト ストリーム全体を停止させます。プロトコルは、データの欠落部分を延々と待ちます。 SRT はパケット損失を外科的に処理します。厳密に固定されたレイテンシ ウィンドウ内でターゲットを絞ったリカバリを要求します。ビデオフィードは引き続きスムーズに再生されます。視聴者は、根底にあるネットワークの中断にほとんど気づきません。
SRT は設計上、ペイロードに厳密に依存しません。ビデオ データを安全にラップするだけで、迅速な転送が可能になります。レガシー RTMP は、最新のビデオ コーデックをネイティブにサポートするのに非常に苦労しています。 SRT を使用する最新のエンコーダーは、HEVC/H.265 ビデオを簡単に送信します。 HEVC により、全体的なビットレート要件が大幅に軽減されます。非常に高いビジュアル品質を継続的に維持します。古い AVC コーデックと比較して、半分の標準帯域幅を使用します。
プロトコル選択のための客観的なベースラインを提供する必要があります。 RTMP は今でも時々有効な目的を果たします。従来のコンテンツ配信ネットワーク (CDN) の取り込みは、依然として RTMP に大きく依存しています。多くの古い消費者向けプラットフォームは、最新のプロトコルをまだサポートしていません。ただし、SRT は他のワークフローでは依然として絶対に必須です。ポイントツーポイントの貢献とリモート生産には、ネイティブに SRT が必要です。地理的に離れた場所に安全かつ低遅延で配信するには、これが絶対に必要です。
機能の寸法 |
RTMP (レガシー) |
SRT (モダン) |
|---|---|---|
基礎となるトランスポート |
TCP (行頭ブロックが発生しやすい) |
UDP (高速、ストリーム指向の配信) |
パケットロスの処理 |
回復するまでストリーム全体を停止します |
固定バッファ内でのターゲット ARQ リカバリ |
HEVC/H.265のサポート |
悪い (非標準的なハックが必要) |
優れた (ペイロードに依存しないアーキテクチャ) |
理想的な運用ユースケース |
従来のソーシャル CDN への最終配信 |
ファーストマイルのリモート生産への貢献 |
の設定 HDMI エンコーダでは、 特定のネットワーク変数に細心の注意を払う必要があります。実際のインターネット伝送経路を理解する必要があります。ここではエンジニアは実証済みの厳格な経験則に従います。まず宛先 IP アドレスに繰り返し ping を実行する必要があります。これにより、実際のネットワーク RTT が正確に明らかになります。この重要な指標を推測しないでください。 SRT レイテンシー バッファーを RTT のちょうど 4 倍に設定することが、標準の開始点として機能します。これにより、信頼性の高いライブ ビデオ ストリームが保証されます。
企業の IT ファイアウォールは、未知の受信トラフィックを常にブロックします。このセキュリティ対策は、リモート ブロードキャスト エンジニアにとって大きな悩みの種です。 SRT は、まさにこの問題を効率的に解決するために 3 つの特定のハンドシェイク モードを提供します。
発信者モード: エンコーダーはアウトバウンド接続を直接開始します。このモードは、厳格な企業ファイアウォールの背後で完全に機能します。ファイアウォールは通常、送信トラフィックを自由に許可します。
リスナー モード: デコーダーは受信接続要求を積極的に待ちます。この設定には、受信側ネットワーク ルーターに専用のポート転送が必要です。
ランデブー モード: 双方が同時に接続を試みます。この賢いアプローチにより、特定の複雑なネットワーク アドレス変換 (NAT) 制限を効果的に簡単に回避できます。
ARQ 再送信が正しく機能するには、追加のネットワーク容量が必要です。利用可能なアップロード速度を安全に最大にすることはできません。必要なネットワーク帯域幅のオーバーヘッド許容量を常に残してください。ターゲット ビデオ ビットレートより 10 ～ 15 パーセントの追加帯域幅をプロビジョニングすることを強くお勧めします。この重要な許容量は、突然の ARQ 再送信スパイクにシームレスに対応します。局所的なネットワークの重度の輻輳時の予期しないビデオ バッファリングを厳密に防ぎます。
測定されたPing (RTT) |
ネットワークの状態 |
推奨バッファ(RTT×4) |
期待される視聴体験 |
|---|---|---|---|
20ミリ秒 |
優れた (ローカル/ファイバー) |
80ミリ秒 |
完璧な、ほぼリアルタイムのインタラクション |
50ミリ秒 |
良好 (標準ブロードバンド) |
200ミリ秒 |
スムーズなブロードキャスト、目立たない遅延 |
100ミリ秒 |
普通 (セルラー/4G LTE) |
400ミリ秒 |
安定したストリーム、わずかな会話の遅延 |
250ミリ秒以上 |
悪い (混雑/衛星) |
1000 ミリ秒以上 (1 秒) |
慎重なリモート面接のペース調整が必要 |
ソフトウェア エンコードでは、本質的に非常に予測不可能な処理遅延が発生します。一般消費者のラップトップで基本的なストリーミング ソフトウェアを実行することは、専門家にとって依然として危険です。これにより、コンピュータの CPU はバックグラウンドのオペレーティング システム タスクを絶えず処理するようになります。専用ハードウェアは、完全に予測可能なエンコード時間を継続的に保証します。特定用途向け集積回路 (ASIC) およびフィールド プログラマブル ゲート アレイ (FPGA) チップは、ビデオ フレームを瞬時に処理します。これらは、単一フレームをドロップすることなく、集中的な HEVC ビデオ圧縮を処理します。
ベースバンド入力を特定のライブ制作環境に注意深く合わせる必要があります。標準の HDMI 接続が現在のカメラを簡単に処理できるかどうかを評価します。複雑なブロードキャスト設定では、多くの場合、代わりにプロフェッショナルな SDI 入力が必要になります。 SDI は安全なロック コネクタを提供し、より長いケーブル配線を確実にサポートします。選択したハードウェアが物理的なカメラ出力と正確に一致していることを確認してください。
選択したエンコーディング デバイスは、さまざまなストリーミング ワークフローを簡単に処理できる必要があります。ハードウェアは、メインのポイントツーポイント投稿フィードの SRT を同時に出力する必要があります。 RTMP または HLS も同時に出力する必要があります。これらの二次出力は、ソーシャル配信への即時の直接バックアップとして機能します。一か八かのライブ イベント中に非常に柔軟な運用が可能になります。
パブリック ネットワークの障害により、ライブ ストリーミング イベントが台無しになることがよくあります。ハードウェア エンコーダが高度なネットワーク ボンディングをネイティブにサポートしているかどうかを評価します。複数のセルラー モデム接続をシームレスにインテリジェントに組み合わせる必要があります。また、標準の有線イーサネット接続と並行してセルラー データを結合することもできます。この高度なネットワーク冗長性により、重要なブロードキャスト中の突然の単一ネットワーク接続障害が完全に軽減されます。
SRT は、総伝送遅延を安全かつ確実に大幅に短縮します。 TCP の非効率性を、信じられないほどインテリジェントなパケット回復メカニズムで積極的に置き換えます。堅牢な UDP ベースのフレームワークを完全に利用しています。予測不可能なネットワーク上でも驚異的な配信速度が得られます。視覚的な安定性や放送品質を犠牲にすることはありません。ハードウェア エンコーダは、このプロトコルを利用して、パブリック インターネット ルーティングの制限を回避します。
テクニカルバイヤーは、現在のネットワーク RTT 機能を厳密に監査する必要があります。新しい機器を導入する前に、専用のハードウェア エンコーダを徹底的に評価する必要があります。ネイティブ HEVC サポートを直ちに優先します。発信者モードやリスナー モードなどの柔軟なファイアウォール トラバーサル機能を詳しく見てみましょう。プロの放送設定には、常にハードウェア アクセラレーションによる真の処理能力が求められます。これらの手順を実行すると、回復力があり、レイテンシが低い本番パイプラインが保証されます。
A: いいえ。真の遅延ゼロというのは技術的な神話です。 SRT には、意図的に数学的に計算されたレイテンシー バッファーが必要です。このバッファは通常、安全に数百ミリ秒に及びます。これにより、プロトコルが ARQ 経由で失われたパケットを回復するのに十分な時間が確保されます。このわずかな遅延の後、ビデオ フレームは問題なく表示されます。
A: いいえ。SRT には、非常に特殊なファームウェアまたは専用ハードウェアのサポートが必要です。レガシー デバイスや低価格デバイスは、多くの場合、RTMP プロトコルまたは RTSP プロトコルのみをネイティブにサポートします。専用のエンコーダにアップグレードすると、シームレスな SRT 統合が保証されます。複雑なリモート ブロードキャスト ワークフローの処理安定性が向上します。
A: ハードウェア デバイスは、全体的に比類のない物理的信頼性を提供します。消費電力が大幅に低いことが特徴です。これらは、ビデオ圧縮のために専用の処理チップを明示的に利用します。これにより、OS レベルの遅延とバックグラウンドでのアプリケーションのランダムなクラッシュが完全に排除されます。また、ハードウェア ユニットは、かさばるラップトップよりもはるかに簡単に、プロ仕様のカメラ リグに物理的に統合できます。
A: 最小要件は、選択したビデオ コーデックとブロードキャスト解像度に大きく依存します。 HEVC は古い標準よりもはるかに少ない帯域幅を必要とします。主なベスト プラクティスとして、合計ネットワーク帯域幅をインテリジェントにプロビジョニングします。ターゲットビデオビットレートより少なくとも 15 ～ 20% 高い値にする必要があります。この適切なオーバーヘッドにより、突然の ARQ 再送信に安全に対応できます。
