RTSP メインストリームは動作しないが、サブストリームは動作する: その違いが証明するもの

非常に一般的な IP カメラの検索クエリは、「RTSP メイン ストリームは動作しないが、サブストリームは動作する」です。症状が具体的であるため、役に立ちます。サブ ストリームが機能している場合は、カメラにアクセスでき、資格情報がおそらく正しく、RTSP サービスが有効で、少なくとも 1 つのビデオ プロファイルにアクセスできます。問題は「RTSP が壊れている」ということではなくなりました。問題はストリームプロファイルの違いです。

通常、メイン ストリームとサブ ストリームは、解像度、ビットレート、コーデック、GOP 間隔、ペイロード サイズが異なり、場合によっては URL パスも異なります。サブ ストリームは低解像度の H.264 ですが、メイン ストリームは H.265、4K、高ビットレート、またはより少ない同時セッションに制限されている場合があります。 NVR は、カメラ自体からのさまざまなパスを公開できます。 ONVIF は低品質のライブ URL を返す場合がありますが、録画 URL またはメイン プロファイルには別のパスが必要です。

診断に役立つ質問は、動作しているサブストリームが何を証明し、何を証明しないのかということです。

動作するサブストリームが証明するもの

サブストリームを RTSP 経由で開くことができる場合、通常は次のように言えます。

• カメラのIPアドレスが到達可能である
• RTSPポートが開いています
• 認証は少なくとも 1 つのストリームに対して機能します
• クライアントは基本的な RTSP 応答を解析できます
• DESCRIBE、SETUP、および PLAY は少なくとも 1 つのプロファイルに対して成功することができます
• 少なくとも 1 つのメディア トラックについては RTP 配信が可能です

それは貴重な証拠だ。検索を絞り込みます。メイン ストリームが別のホスト、ポート、トランスポート モード、または NVR パスを使用しない限り、この時点以降、基本的なネットワーク到達可能性のデバッグを続行しないでください。

機能するサブストリームが証明できないこと

動作するサブストリームは次のことを証明しません。

• メインストリームの URL パスは正しいです
• メインストリームが有効になっています
• メインストリームコーデックがサポートされています
• メインストリームのビットレートはネットワークを越えることができます
• メインストリームは複数のクライアントが利用できます
• メインストリームは、デコード可能な SPS/PPS または VPS/SPS/PPS 証拠を送信します。
• NVR は同じパスを通じてカメラのメインストリームを公開します

これが、メイン ストリームを必要とする VMS、分析システム、またはリストリーミング パイプラインにとって「VLC がサブ ストリームを開くことができる」だけでは十分ではない理由です。

コーデックの前に URL パスを確認する

多くのカメラ ファミリは、メイン ストリームとサブ ストリームに異なるパス パターンを使用します。 profile1 と profile2 を使用するものもあります。 /Streaming/Channels/101 および /Streaming/Channels/102 を使用するものもあります。 main、sub、video1、video2、またはベンダー固有のアクセス名を使用するものもあります。一部の NVR は、直接カメラ URL とは異なる方法でチャンネルを公開します。

メインストリームが「404 Not Found」を返した場合は、以下を検査してください。

• DESCRIBE で送信された正確なリクエスト URI
• URL パスがベンダー モデルと一致するかどうか
• チャンネル番号
• ストリーム番号
• ONVIF によって検出されたプロファイル トークン
• カメラ Web UI でストリームが有効になっているかどうか
• URL がカメラ IP または NVR IP をターゲットにしているかどうか

404 をパケット損失として扱わないでください。 RTP はまだ開始されていません。

パスが有効になったらコーデックとビットレートを確認します

メイン ストリームが SDP を返し、RTP を開始してもビデオが表示されない場合は、コーデックとメディアの証拠に進みます。

メインストリームの障害は、次のような原因で発生することがよくあります。

• 消費者は H.264 を期待しているのに、H.265 が選択される
• H.264 SPS/PPS または H.265 VPS/SPS/PPS の証拠がありません
• 非常に長いキーフレーム間隔
• Wi-Fi または弱いアップリンクでの高いビットレート損失
• 移動中のパケットの断片化と損失
• デコーダ プロファイルまたはレベルがダウンストリーム システムでサポートされていません

この段階では、レポートには SDP、ペイロード タイプ、RTP シーケンスの連続性、コーデック NAL ユニットの証拠、および最初のデコード境界に到達したかどうかを含める必要があります。

同時実行制限と NVR の動作

一部の低価格 DVR、NVR、またはカメラ ファームウェア ビルドでは、メイン ストリーム アクセスが制限されています。メイン ストリームがローカル ディスプレイ、録画、ベンダー アプリ、または別のクライアントによってすでに消費されている間、サブ ストリームは利用可能なままである場合があります。これは、パスが正しい場合でも URL の問題のように見えることがあります。

便利なチェック:

• 他の視聴者の接続を解除する
• 直接カメラ IP と NVR IP をテストする
• カメラ Web UI からメインストリームを比較
• メインストリームのビットレートまたは解像度が低い
• メインストリーム コーデックを H.265 から H.264 に切り替える
• インターリーブされた TCP 経由の RTSP と UDP を個別にテストする

ビットレートを下げることで問題が解決する場合、元の障害は URL 構文ではなく転送容量にある可能性があります。

RTSP Inspector がこのケースをどのように組み立てるべきか

RTSP Inspector は、境界を説明する場合に最も強力です。

• サブストリーム制御パスは成功します
• メインストリーム制御パスがステータスコードで失敗する
• メインストリームは SDP を返しますが、RTP は返しません
• メインストリーム RTP がパケット損失を伴って到着する
• メイン ストリーム コーデックのメタデータが欠落しているかサポートされていません
• 主流は H.265 ですが、消費者は H.264 を必要としています

それが、「メインストリームが壊れた」ことと有用なサポートレポートの違いです。正しい次のアクションは、ベンダー URL の検索、ストリーム プロファイルの構成、コーデックの変更、ビットレートの削減、ファームウェアの更新、またはネットワーク パスの修復である可能性があります。

「RTSP サブストリームは機能するが、メインストリームは機能しない」という検索が正確である場合は、RTSP メソッド、SDP、コーデック、トランスポート、および同時実行性を比較することから始めます。作業中のサブストリームが診断の終わりではありません。コントロールサンプルです。