RTSP は接続するがビデオが表示されない: プレーヤーを責める前に何を調べるべきか

最も一般的なカメラ サポート チケットの 1 つは単純に思えます。RTSP URL は接続し、認証は成功しますが、ビューアにはビデオが表示されません。他のプレイヤーを試してみるのが自然な本能です。これは便利ですが、ストリームは RTSP 制御、SDP ネゴシエーション、RTP 配信、またはコーデックの準備で失敗しましたか?というエンジニアリング上の質問には答えていません。

CCTV インテグレーター、VMS エンジニア、カメラ ベンダーにとって、この区別は重要です。プレーヤーは、パケット損失を隠したり、古いデコーダー状態を再利用したり、トランスポート モードをサイレントに再試行したりできます。診断レポートでは、ストリームのどの部分が正常であることが証明され、どの部分が正常でないかを説明する必要があります。

コントロールの成功とメディアの成功を分離する

RTSP は制御プロトコルです。 DESCRIBE、SETUP、および PLAY シーケンスが成功すると、カメラがセッションを受け入れたことを証明します。 RTP パケットが到着したことを証明するものではありません。また、ペイロードが実際に SDP によって宣伝されている形式の H.264 または H.265 であることも証明されません。

役立つ最初のパスの記録は次のとおりです。

• OPTIONS、DESCRIBE、SETUP、および PLAY の RTSP ステータス コード
• SDP ボディにビデオ メディア セクションが含まれるかどうか
• ビデオトラック用にネゴシエートされたペイロードタイプ
• RTP パケットが「PLAY」後に到着するかどうか
• RTP タイムスタンプとシーケンス番号が前進するかどうか
• 最初のビデオ ペイロードにコーデック パラメータの証拠が含まれているかどうか

制御は成功しても RTP が到着しない場合、問題は通常、トランスポート、ファイアウォール、NAT、カメラ モード、またはサーバー側ストリームの可用性です。 RTP が到着してもデコード可能なビデオがない場合、問題はペイロード、パケット化、またはコーデック メタデータに移ります。

SDP が第一証拠境界である理由

SDP は、カメラが送信すると主張するものをクライアントに伝えます。 H.264 の場合、エンジニアはパケット化モード、profile-level-id、および sprop-parameter-sets などの「rtpmap」および「fmtp」の値を探します。 H.265 の場合、SDP は VPS、SPS、および PPS 情報を異なる方法で伝送する可能性があり、多くの消費者にはより厳しいサポート制限が設けられています。

SDP に H.264 と記載されているが、メディア バイトに予期される NAL ユニット構造が含まれていない場合、その障害は一般的な「プレーヤーの問題」ではありません。これは、宣伝されたメタデータと実際のペイロードとの間の不一致です。 SDP がパラメータ セットを省略し、RTP ストリームがパラメータ セットを帯域内で送信しない場合、デコーダは永久に待機する可能性があります。

そのため、RTSP 検査ワークフローでは、SDP をプレーヤー ログに埋め込まず、メディア証拠の横に保持する必要があります。

RTP 到着だけでは十分ではありません

RTP パケットが到着した場合でも、ビデオが失敗する可能性があります。 H.264 および H.265 フレームは、多くの場合、以前のパケットに依存します。パケットが欠落していると、次のスライスがデコード不能になる可能性があります。順序どおりでない配信は破損のように見える場合があります。 GOP の途中で開始されるペイロードは、次のキー フレームとパラメータ セットが表示されるまでデコードの準備が整わない場合があります。

収集する最低限の証拠は次のとおりです。

• RTPシーケンスの連続性
• タイムスタンプの進行
• マーカービットの動作
• ペイロードタイプの一貫性
• H.264 または H.265 NAL ユニット カテゴリ
• SPS、PPS、および H.265 VPS の可視性
• 最初のキーフレームの準備完了

これは、「VLC が再生する」と「分析パイプラインがそれを拒否する」が両方とも真実である理由を説明しています。積極的に回復する視聴者もいます。エンジニアリング システムには多くの場合、標準に準拠したクリーンな証拠が必要です。

TCP と UDP は診断上の選択です

RTSP トランスポートを UDP から TCP に切り替えることは一般的なトラブルシューティング手順ですが、これを万能薬として扱うべきではありません。 TCP インターリーブにより、ブロックされた UDP ポートを回避し、ネットワーク ポリシーによって引き起こされるパケット損失を軽減できます。また、展開の意図した UDP パスが機能するかどうかを隠すこともできます。

優れたフィールドレポートには両方の試みが記録されます。

• RTSP over TCP インターリーブ: メディアは到着しますか?
• RTP over UDP ユニキャスト: パケットはネゴシエートされたポートに到着しますか?
• RTCP: 送信者のフィードバックにはタイミングとパケット数が表示されますか?

TCP が機能し、UDP が失敗する場合、その答えはおそらくコーデックのサポートではありません。おそらく、ネットワーク パス、ファイアウォール、NAT、またはポート割り当てです。両方のトランスポートが RTP を配信してもデコードが失敗する場合は、コーデック構造を調べてください。

RTSP インスペクターが適している場所

RTSP Inspector は、この正確な境界に合わせて構築されています。ビデオプレーヤーやNVRになろうとしているわけではありません。 RTSP セッション、SDP、RTP/RTCP フロー、H.264/H.265 の準備状況に関する証拠が収集されるため、エンジニアは「接続済み」が「使用可能なビデオ」にならなかった理由を説明できます。

有用な出力は、黒いプレーヤー ウィンドウのスクリーンショットではありません。それは繰り返し可能な答えです:

• RTSP制御に成功しました
• SDP はこのコーデックとペイロード タイプをアドバタイズしました
• RTP が到着した、または到着しなかった
• パケットシーケンスが連続しているか壊れている
• コーデック パラメータの証拠が存在するか欠落していました
• 次のアクションはネットワーク、カメラ設定、ファームウェア、またはストリーム コンシューマに属します

それが、ストリームを見ることと診断することの違いです。