RTSP RTP RTCP SDP基础知识

理论

        流(Streaming 是近年在 Internet 上出现的新概念,其定义非常广泛,主要是指通过网络传输多媒体数据的技术总称。
流式传输分为两种
  1.  顺序流式传输  (Progressive Streaming)
  2.  实时流式传输  (Real time Streaming)

​​​​​实时流式传输是实时传送,特别适合现场事件。“实时”是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系,这需要相应的协议支持,这样RTP和RTCP就相应的出现了。

1.什么是RTSP RTP RTCP SDP?

        实时流传输协议(RTSP:Real Time Streaming Protocol)是⼀种⽹络传输协议,旨在发送低延迟流。 该协议由RealNetworks,Netscape和哥伦⽐亚⼤学的专家在1996年开发。它定义了应如何打包流中的数据以进⾏传输。RTSP 用于创建和控制流媒体服务器上的多媒体会话。比如多媒体流播放、暂停、快进和快退。
        

        RTSP 常用于视频会议、视频监控、远程教学和视频点播等场景。它与RTP(实时传输协议)和RTCP(实时传输控制协议)一起工作,其中:

  1. RTP 负责传输多媒体数据(如音频和视频)。 服务器默认端口号5004
  2. RTCP 提供传输质量反馈和媒体同步。             默认端口号默认为5005
  3. RTSP负责服务器与客户端之间的请求与响应      默认端口是554

        网络体系

   SDP

        描述可以被用于建立 H.264 视频流的 RTP 传输会话。接收端可以根据这些信息来正确地解码和渲染视频内容.

1. 媒体类型
   - 通常使用 `m=video` 来标识视频媒体流。
2. 传输协议和负载类型
   - 通常使用 `RTP/AVP` 协议,并指定一个有效负载类型(Payload Type)。
3. 时间基准
   - 使用 `a=rtpmap` 属性指定时间基准,如 `a=rtpmap:96 H264/90000`。
4. H.264 编码配置
   - 使用a=fmtp属性指定 H.264 的配置参数,如:
     - `profile-level-id`: 用十六进制表示的profile和level。
     - `packetization-mode`: 分片模式,通常为1(非交错模式)。
     - `sprop-parameter-sets`: Base64 编码的SPS和PPS数据。
5. 传输地址
   - 使用 `c=IN IP4 <ip-address>` 属性指定传输地址。

m=video 55002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4d0028; packetization-mode=1; \
sprop-parameter-sets=Z2QAKeKQCgC3YC3Af0I=,aM46gA==
c=IN IP4 192.168.1.100



packetization-mode: 
当 packetization-mode 的值为 0 时或不存在时, 必须使用单一 NALU 单元模式.
当 packetization-mode 的值为 1 时必须使用非交错(non-interleaved)封包模式.
当 packetization-mode 的值为 2 时必须使用交错(interleaved)封包模式.

sprop-parameter-sets: SPS,PPS
这个参数可以用于传输 H.264 的序列参数集和图像参数 NAL 单元. 
这个参数的值采用 Base64 进行编码. 不同的参数集间用","号隔开.

profile-level-id:
这个参数用于指示 H.264 流的 profile 类型和级别. 由 Base16(十六进制) 表示的 3 个字节.
 第一个字节表示 H.264 的 Profile 类型, 第三个字节表示 H.264 的 Profile 级别

max-mbps: 
这个参数的值是一个整型, 指出了每一秒最大的宏块处理速度.

        RTSP 运行在TCP或UDP之上,通常使用TCP来建立控制连接,而使用UDP来传输实际的媒体数据。它允许客户端请求实时数据流的播放、录制和广播,并且可以控制播放过程中的各种参数。在以tcp传输音频或视频时RTP RTCP使用统一音频或视频端口,在以udp传输 音频rtp和rtcp 以及视频rtp和rtcp都有独立的端口。

        

 小总结

rtsp承载与rtp和rtcp之上,rtsp并不会发送媒体数据,而是使用rtp协议传输,rtcp质量控制,sdp用于ICE媒体和网络协商,为了正确的输出音视频数据。

rtp并没有规定发送方式,可以选择udp发送或者tcp发送

使用udp传输数据端rtcp/rtp端口随机分布。

rtp协议封装

        rtp负责对流媒体数据进行封包并实现媒体流的实时传输,即它按照RPT数据包格式来封装流媒体数据,并利用与它绑定的协议进行数据包的传输。

        RTP报⽂由两部分组成:报头和有效载荷12 个字节 RTP报头格式如下:
V:RTP协议的版本号,占2位,当前协议版本号为2。
P:填充标志,占1位,如果P=1,则在该报⽂的尾部填充⼀个或多个额外的⼋位组,用于包对齐,它们不是有效载荷的⼀部分。
X:扩展报头,占1位,如果X=1,则在RTP报头后跟有⼀个扩展报头。
CC:CSRC计数器,占4位,指示CSRC 标识符的个数。

M: 最后一个分片位,占1位

  1. 对于视频数据,标记位通常用来指示一帧视频数据的结束。这可以帮助接收端确定何时完成了一帧数据的接收,从而可以进行解码和显示。

  2. 对于音频数据,标记位可能用来指示会话的开始或结束,或者一个逻辑流的开始。

PT: 有效载荷类型,占7位,⽤于说明RTP报⽂中有效载荷的类型,如GSM⾳频、JPEM图像等。

序列号 sequence:占16位,⽤于标识发送者所发送的RTP报⽂的序列号,每发送⼀个报⽂,序列号增1。接收者通过序列号来检测报⽂丢失情况,重新排序报⽂,恢复数据。需注意使用udp接收乱序时,应该设计一个重排机制。

时戳(Timestamp):占32位,时戳反映了该RTP报⽂的第⼀个⼋位组的采样时刻。接收者使⽤时戳来计算延迟和延迟抖动,并进⾏同步控制。需注意单位 如果是90khz 则1/90000 * 1000 = 0.0111s

同步信源(SSRC)标识符:占32位,⽤于标识同步信源。该标识符是随机的,参加同⼀视频会议的两个同步信源不能有相同的SSRC。
特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报⽂有效载荷中的所有特约信源。

SSRC和CSRC详细介绍

SSRC 同步信源是指产⽣媒体流的信源,例如⻨克⻛、摄像机、RTP混合器等。它通过RTP报头中的⼀个32位数字SSRC标识符来标识,⽽不依赖于⽹络地址,接收者将根据SSRC标识符来区分不同的信源,进⾏RTP报⽂的分组。
CSRC特约信源是指当混合器接收到⼀个或多个同步信源的RTP报⽂后,经过混合处理产⽣⼀个新的组合RTP报⽂,并把混合器作为组合RTP报⽂的SSRC,⽽将原来所有的SSRC都作为CSRC传送给接收者,使接收者知道组成组合报⽂的各个SSRC。

SSRC (Synchronization Source)

1. SSRC是一个32位的随机值,用于标识每个RTP数据流的来源。
2. 每个参与RTP会话的终端都会分配一个唯一的SSRC值。可用于识别和区分不同的数据流。
3. SSRC值可能会在会话过程中发生变化,例如当终端重新加入会话时。

CSRC (Contributing Source)

1. CSRC用于标识参与混音的数据流。
2. 当一个RTP数据包包含来自多个源的混音音频数据时,该数据包的CSRC列表中会包含所有贡献源的SSRC值。接收端可以根据CSRC列表来确定哪些数据源参与了当前数据包的混音。
3. CSRC列表的长度可以在0到15之间变化。

小结:

SSRC和CSRC在RTP协议中的作用如下:

SSRC用于唯一标识每个数据流源,便于接收端进行同步和恢复。
CSRC用于标识参与混音的数据流源,便于接收端进行正确的音频混合和渲染。

这两个标识符确保了RTP会话中各数据流的独立性和可识别性,是RTP协议实现多路复用和同步的关键机制。

CSRC(Contributing Source Identifier)是通过RTP数据包头中的CC(CSRC Count)字段来携带的。例如,如果 CC 字段的值为 2,那么 CSRC 列表中就会有 2 个 32 位的 CSRC 标识符,代表有两个数据源参与了当前数据包的混合。

RTSP交互流程

推流(左图Clinet右图Server)

1.通过OPTION 查询服务器端可⽤⽅法 S返回可用命令表

2.ANNOUNCE 发送媒体描述信息,在此确定了rtpmap96开始 是以音频还是视频。S回应媒体描述信息,并返回了Session ID。

3.SETUP建⽴RTSP会话通过Transport头字段列出可接受的传输选项,请求S建⽴会话。流媒体通道id和c端端口。S通过Transport头字段返回选择的具体转输选项,并返回建⽴的Session ID;以及ssrc 同步。C->SRTP: 31590 -> 59472RTCP: 31591 -> 59473

4.RECORD请求传送数据npt时间戳。S回应该允许的信息

5.RTP数据推送SSRC 就是在setup返回来的SSRC。

6.TEARDOWN关闭会话.S回应该请求

拉流

与推流不同之处:

第⼆步:DESCRIBE得到媒体描述信息。S回应媒体描述信息,⼀般是sdp信息

第四步:PLAY请求开始传送数据。S回应该请求的信息,npt=起始时间 不一定是0.00

 如何确定流id和传输协议? sdp阶段如下:

⼩总结

推流拉流区别
第⼆步    推流:ANNOUNCE; 拉流:DESCRIBE
第四步:推流:RECORD;拉流:PLAY

第五步 :发送方和接收方

opt支持命令                                     why:拉流和推流命令不同
describe(
ANNOUNCE )              音视频流配置信息 sdp
stepup(
RECORD)                       确定传输地址和端口。 
play                                                   开始推流 

SDP协议

SDP 协议是一种会话描述协议,主要用于描述多媒体会话的各种参数,如媒体类型、编码格式、传输地址和端口等。它是 RTSP 协议的一部分,两者通常配合使用。

SDP 协议的主要作用有:

  1. 会话参数描述

    • 描述会话的名称、时间、带宽等基本参数
    • 描述会话中包含的媒体流,如音频、视频等
  2. 媒体参数描述

    • 描述每个媒体流的编码格式、传输协议、传输地址和端口等
    • 这些参数对接收端初始化和设置播放非常重要
  3. 网络传输参数描述

    • 描述 RTP/RTCP 使用的传输参数,如 SSRC、时间戳单位等
    • 这些参数对于媒体同步和质量控制很关键

SDP协议格式

SDP描述由许多⽂本⾏组成,⽂本⾏的格式为<类型>=<值>,<类型>是⼀个字⺟,<值>是结构化的⽂本串.

SDP的结构

SDP仅仅提供了对会话的描述,没有提供将会话和可能的参与者联系起来的⽅法,需要使⽤特定的编码集。字段名称只能使⽤US-ASCII字符集,⽂本信息可以使⽤任何语⾔。由于SDP的ASCII编码⽐⼆进制编码占⽤ 带宽多,所以SDP采⽤紧凑格式提⾼带宽利⽤率。如v=version,s=session name等等。字段名只⽤⼀个字符表示(⼤⼩写敏感),字段值可以有多个信息块组成,⽤分号隔开,“=”左右不能有空格。

SDP语法

根据sdp结构可知 开始是会话级随后媒体流的描述。第⼀个媒体描述 字段(m=)的出现,之后的每个媒体描述字段的出现标志着这个会话中⼜⼀个媒体流数据的开始。

必需字段

v=(协议版本号),⼀个会话描述的开始,前⼀个会话结束标志。
o=(会话源或者会话⽣成者,以及会话标识符)
s=(会话名称)这个字段是个⽂本字符串,可以显示给会话参与者。
t=(会话时间)这个字段指明会话开始时间与结束时间。
m=(媒体)该字段⽤来指明媒体类型、数据应该发送到的传输端⼝,传输协议(例如RTP)以及媒体格式(例如RTP负载格式)

可选字段

SDP可选字段中,⼀些只能应⽤于会话级,⼀些只能应⽤于媒体级,还有⼀些可以应⽤于两种级别。

可选字段如下:
i=(会话信息)对字段的⽂本描述,提供了⽐会话名称更多的信息。该字段既可以⽤于会话级也可以⽤
于媒体级。
u=(描述的URI地址)URI信息,通过这个地址可以获取更多会话相关信息。例如,⼀个会议可能公布
在WEB⻚⾯上,所以需要该WEB的URI。每个会话只能提供⼀个URI
E=(E-mail地址)负责会话个体的E-mail地址,可以有多个。只能⽤于会话级别。
p=(电话号码)同email⼀样,多个,会话级别。
c=(连接信息)该字段提供连接数据,包括连接类型、⽹络类型和连接地址。可应⽤于会话级也可以⽤于媒体级。
b=(带宽信息)指明带宽需求,单位kbit/s, 可⽤于两个级别
r=(重复次数)如果是有规律的⽇程安排活动,这个字段⽤来指明会话重复频次和时间。
z=(时区调整)⽤于按⽇程安排的有规律活动会话。会话可能会夸时区,避免时区变更造成的混乱。
k=(加密密钥)为了对媒体加密、解密,该字段提供了⼀个加密密钥或者规定了⼀个获取密钥的机制。
可⽤于两个级别。
a=(属性)⽤于描述会话或者某个媒体的额外属性。

 

字段顺序

举例:

会话级
协议版本号(v)
会话源(o)
会话名称(s)
会话信息(i)(可选)
URI(u)(可选)
E-mail地址(e)(可选)
电话号码(p)(可选)
连接信息(c)(可选)
带宽信息(b)(可选)
时间描述(t)
重复信息(r)(可选)
时区调整(z)(可选)
加密密钥(k)(可选)
属性(a)(可选)

媒体级
媒体描述(m)
媒体信息(i)(可选)
连接信息(c)(会话级进⾏了规定,这⾥可选)
带宽信息(b)(可选)
加密密钥(k)(可选)

属性(a)(可选)

⼦字段

 在SDP中许多字段采⽤多个⼦字段的形式,此时,这些字段值由多个以空格符间隔的多个值组成。格式如 下:

字段名称=<⼦字段1的值> <⼦字段2的值> <⼦字段3的值>

媒体信息(m)有四个⼦字段:媒体类型、端⼝、传输协议、格式。
格式: m=(媒体)(端⼝)(传送层)(格式列表)
媒体类型:⾳频(audio),视频(video),应⽤,数据和控制
端⼝:媒体传送层端⼝
传送层:ip4上⼤多基于rtp/udp上传送(RTP/AVP)IETF RTP协议,在udp上传输
格式列表: 对应对应的⾳频负载类型(PT)

举例:
m=video 0 RTP/AVP 96

a属性⾏

格式:
a=rtpmap:(净荷类型)(编码名)/(时钟速率)【/(编码参数)】
a=control:(⾳/视频连接信息)
a=control:rtsp://192.168.1.197/h264stream0/trackID=0
a=rtpmap:96 H264/90000
属性有两种形式,第⼀种是特征属性,第⼆种属于值属性。SDP描述了多个建议属性。
例如a=sendonly  表明会话描述的发送者只希望发送数据⽽不打算接收数据,端⼝号⽆意义,可以置为0。

rtpmap属性提供了⼀个在VoIP应⽤中的重要属性使⽤⽅法,该属性可⽤于媒体流,在媒体格式不是静态的 RTP负载类型时特别有⽤。 严格来说,“rtpmap”只在使⽤动态负载类型情况下才是必须的,例如标准的G.711语⾳是静态RTP负载类 型,采⽤如下⽅法就可以对它完整描述: m=audio 45678 RTP/AVP 0

对动态负载来说需要指定更多信息才能使远端完全识别到媒体编码,例如16位线性编码16kHz取样的⽴ 体声⾳就是⼀个动态RTP负载类型,如果我们采⽤动态负载类型98表示这个媒体流,那么SDP格式如下:

m=audio 45678 RTP/AVP 0

a=rtpmap 98 L16/16000/2

大家可以抓包分析,有什么不懂的字段格式再去网上查。

RTCP协议

        Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP)是实时传输协议 (RTP)的⼀个姐妹协议。RTCP由RFC 3550定义(取代作废的RFC 1889)。RTP 使⽤⼀个 偶数 UDP port ;⽽RTCP 则使⽤ RTP 的下⼀个 port,也就是⼀个奇数 port。RTCP与RTP联合⼯作,RTP实施实 际数据的传输,RTCP则负责将控制包送⾄电话中的每个⼈。其主要功能是就RTP正在提供的服务质量做出 反馈。

RTCP报⽂封装在UDP中进⾏传输,作⽤如下:
质量反馈
传输层标识(CNAME)
给参与者发送RTCP控制报⽂
最⼩会话控制消息(可选)
RTCP端⼝号 = RTP端⼝号 + 1

 RTCP报⽂格式--报⽂类型

 在RTP的规范(RFC 3550)中,⼀共定义了5种RTCP报告⽤来报告当前控制信息:

PacketType值     分组类型                 描述
*200             SR(Sender report)             发送者报告,包含发送者的统计信息。
*201             RR(Receiver report)          接收者报告,包含接收者的统计信息。

202              SDES(Source description)     源描述报告,包含关于发送者的各种描述信息。
203              BYE(Goodbye)                 离开会话标识,表示某个参与者退出了会话。
204              APP(Application-defined)     应用定义的报文,用于扩展 RTCP 的功能。

 RTCP的5种报告:RR,SR,SDES,BYE和APP。他们使⽤共同的结构,但是在某些具体的地⽅有⼀些不同。本文主要对200和201做出解析

以下是RTCP报⽂基本结构:

typedef struct _rtcp_header_t
{
    uint32_t v:2; // version
    uint32_t p:1; // padding
    uint32_t rc:5; // reception report count
    uint32_t pt:8; // packet type
    uint32_t length:16; /* pkt len in words, w/o this word */
} rtcp_header_t;

Version (V) 	2bit : RTCP 协议版本号,目前为 2。
Padding (P) 	1bit : 如果为 1,表示包尾有填充字节。
Item count(IC) 5bit : 有些RTCP分组类型包含多个条⽬(item)
,IC⽤来计算有多少个条⽬。因为IC只有5个⽐特,所以最多31个item。
如果需要的item超过31个,那么应⽤实现必须包含多个RTCP分组。
如果IC为0表示空的item列表。分组如果不需要item列表,那么可以把IC字段⽤于其他⽬的。

Packettype(PT) 8bit :**PT标识了分组中携带消息的类型**。在RTP标准中定义了
5种类型:RR,SR,SDES,BYE和APP。
Length(M) 	   16bit :**分组⻓度,以4 bytes为单位,所以意味着RTCP分组必须
是4字节对⻬。该⻓度不包含32 bites固定头,也就是说length为0也是合理的,
说明只有4字节的头部(这种情况IC也是0)**。

**header size = 2 + 1 + 5 +8 + 16 = 4个字节**

RTCP报⽂格式-- SR报⽂格式

RTP协议还规定了最近发送数据的参与者发送SR,该报告提供了发送的媒体的⼀些 信息。主要⽤于接收端同步多媒体流,如语⾳和视频流。

SR 包,总共28字节 = header 4字节 +  4字节 * 6

RTCP报⽂格式-- RR报⽂格式

RTCP通过RR可以很好地保证传输质量,每个接收数据的参与者都要发出RR。

其中PT定义为201。接收者报告包含发送者的SSRC,跟随在由RC指定的(0个或多个)报告 块之后。

Extended highest sequence number received: 接收方收到的最高序号的 RTP 包。
Interarrival jitter: 接收到的 RTP 包的到达时间抖动。
Last SR (LSR): 上次收到的发送者报告(SR)的时间戳。
Delay since last SR (DLSR): 从上次收到 SR 报告到现在的时间延迟。

typedef struct _rtcp_rr_t // receiver report
{
	uint32_t ssrc;
} rtcp_rr_t;
typedef struct _rtcp_rb_t // report block
{
    uint32_t ssrc;
    uint32_t fraction:8; // fraction lost
    uint32_t cumulative:24; // cumulative number of packets lost
    uint32_t exthsn; // extended highest sequence number received
    uint32_t jitter; // interarrival jitter
    uint32_t lsr; // last SR
    uint32_t dlsr; // delay since last SR
} rtcp_rb_t;

丢包率计算:表示⽅式:分⺟固定为256,分⼦是loss fraction表示的整数。所以如果想要表示1/4的报⽂丢失,那么loss fraction=64。

丢包数量计算:cumulative number of packets lost不是以每个周期为计算范围,⽽是以整个会话为计算范围。所以0x7fffff是cumulative number of packets lost的最⼤值,因为它是带符号整数。

扩展⾼位序列号:随着会话时间增⻓,16⽐特⻓度的序列号可能会不够⽤,当序列号⼜回到初始化序列号时,为了表示这个环绕,在⾼16⽐特记录环绕的次数,也就是把序列号扩展了。

总结

       RTSP 是一种专门用于控制流媒体传输的网络协议,与 RTP(传输)/RTCP(质量控制) 和 SDP (session以及流媒体信息等等)协议一起构成了流媒体传输的核心技术。 

参考

音视频同步!RTCP 协议解析及代码实现_rtcp功能的含义和作用-优快云博客

SDP协议详细总结-优快云博客

实时流协议---RTSP【详解】-优快云博客

学习资料分享

0voice · GitHub

03-08
### Real-time Transport Protocol (RTP) Overview #### Purpose and Functionality The Real-time Transport Protocol (RTP) serves as the primary protocol for delivering audio and video over IP networks. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as interactive voice or video conferences. It offers several key features including payload type identification, sequence numbering, timestamping, and delivery monitoring[^1]. #### Data Transmission Mechanism In conjunction with RTSP servers which manage control operations like play, pause, and rewind, RTP handles actual media stream transmission typically via UDP due to its lower latency compared to TCP. This setup ensures efficient handling of time-sensitive multimedia content where timely delivery outweighs error-free transmission. #### Quality Control through RTCP To maintain quality during streaming sessions, RTP works alongside RTCP (RTP Control Protocol). When employing profiles like RTP/AVPF, additional feedback mechanisms become available; these include Negative Acknowledgements (NACK), Picture Loss Indication (PLI), Full Intra Request (FIR), among others. Such messages inform senders about reception status so they can promptly respond accordingly[^2]. For instance, reduced-size RTCP packets may also be utilized under specific conditions but are restricted from regular reporting duties depending on the profile being used[^3]. #### Session Description Integration An example scenario illustrating how RTP integrates into session descriptions involves specifying ports within SDP attributes. An entity might declare willingness to accept incoming streams directed at particular addresses while expecting associated control traffic on adjacent ports[^4]: ```plaintext m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ``` This configuration directs media towards port `49170` whereas related RTCP reports would target `49171`. #### Synchronization Sources Identification For accurate synchronization across multiple streams originating from different sources yet partaking in unified presentations—such as layered coding schemes involving scalable bitrates—the concept of SSRC plays a crucial role. Depending upon whether Single Stream Rollover Timestamp (SRST), Multiple Streams Same Timestamp (MSST), Multi-Rate Single-Timestamp (MRST), or Multi-Rate Multiple Timestamp (MRMT) strategies apply, varying numbers of unique identifiers will represent individual components constituting composite transmissions[^5].
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值