【音视频开发】:RTSP服务器协议内容

一、什么是RTSP协议

RTSP是一个实时传输流协议,是一个应用层的协议。通常说的RTSP包括RTSP协议、RTP协议、RTCP协议。

  • RTSP协议:负责服务器与客户端之间的请求与相应
  • RTP协议 :负责服务器与客户端之间传输媒体数据
  • RTCP协议:负责提供有关RTP传输指令的反馈,就是确保RTP传输的质量

    三者关系:RTSP并不会发送媒体数据,只是完成服务器和客户端之间的交互。
    RTP协议负责媒体数据传输,RTCP负责RTP数据包的监视和反馈。RTP和RTCP并没有规定传输层的类型,可以选择UDP或者TCP。RTSP的传输层则是TCP。

二、协议分析

RTSP常用的方法包括:OPTIONS、DESCRIBE、ANNOUNCE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER等。

方法 方向 是否必须 含义
OPTIONS C->S 查询服务器支持的方法和协议选项,帮助客户端了解服务器的能力和限制,以便进行后续的实时流传输控制。
DESCRIBE C->S 客户端可以获取到媒体流的详细信息,例如媒体类型、编解码格式、传输协议等,以便为后续的播放或者录制操作做准备。
SETUP C->S 用于建立媒体传输的通道。客户端和服务器可以就媒体流的传输进行协商,并最终确定有效的传输通道,为后续的播放或者录制操作做准备。
PLAY C->S 客户端告知服务器可以开始传输媒体流数据,服务器收到PLAY请求后即可开始向客户端发送实时的媒体流数据,实现实时的音视频播放。当多个PLAY请求到达时,服务器会将PLAY请求排成队列,顺序执行,即必须等待第一个PLAY的时间完成后,才会继续处理第二个PLAY消息。
。。。 。。。 。。。 。。。

简单的RTSP交互过程:

C表示RTSP客户端,S表示RTSP服务端
1.C->S:OPTIONS request //询问S有哪些方法可用
1.S->C:OPTIONS response //S回应信息中包括提供的所有可用方法

2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息
2.S->C:DESCRIBE response //S回应媒体初始化描述信息,主要是sdp

3.C->S:SETUP request //设置会话的属性,以及传输模式,提醒S建立会话
3.S->C:SETUP response //S建立会话,返回会话标识符,以及会话相关信息

4.C->S:PLAY request //C请求播放
4.S->C:PLAY response //S回应该请求的信息

S->C:发送流媒体数据
5.C->S:TEARDOWN request //C请求关闭会话
5.S->C:TEARDOWN response //S回应该请求

在这里插入图片描述

连接信息交流过程(rbuf为客户端发送信息 , sbuf为服务器发送信息)

accept client;client ip : xxx.xxx.xxx.xxx,client port:62922
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = OPTIONS rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
CSeq: 1
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Public: OPTIONS, DESCRIBE, SETUP, PLAY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = DESCRIBE rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Content-Base: rtsp://xxx.xxx.xxx.xxx:8554
Content-type: application/sdp
Content-length: 128
v=0
o=- 91710247606 1 IN IP4 xxx.xxx.xxx.xxx
t=0 0
a=control:*
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:track0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = SETUP rtsp://xxx.xxx.xxx.xxx:8554/track0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10150-10151
CSeq: 3
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Transport: RTP/AVP;unicast;client_port=10150-10151;server_port=55532-55533
Session: 66334873
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = PLAY rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf60.13.100
Session: 66334873
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Range: npt=0.000-
Session: 66334873; timeout=10
start play
client ip:xxx.xxx.xxx.xxx
client port:10150

三、RTPHeader分析


  *    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报文有效载荷中的所有特约信源

   */
};

相关推荐

  1. 从零开始写一个RTSP服务器(二)RTSP协议的实现

    2024-03-14 10:22:01       18 阅读

最近更新

  1. TCP协议是安全的吗?

    2024-03-14 10:22:01       19 阅读
  2. 阿里云服务器执行yum,一直下载docker-ce-stable失败

    2024-03-14 10:22:01       19 阅读
  3. 【Python教程】压缩PDF文件大小

    2024-03-14 10:22:01       19 阅读
  4. 通过文章id递归查询所有评论(xml)

    2024-03-14 10:22:01       20 阅读

热门阅读

  1. Apache Spark 的基本概念和在大数据分析中的应用

    2024-03-14 10:22:01       25 阅读
  2. 项目使用jdk17启动报错

    2024-03-14 10:22:01       25 阅读
  3. 原型和原型链的区别,__proto__和prototype的区别

    2024-03-14 10:22:01       20 阅读
  4. Go语言的自给自足:编译自身的神奇之旅

    2024-03-14 10:22:01       27 阅读
  5. 【Docker】Tensorflow 容器化部署

    2024-03-14 10:22:01       20 阅读
  6. 预取和缓存替换介绍--自用

    2024-03-14 10:22:01       19 阅读
  7. 【WEEK2】学习目标及总结【SpringMVC】【中文版】

    2024-03-14 10:22:01       22 阅读
  8. Spring MVC InternalResourceViewResolver原理解析

    2024-03-14 10:22:01       23 阅读
  9. Goland运行go语言基础篇

    2024-03-14 10:22:01       21 阅读
  10. 面试经典150题(108-110)

    2024-03-14 10:22:01       17 阅读
  11. python使用rabbitmq发送消息和接收消息数据

    2024-03-14 10:22:01       22 阅读
  12. 【Leetcode】top 100 矩阵

    2024-03-14 10:22:01       17 阅读
  13. Vuex和Pinia

    2024-03-14 10:22:01       19 阅读