音视频流媒体开发-目录
iOS知识点-目录
Android-目录
Flutter-目录
数据结构与算法-目录
uni-pp-目录
FFmpeg源码对应⽬录
rtsp.c 是总⼊⼝，推流拉流都是该⽂件
rtspenc.c：推流的时候使⽤
rtspdec.c：拉流的时候使⽤
RTSP协议概述
RTSP 很详细的英⽂⽂档
https://blog.csdn.net/u012519333/article/details/52746375
RTSP(Real-Time Stream Protocol )是⼀种基于⽂本的应⽤层协议，在语法及⼀些消息参数等⽅⾯，RTSP协议与HTTP协议类似。
RTSP被⽤于建⽴的控制媒体流的传输，它为多媒体服务扮演“⽹络远程控制”的⻆⾊。尽管有时可以把RTSP控制信息和媒体数据流交织在⼀起传送，但⼀般情况RTSP本身并不⽤于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。
⼀次基本的RTSP操作过程是:⾸先，客户端连接到流服务器并发送⼀个RTSP描述命令（DESCRIBE）。流服务器通过⼀个SDP描述来进⾏反馈，反馈信息包括流数量、媒体类型等信息。客户端再分析该SDP描述，并为会话中的每⼀个流发送⼀个RTSP建⽴命令(SETUP)，RTSP建⽴命令告诉服务器客户端⽤于接收媒体数据的端⼝。流媒体连接建⽴完成后，客户端发送⼀个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送⼀个终⽌命令(TERADOWN)来结束流媒体会话
RTSP协议与HTTP协议区别
- RTSP引⼊了⼏种新的⽅法，⽐如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp 1.0,HTTP为http 1.1；
- HTTP是⽆状态的协议，⽽RTSP为每个会话保持状态 session的概念；
- RTSP协议的客户端和服务器端都可以发送Request请求，⽽在HTTPF 协议中，只有客户端能发送Request请求。
- 在RTSP协议中，载荷数据⼀般是通过带外⽅式来传送的(除了交织的情况)，及通过RTP协议在不同的通道中来传送载荷数据。⽽HTTP协议的载荷数据都是通过带内⽅式传送的，⽐如请求的⽹⻚数据是在回应的消息体中携带的。
- 使⽤ISO 10646(UTF-8) ⽽不是ISO 8859-1，以配合当前HTML的国际化；
- RTSP使⽤URI请求时包含绝对URI。⽽由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放⼊单独的标题域中；
推流过程
推流详细过程
第⼀步：OPTION 查询服务器端可⽤⽅法
- C->S:OPTION request //询问S有哪些⽅法可⽤
1.S->C:OPTION response //S回应信息的public头字段中包括提供的所有可⽤⽅法
第⼆步：ANNOUNCE 发送媒体描述信息
2.C->S:ANNOUNCE request //客户端发送媒体描述信息给服务器
2.S->C:ANNOUNCE response //S回应媒体描述信息，并返回了Session ID
第三步：SETUP建⽴RTSP会话
3.1C->S:SETUP request //通过Transport头字段列出可接受的传输选项，请求S建⽴会话
[图片上传失败...(image-ad531f-1690263750915)]
image.png
RTP:31590 RTCP:31591
3.1 S->C:SETUP response //S建⽴会话，通过Transport头字段返回选择的具体转输选项，并返回建⽴的Session ID;
C->S
RTP: 31590 -> 59472
RTCP: 31591 -> 59473
3.2 C->S:SETUP request //通过Transport头字段列出可接受的传输选项，请求S建⽴会话
3.2 S->C:SETUP response //S建⽴会话，通过Transport头字段返回选择的具体转输选项
第四步：RECORD请求传送数据
4.C->S:RECORD request //C向S请求发送数据
4.S->C:RECORD response //S回应该允许的信息
第五步： RTP数据推送
C->S:发送流媒体数据 // 通过RTP协议传送数据
视频
⾳频
还有⼀些RTCP的包，这⾥先不表，都是client->server
第六步：TEARDOWN关闭会话，退出
6.C->S:TEARDOWN request //C请求关闭会话
6.S->C:TEARDOWN response //S回应该请求
总结
拉流过程
拉流详细过程
第⼀步：查询服务器端可⽤⽅法
1.C->S:OPTION request //询问S有哪些⽅法可⽤
1.S->C:OPTION response //S回应信息的public头字段中包括提供的所有可⽤⽅法
第⼆步：DESCRIBE得到媒体描述信息
2.C->S:DESCRIBE request //要求得到S提供的媒体描述信息
2.S->C:DESCRIBE response //S回应媒体描述信息，⼀般是sdp信息
第三步：SETUP建⽴RTSP会话
3.1 C->S:SETUP request //通过Transport头字段列出可接受的传输选项，请求S建⽴会话
3.1 S->C:SETUP response //S建⽴会话，通过Transport头字段返回选择的具体转输选项
3.2 C->S:SETUP request //通过Transport头字段列出可接受的传输选项，请求S建⽴会话
3.2 S->C:SETUP response //S建⽴会话，通过Transport头字段返回选择的具体转输选项
第四步：PLAY请求开始传送数据
4.C->S:PLAY request //C请求S开始发送数据
4.S->C:PLAYresponse //S回应该请求的信息
可能流已经播放了⼀段时间，npt=起始时间
第五步： RTP数据传送播放中
S->C:发送流媒体数据 // 通过RTP协议传送数据
视频 这⾥的ssrc 来⾃服务器
SSRC 就是在setup返回来的SSRC。
⾳频 这⾥的ssrc 来⾃服务器
第六步：TEARDOWN关闭会话，退出
6.C->S:TEARDOWN request //C请求关闭会话
6.S->C:TEARDOWN response //S回应该请求
⼩总结：
推流拉流
第⼀步 option是⼀样的
第⼆步 有区别，推流：ANNOUNCE； 拉流：DESCRIBE
第三步： SETUP
第四步：推流：RECORD；拉流：PLAY
第五步：RTP传输，只是⽅向刚好相反
第六步：TEARDOWN
提问
- SSRC由谁来定义，是client还是server？
推流是客户端⾃⼰定义的
拉流的时候是服务器发送过来的 - session id由谁⽽来
推流来⾃server，当C->S ANNOUNCE后，server reply时附带session id -
Transport字段的意义，⽐如
- rtptime有什么作⽤
- rtp的时间戳问题
- 如何做⾳视频同步
- npt是什么
总结
上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不⼀定按此过程。其中第三和第四步是必需的！第⼀步，只要服务器客户端约定好，有哪些⽅法可⽤，则option请求可以不要。第⼆步，如果我们有其他途径得到媒体初始化描述信息（⽐如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。
RTSP服务器默认端⼝是554，在客户端SETUP的时候会把⾃身的RTP和RTCP端⼝告知服务器。在RTSP的session建⽴后，会使⽤RTP/RTCP在约定好的端⼝上传输数据。
1.Accept:
⽤于指定客户端可以接受的媒体描述信息类型。
⽐如:
Accept: application/rtsl, application/sdp;level=2
2.Bandwidth:
⽤于描述客户端可⽤的带宽值。
3.CSeq：
指定了RTSP请求回应对的序列号，在每个请求或回应中都必须包括这个头字段。对每个包含⼀个给定序列号的请求消息，都会有⼀个相同序列号的回应消息。
4.Rang：
⽤于指定⼀个时间范围，可以使⽤SMPTE、NTP或clock时间单元。
5.Session:
Session头字段标识了⼀个RTSP会话。Session ID是由服务器在SETUP的回应中选择的，客户端⼀当得到Session ID后，在以后的对Session的操作请求消息中都要包含Session ID。
6.Transport:
Transport头字段包含客户端可以接受的传输选项列表，包括传输协议，地址端⼝，TTL等。服务器端也通
过这个头字段返回实际选择的具体选项。如:
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
网友评论