当社はカメラ監視ソフトウェアを開発しており、主にデバイスとの通信にRTSPを使用しています（ただし、必要なプロトコルはすべてサポートしています）。独自のRTSPクライアントとパーサーを開発しました。
今日、私たちは新しいカメラの統合に取り組んでおり、カメラが動的ペイロード96をオーディオパケットとビデオパケットの両方にマッピングする興味深いシナリオを見つけました。SDPの説明を参照してください。
RTSP/1.0 200 OK
CSeq: 2
Date: Sat, Jan 01 2000 19:39:38 GMT
Content-Base: rtsp://10.1.39.174:8557/PSIA/Streaming/channels/2?videoCodecType=H.264/
Content-Type: application/sdp
Content-Length: 830
v=0
o=- 946754247689123 1 IN IP4 10.1.39.174
s=RTSP/RTP stream from IPNC
i=2?videoCodecType=H.264
t=0 0
a=tool:LIVE555 Streaming Media v2010.07.29
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:RTSP/RTP stream from IPNC
a=x-qt-text-inf:2?videoCodecType=H.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:4000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter- sets=Z2QAKK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQCgC3YCqQAAAMABAAAAwJZgQAB6EgAAiVQve+F4RCNQAAAAAE=,aO48sA==
a=control:track1
m=audio 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:128
a=rtpmap:96 PCMU/16000
a=control:track2
m=application 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:64
a=rtpmap:96 vnd.onvif.metadata/90000
a=control:track3
ご覧のように：
m=video 0 RTP/AVP 96
m=audio 0 RTP/AVP 96
問題は、このマッピングを使用して、受信したRTPパケットからの圧縮を識別することです。ビデオの場合は96、オーディオの場合は97など、メディアごとに異なるマッピングがあると常に思っていましたが、このデバイスはすべてのメディアに同じマッピングを使用するため、パーサーは使用しません。ペイロード96で受信されているオーディオパケットをビデオパケットとして識別し、それらをビデオデコーダに直接送信するため、機能します。もちろん、機能しません。
VLCが正常に機能することを確認しましたが、VLCはこのマッピングを使用してパケットを分割するのではなく、チャネルID（TCPの場合）またはさまざまなUDPポートを使用して、パケットがどのメディアに属しているかを識別します。ただし、ペイロードタイプに応じてパケットを分割するアーキテクチャはすでに構築されています
だから私は尋ねます...オーディオとビデオの両方を同じ動的ペイロード番号（96）にマッピングするのは正しいですか？
この問題に遭遇したのはこれが初めてであり、ペイロード形式の代わりにチャネルを使用してメディアを識別するためにRTSPクライアント全体を変更する必要があるかどうか、またはカメラ側に実装のバグがあるかどうかを知る必要があります。他のペイロード番号をそれぞれの異なるメディア（96ビデオ、97オーディオ、98アプリケーション...）にリンクする必要があります。
そのような慣行（すべてのメディアに同じペイロード番号を使用）が有効かどうか誰かが知っていますか？
RFC仕様を使用してRTSPクライアントとSDPパーサーを実装しましたが、すべてのメディアに同じペイロード番号を使用することに関連するものは見つかりませんでした。すべての例で、メディアごとに異なるペイロード番号が常に割り当てられます...