RTSP交互过程
RTSP(Real-Time Streaming Protocol)是一种用于实时流媒体传输的应用层协议。在RTSP通信中,以下是参与的主要角色和组件:
-
客户端(Client):发送请求并接收服务器的响应。客户端可以是一个播放器应用程序或其他支持RTSP协议的设备。
-
服务器(Server):接收来自客户端的请求,并提供相应的流媒体数据。服务器可以是一个流媒体服务器或其他支持RTSP协议的设备。
-
RTSP协议栈:负责处理RTSP协议的各种细节,包括建立连接、发送请求、解析响应等。
-
RTP(Real-time Transport Protocol):用于传输实时流媒体数据的协议。RTSP协议通常与RTP协议一起使用,以便在流媒体传输期间进行数据传输。
-
媒体服务器:存储和管理流媒体文件,并根据RTSP请求提供相应的媒体数据。
-
流媒体编码器/解码器:负责将音频和视频数据进行编码和解码,以便进行流媒体传输。
-
SDP(Session Description Protocol):用于描述会话信息的协议。RTSP通信中,SDP通常用于描述流媒体的参数,如编码格式、传输协议、媒体流地址等。
-
NAT(Network Address Translation):在存在网络地址转换的情况下,处理RTSP通信中的IP地址和端口映射问题。
-
RTCP(Real-Time Control Protocol是用于实时流媒体传输的RTP协议的一个补充协议。它提供了一种用于监测和控制RTP会话质量的机制。尽管在某些情况下RTCP并不是必需的,但在大多数实时流媒体应用中,RTCP是非常有用的。
服务端读取视频文件,客户端进行拉流过程
- 连接到RTSP服务器并发送
OPTIONS
请求以获取支持的方法列表。 - 发送
DESCRIBE
请求以获取媒体资源的描述信息。 - 如果需要进行身份验证,拉流客户端会发送
SETUP
请求以建立安全连接,并提供相关的认证信息。 - 发送
SETUP
请求以建立传输通道,指定使用的传输协议和端口号。 - 发送
PLAY
请求以开始拉取媒体流。 - 如果需要暂停或停止拉流,拉流客户端可以发送
PAUSE
或TEARDOWN
请求。
PLAY
请求发出后,服务端需要创建UDP
连接或者TCP
连接,二者都可以,但是UDP
连接的话需要创建两个,一个用于RTP
包传输,一个用于RTCP
反馈,使用TCP
传输的话,客户端请求RTSP
的Setup
请求时,RTSP
服务器不需要再对应创建RTP
和RTCP
的UDP
连接通道,因为TCP
版的RTP
传输,客户端与服务器交互时,无论是RTSP
信令还是RTP
数据包或者是RTCP
数据包,都是使用同一个tcp
连接通道。只不过这个tcp
连接通道在发送rtp
数据包或者rtcp
数据包时,需要加一些分隔字节。
下面介绍一下RTP
包,他保存的就是视频或者音频的数据了。
/*
* 0 1 2 3
* 7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* |V=2|P|X| CC |M| PT | sequence number |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* | timestamp |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* | synchronization source (SSRC) identifier |
* +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
* | contributing source (CSRC) identifiers |
* : .... :
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
*/
struct RtpHeader
{
/* byte 0 */
uint8_t csrcLen : 4;//CSRC计数器,占4位,指示CSRC 标识符的个数。
uint8_t extension : 1;//占1位,如果X=1,则在RTP报头后跟有一个扩展报头。
uint8_t padding : 1;//填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。
uint8_t version : 2;//RTP协议的版本号,占2位,当前协议版本号为2。
/* byte 1 */
uint8_t payloadType : 7;//有效载荷类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等。
uint8_t marker : 1;//标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。
/* bytes 2,3 */
uint16_t seq;//占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。接收者通过序列号来检测报文丢失情况,重新排序报文,恢复数据。
/* bytes 4-7 */
uint32_t timestamp;//占32位,时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。
/* bytes 8-11 */
uint32_t ssrc;//占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。
/*标准的RTP Header 还可能存在 0-15个特约信源(CSRC)标识符
每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源
*/
};
struct RtpPacket
{
struct RtpHeader rtpHeader;
uint8_t payload[0];
};
RTP(Real-time Transport Protocol)报文是用于实时流媒体传输的协议数据单元(PDU),它负责承载音频、视频或其他实时媒体数据。下面对RTP报文进行详细解释:
- RTP报头(RTP Header):RTP报文以12字节的报头开始,包含了一些重要的元数据信息,如版本号、源标识符、序列号、时间戳等。
- 版本号(Version):占据2个比特,表示RTP协议的版本。
- 填充位(Padding):占据1个比特,如果被设置为1,表示在RTP报文末尾存在额外的填充字节。
- 扩展位(Extension):占据1个比特,如果被设置为1,表示RTP报头后会包含一个扩展部分。
- CSRC计数(CSRC Count):占据4个比特,表示CSRC(Contributing Source)标识符的个数。
- 标记位(Marker):占据1个比特,由应用程序使用,可用于指示关键帧等重要信息。
- 负载类型(Payload Type):占据7个比特,指定RTP载荷的类型,例如音频或视频编码格式。
- 序列号(Sequence Number):占据16个比特,用于标识发送的RTP报文的顺序。
- 时间戳(Timestamp):占据32个比特,用于同步和定时目的,表示报文中第一个字节的采样时刻。
- SSRC(Synchronization Source)标识符:占据32个比特,用于唯一地标识发送RTP报文的源。
-
CSRC列表(CSRC List):如果在RTP报头的CSRC计数字段中指定了非零值,那么后续的CSRC列表将包含对应的CSRC标识符。每个CSRC标识符占据32个比特。
-
RTP扩展头(RTP Extension Header):如果RTP报头的扩展位被设置为1,则RTP报文会包含一个扩展头部。扩展头部提供了额外的自定义元数据信息,如传输速率、帧类型等。
-
RTP载荷(RTP Payload):RTP载荷包含实际的媒体数据,例如音频或视频编码后的数据。其结构和格式由负载类型字段确定,并根据具体的编码标准进行解析和处理。
总而言之,RTP报文是一种用于实时流媒体传输的数据单元,它由报头、CSRC列表、扩展头部和载荷组成。报头包含了一些关键的元数据信息,如版本号、序列号、时间戳等。CSRC列表用于标识参与者的贡献源。扩展头部允许自定义的元数据信息。载荷部分包含实际的媒体数据,其格式由负载类型字段确定,并根据具体的编码标准进行解析和处理。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!