ブラウザ配信アーキテクチャ · 03/20

RTSP ~ HLS レイテンシ: セグメント サイズは 1 つの部分にすぎません

エンコーダー GOP、セグメントの長さ、プレイリストの深さ、CDN の動作、プレーヤー バッファーを使用して HLS 遅延を計画します。

対象となる質問: RTSP から HLS までの遅延研究のチェック済み: 2026-09-11

直接の答え

セグメントを短くすると HLS 遅延を減らすことができますが、カメラのキーフレーム間隔、ゲートウェイ パッケージ化、プレイリスト ポリシー、およびプレーヤー バッファーを調整する必要があります。 セグメントの継続時間をカットする前に完全なパスを測定します。

なぜこれが起こるのか

HLS クライアントは通常、公開されたプレイリストと安全に開始するのに十分なメディアを必要とします。 キーフレームの位置がずれていたり、ライブ ウィンドウが深い場合は、ネットワークが高速であっても、複数の遅延セグメントが追加される可能性があります。

通常、ブラウザにはカメラ フィードを Web ネイティブの配信パスに変換するゲートウェイが必要です。

管理されたテスト

カメラ GOP、セグメントの長さ、プレイリストの長さ、および実際のプレーヤーのライブエッジ距離を記録します。

一度に 1 つの変数を変更します。 カメラのモデル、ファームウェア、エンドポイント、アカウントを記録しておきます。 次に、ネットワーク到達可能性、プロトコル応答、メディアトランスポート、およびデコードを個別のレイヤーとしてテストします。

専用の表示専用アカウントと信頼できるローカル診断ツールを使用します。 出力を共有する前に、資格情報、プライベート アドレス、識別データを編集します。

診断シーケンス

チェックアクション進歩の証拠
エンコーダキーフレームをパッケージ化の目標に合わせます。セグメントは、使用可能なランダム アクセス ポイントで開始できます。
パッケージャーセグメントの作成とプレイリストの公開を測定します。ゲートウェイ遅延は既知です。
配達キャッシュとオリジンの動作を確認します。クライアントは新しいプレイリストとメディアを受け取ります。
プレーヤーライブエッジバッファとリカバリを測定します。起動性と継続性は目標を達成しています。

保管すべき証拠

有用な結果には、定常状態の遅延、起動時間、パケット損失またはゲートウェイの再起動時の動作が含まれます。

境界と安全上の注意

HLS は多くの場合、優れた配布形式ですが、低遅延設計が証明されていない限り、緊密なインタラクティブな制御には最初の選択肢ではありません。

リモート表示の場合は、RTSP またはカメラ管理ポートをパブリック インターネットに直接公開するのではなく、管理された VPN を使用します。

SmartRTSP

SmartRTSP は、Apple デバイス、Windows、Android 用のカメラに焦点を当てた RTSP および ONVIF ビューアです。 直接表示、発見、マルチカメラのチェックに適しています。 継続的な記録、証拠のエクスポート、または企業の集中管理が必要な場合は、専用の NVR または VMS を用意してください。

よくある質問

1 秒のセグメントでは 1 秒の遅延が発生しますか?

必ずしもそうではありません。 プレイリストとプレーヤーのバッファリングにより、いくつかのセグメントの継続時間が追加される場合があります。

なぜキーフレームが重要なのでしょうか?

クライアントが正常に起動または切り替えするには、ランダム アクセス ポイントが必要です。

すべての視聴者がカメラに接続する必要がありますか?

いいえ。ゲートウェイは、カメラ セッションの制限が保護されるように、パッケージ化された出力をファンアウトする必要があります。

一次参考文献

関連する SmartRTSP ガイド

関連ガイドを開く

エンコーダー GOP、セグメントの長さ、プレイリストの深さ、CDN の動作、プレーヤー バッファーを使用して HLS 遅延を計画します。