RTSP 上音频和视频的相同媒体格式

Posted 2023-02-14

【中文标题】RTSP 上音频和视频的相同媒体格式

【英文标题】：Same media format for audio and video on RTSP

【发布时间】：2013-02-12 00:42:42

【问题描述】：

我们公司开发了一个摄像头监控软件，我们主要使用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（甚至静态映射，比如 PCMU 的 0），但是这个设备对所有媒体使用相同的映射，所以，我们的解析器不会工作，因为它将使用有效载荷 96 接收的音频数据包识别为视频数据包，并将它们直接发送到视频解码器，当然它不会工作......

我已经检查过 VLC 工作正常，但我坚信 VLC 不使用此映射来拆分数据包，而是使用通道标识（在 TCP 中）或不同的 UDP 端口来识别哪些数据包属于哪个媒体。 ...但是我们已经构建了根据负载类型拆分数据包的架构

所以我问...将音频和视频都映射到相同的动态有效载荷编号（96）是否正确？？？

这是我第一次遇到这个问题，我需要知道我们是否必须更改整个 RTSP 客户端以使用通道而不是 Payload 格式来识别媒体，或者是否存在实现错误相机方面，他们应该将其他有效载荷编号链接到每个不同的媒体（96 个视频、97 个音频、98 个应用程序......）

有谁知道这种做法（对所有媒体使用相同的有效载荷编号）是否有效？？？

我们已经使用 RFC 规范实现了 RTSP 客户端和 SDP 解析器，但我没有发现任何与对所有媒体使用相同有效载荷编号相关的内容，在所有示例中，它们总是为每个媒体分配不同的有效载荷编号...

【参考方案1】：

这是一个非常好的问题。从您发布的 SDP 的语义来看，这台相机似乎正在实现 RFC 2326 中的 RTSP 规范，基于 a=control 字段的存在。

在本规范中，可以观察到每个媒体负载都有一个特定的控制参数，第一个控制语句是a=control:*。从规范的第83页，我觉得音频和视频流可以设置为

audio = rtsp://10.1.39.174:8557/PSIA/Streaming/channels/track2

和

video = rtsp://10.1.39.174:8557/PSIA/Streaming/channels/track1

【参考方案2】：

好问题，范围 96-127 是为动态负载类型定义的，RFC 没有具体说明使用的类型是否应该在多个描述符中是唯一的。当然，如果它们是独一无二的，事情会更清楚。但是他们不必as it seems。没有混合有效负载类型，因为它们都是在其自己的媒体公告下单独定义的，即使用视频 96 和音频 96 看起来是有效的。更不用说如果现实世界的设备以这种方式定义会话，那么 RTSP 客户端应该为此做好准备。

【讨论】：

问题是我已经看到了很多东西，而且我不怀疑这家中国制造商在 RTP 流媒体上存在一些问题......但很高兴知道有效载荷是否必须是在整个公告中是否唯一

RFC 4566 第 5.14 和 6 节说它是“媒体级别属性”，所以我会说这个 SDP 是有效的。

我会说原始 SDP 是有效的。 Media 属性告诉您音频或视频。 'm='

【参考方案3】：

我认为高于 SDP 是有效的。我已经看到媒体类型包含相同的音频和视频媒体通道的有效载荷编号。

几个想法： 1. 看看你是否可以让这台相机只独立流式传输音频或视频。这样，您在技术上可以拥有两个 RTSP 会话（一个用于音频，一个用于视频）；这样你就可以确切地知道什么样的 RTP 流量正在向你走来；并根据该信息使用音频或视频解码器。

如果这对您来说确实是一个很大的提升，请检查传入的 RTP 数据包是否可能没有任何其他额外信息可以让您推断它是音频还是视频通道。