プライマリ ストリームの RTP エラー修正: RTSP のパケット損失、カメラ フリーズ、およびマクロブロックを診断する

IP カメラ ストリームがフリーズしたり、途切れたり、H.264 デコーダ エラーが発生したりする場合、目に見える症状は通常、遅れて現れます。多くの場合、原因は RTP シーケンスの早い段階で現れます。 RTP パケットが欠落すると、後のフレームが依存するビデオ データのスライスが削除される可能性があります。プレーヤーがデコード エラーを記録するまでに、ネットワーク上の証拠はすでに失われている可能性があります。

そのため、RTP のトラブルシューティングは、ランダムなカメラ設定を変更する前に、シーケンス番号、タイムスタンプ、ペイロード タイプ、マーカーの動作、コーデック構造から開始する必要があります。

RTP シーケンス ギャップからわかること

各 RTP パケットにはシーケンス番号が含まれています。安定したストリームの場合、シーケンスは予測どおりに進むはずです。ギャップは、1 つ以上のパケットが到着しなかったことを意味します。逆方向ジャンプは、並べ替え、重複配信、再起動動作、またはキャプチャ境界の問題を示している可能性があります。

実際的な質問は次のとおりです。

• 何個のパケットが不足していましたか?
• 損失は​​一度だけ発生しましたか、それとも繰り返し発生しましたか?
• キーフレームの近くで発生しましたか?
• RTCP 送信者レポートは継続されましたか?
• RTSP コントロール セッションは生きたままですか?
• デコーダーの障害はギャップの後に発生しましたか?

この証拠により、ネットワーク損失とカメラ ペイロードのバグを区別できます。シーケンスのギャップが視覚的な破損と一致する場合、その可能性はさらに高くなります。シーケンスの連続性は完璧だが、ペイロードの形式が正しくない場合、診断はエンコーダまたはパケット化の動作に進みます。

H.264 と H.265 が損失に敏感な理由

圧縮ビデオは独立した画像のリストではありません。インターフレームは参照フレームに依存します。小さなパケット損失は、直接のパケット以上の損害を与える可能性があります。 H.264 および H.265 ストリームは、SPS や PPS などのパラメータ セットに依存する場合もあり、H.265 には VPS が追加されます。これらが欠落していたり​​、遅延していたり​​、破損していたり​​すると、耐性のあるビューアが回復したように見えても、ダウンストリーム ソフトウェアがストリームを拒否する可能性があります。

一般的な症状は次のとおりです。

• マクロブロックまたはブロック状のアーティファクト
• フリーズとその後の突然の追いつき
• 「参照がありません」スタイル デコーダ エラー
• ストリームは開始しますが、デコード準備が整ったフレームがありません
• 動きの多いシーンの後に繰り返される破損

これらの症状だけでは十分ではありません。 RTP とコーデックの証拠により、実用的なものになります。

ジッターと損失を混同しないでください

ジッターとは、パケットが不均一なタイミングで到着することを意味します。損失とは、パケットが到着しないことを意味します。どちらもユーザーに見える途切れを引き起こす可能性がありますが、それぞれ異なる修正が必要です。

ジッターについては、タイムスタンプの進行と到着タイミングを検査します。損失がないか、シーケンスのギャップを検査します。カメラのファームウェアのバグについては、ペイロードの一貫性と NAL 構造を検査します。 「ストリームが途切れている」というだけのフィールドレポートでは、ネットワークエンジニア、ファームウェアエンジニア、または VMS ベンダーに何を変更する必要があるかがわかりません。

より良いレポートには次のように書かれています。

• N から N+M への RTP シーケンス ギャップ
• 同じ時点でタイムスタンプのジャンプが観察されました
• RTSPセッションは確立されたままです
• ペイロードタイプは安定したまま
• H.264 スライスが不完全でした
• 次の IDR フレームはデコーダの準備状態を復元しました

それははるかに強力なサポートアーティファクトです。

UDP と TCP は異なるストーリーを伝えます

RTSP は通常、UDP またはインターリーブ TCP を介して RTP を転送します。 UDP はパケット損失を直接公開します。 TCP はブロックされた UDP パスを消去できますが、遅延が発生する可能性があり、意図した展開パスが正常であることを証明するものではありません。

診断のために、両方のモードを比較します。

• UDP はシーケンス ギャップにより失敗します。ネットワーク損失、スイッチ、Wi-Fi、ファイアウォール、NAT、またはカメラの送信動作を検査します。
• UDP は RTP を受信しません。ネゴシエートされたポートとファイアウォール ポリシーを検査します。
• TCP は機能しますが、UDP は失敗します。コーデックではなくネットワーク パスが疑われます。
• どちらのモードでも、不正な形式のペイロードが表示されます。疑わしいカメラ エンコーダ、ストリーム プロファイル、またはファームウェアです。

トランスポートの選択は、単なるプレーヤーのチェックボックスではなく、証拠となります。

RTSP Inspector が問題をどのように捉えるか

RTSP Inspector は、再生ではなくプロトコルの証拠に焦点を当てます。 RTSP、RTP、RTCP、およびコーデックの観察をキャプチャするため、サポート ケースを再生して説明できます。同じストリームが VLC、FFmpeg、NVR、クラウド取り込みサービス、分析パイプラインで異なる動作をする場合、これは重要です。

目標は、すべてのストリームをローカルで修正できると主張することではありません。目標は、障害の所有者を特定することです。

• ネットワークパス
• カメラ構成
• ファームウェアのパケット化
• ダウンストリーム デコーダのサポート
• サポートされていないコーデック境界
• 予想される UDP/TCP 導入の不一致

RTP 損失はビデオだけの症状ではありません。これは測定可能なプロトコル イベントです。測定が完了すると、トラブルシューティングの会話は大幅に短くなります。