Fatal编程技术网
  • h.264/
  • H.264 RTSP上音频和视频的媒体格式相同

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

H.264 RTSP上音频和视频的媒体格式相同,h.264,rtsp,rtp,mpeg-4,sdp,H.264,Rtsp,Rtp,Mpeg 4,Sdp,我们公司开发了一个摄像头监控软件，我们主要使用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

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

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

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

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

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

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

好问题，96-127范围是为动态有效负载类型定义的，RFC不是特定的她使用的类型应该在多个描述符中都是唯一的。当然，如果它们是唯一的，事情会更清楚。但是，它们不一定是唯一的。不存在负载类型的混合，因为它们都是在其自己的媒体公告下单独定义的，即视频96和音频96的使用看起来是有效的。更不用说，如果真实世界中设备以这种方式定义会话，那么RTSP客户端应该准备好了。我认为上面的SDP是有效的。我看到媒体类型包括音频和视频媒体频道的相同有效负载号

两个想法： 1.查看您是否可以要求此摄像头仅独立地流式传输音频或视频。这样，从技术上讲，您可以有两个RTSP会话（一个用于音频，一个用于视频）；这样，您就可以确切地知道什么样的RTP通信正在向您走来；并根据这些信息使用音频或视频解码器

  • 如果这对你来说是一个很大的提升，检查传入的RTP数据包是否没有任何其他额外的信息，可以让你推断它是音频还是视频频道
    • 这是一个非常好的问题。从您发布的SDP的语义来看，基于
    a=control
    字段的存在，该摄像头似乎正在实现
    RTSP
    规范

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

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

    问题是，我已经看到了很多东西，我不怀疑这家中国制造商在RTP流媒体方面存在一些问题……但如果知道有效负载在整个公告中必须是唯一的，或者RFC 4566第5.14节和第6节说它是“媒体级属性”，那就太好了，因此我会说此SDP有效。我会说原始SDP有效。媒体属性告诉您音频或视频。'm='0 
    video = rtsp://10.1.39.174:8557/PSIA/Streaming/channels/track1