RTSP（Real Time Streaming Protocol），RFC2326

RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。

RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。

HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。

因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

实时流媒体会话协议,

SDP(会话描述协议)Session Description Protocol

RTP(实时传输协议)Realtime Transfer Protocol：

音视频流是用来控制声音或影像的多媒体串流协议,RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。

媒体数据使用rtp,rtcp协议。

一般使用udp 作为传输层。

适合IPTV场景。

数据源包括现场数据与存储在文件中的数据。

该协议目的在于控制多个数据（音视流或视频流）发送连接，为发送选择通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，比较能容忍网络延迟.

RTSP协议简介

TCP/IP 协议体系中的一个应用层协议，该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。

RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。

HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。

RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。

行以CRLF中断（\r\n:10,13:0x0A,0x0D），包括消息类型、消息头、消息体和消息长。但接收者本身可将CR和LF解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用SDP作为描述语言。

RTSP是应用级协议，控制实时数据的发送。

RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。

RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。

RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。

此外，可使用无连接传输协议，如UDP。

RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。

协议支持的操作如下：

RTSP协议支持

（1）从媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。

（2）媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。

（3）将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。

手撕RTSP

相关学习资料推荐，点击下方链接免费报名，先码住不迷路~】

音视频免费学习地址：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发

【免费分享】音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击788280672加群免费领取~

1.rtsp协议简介

rtsp，英文全称 Real Time Streaming Protocol，RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议！

协议主要规定定了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP体系结位于RTP和RTCP之上（RTCP用于控制传输，RTP用于数据传输），使用TCP或UDP完成数据传输！

2.rtsp基本交互过程

Wireshark抓本机包：

1.以管理员身份运行cmd

2.route add 本机ip mask 255.255.255.255 网关ip

如：route add 192.168.1.9 mask 255.255.255.255 192.168.1.1

3.route delete:

使用完毕后用route delete 192.168.1.9 mask 255.255.255.255 192.168.1.1删除，否则所有本机报文都经过网卡出去走一圈回来很耗性能。

5.配置过滤器：dst host 192.168.1.9

此时再利用wireshark进行抓包便可以抓到本机自己同自己的通信包，这样配置的原因是将发往本机的包发送到网关，而此时wireshark可以捕获到网卡驱动的报文实现抓包。

但这样有一个缺点，那就是本地请求的URL的IP只能写本地的IP地址，不能写localhost或127.0.0.1，写localhost或127.0.0.1还是抓不到包。

route add 192.168.1.9 mask 255.255.255.255 192.168.1.1

route delete 192.168.1.9 mask 255.255.255.255 192.168.1.1

5.ffplay播放：ffplay -i rtsp://192.168.1.9:8554/rtspa200

RTSP交互流程

假设我们现在要向一个RTSP的sever发送请求获取数据，基本流程如下：

1）OPTIONS

Client--->Server

C--->S

客户端向服务器端发现OPTIONS，请求可用的方法。

S--->C

服务器端回复客户端，消息中包含当前可用的方法。

2）DESCRIBE

C--->S

客户端向服务器请求媒体描述文件，一般通过rtsp开头的url来发起请求，格式为sdp。

S--->C

服务器回复客户端sdp文件，该文件告诉客户端服务器有哪些音视频流，有什么属性，如编解码器信息，帧率等。

3）SETUP

为音视频数据的传输准备通道

C--->S

客户端向服务器端发起建立连接请求，请求建立会话连接，准备开始接收音视频数据，请求信息描述了期望音视频数据包基于UDP还是TCP传输，指定了RTP，RTCP端口，以及是单播还是组播等信息！

S--->C

服务器端收到客户端请求后，根据客户端请求的端口号确定发送控制数据的端口以及音视频数据的端口!

4）PLAY

C--->S

客户端向服务端请求播放媒体。

S--->C

服务器回复客户端200 OK! 之后开始通过SETUP中指定的端口开始发送数据！

5）TEARDOWN

C---->S

结束播放的时候，客户端向服务器端发起结束请求

S--->C

服务端收到消息后，向客户端发送200 OK，之后断开连接

上述的流程基本涵盖了RTSP的流程，当然，RTSP除此之外，还有PAUSE，SCALE，GET_PARAMETER，SET_PARAMETER等参数。

ffmpeg -re -i ande10.mp4 -vcodec libx264 -acodec aac -f flv -y rtmp://127.0.0.1:1935/live/test1

rtsp重要概念

集合控制

对多个流的同时控制。对音频/视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。

音视频同步

延迟问题

实体（Entity）

作为请求或者回应的有效负荷传输的信息。

由以实体标题域[头，head]（entity-header field）形式存在的元信息和以实体主体[身体，body]（entity body）形式存在的内容组成。

如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体则由实体头文件和实体体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。

实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。

容器文件（Containerfile）

可以容纳多个媒体流的文件。(mp4,avi,mkv,flv, ts, .....)

Ffmpeg4.3开发系列之二：音视频基础理论

RTSP服务器可以为这些容器文件提供集合控制。

RTSP会话

RTSP交互的全过程(session)。

对一个电影的观看过程,会话（session）包括由客户端建立媒体流传输机制（SETUP），使用播放（PLAY）或录制（RECORD）开始传送流，用停止（TEARDOWN）关闭流。

RTSP协议特点

RTSP协议具有如下特点：

可扩展性：新方法和参数很容易加入RTSP。

易解析：RTSP可由标准HTTP或MIME解析器解析。

安全：RTSP使用网页安全机制。

独立于传输：RTSP可使用不可靠数据报协议（EDP）、可靠数据报协议（RDP）；如要实现应用级可靠，可使用可靠流协议。

多服务器支持：每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。

记录设备控制：协议可控制记录和回放设备。

流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建惟一会议标识号。特殊情况下，可用SIP或H.323来邀请服务器入会。

适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。

演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSP URL。

代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。

HTTP友好：此处，RTSP明智地采用HTTP观念，使现在结构都可重用。结构包括Internet内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。

适当的服务器控制：如用户启动一个流，必须也可以停止一个流。

传输协调：实际处理连续媒体流前，用户可协调传输方法。

性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效。这允许用户提出适合的用户界面。

rtsp协议格式

RTSP中所有的操作都是通过服务器和客户端的消息应答机制完成的，其中消息包括请求和应答两种，RTSP是对称的协议，客户机和服务器都可以发送和回应请求。

RTSP是一个基于文本的协议，它使用UTF -8编码（RFC2279）和ISO10646字符序列，采用RFC882定义的通用消息格式，每个语句行由CRLF结束(\r\n)。

RTSP的消息包括请求和应答两类。

请求消息

请求消息由请求行、标题行中的各种标题域和主体实体组成。

请求行和标题行由ASCⅡ字符组成。

请求消息格式

其中方法包括OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN等。

URL是接接收方的地址，例如:rtsp://192.168.0.1/video.264。

RTSP版本一般都是 RTSP/1.0。

每行后面的CRLF表示回车换行，需要接收端有相应的解析，最后一个消息头需要有两个CRLF。

消息体是可选的，有的请求消息并不带消息体

应答消息

应答消息格式

应答消息格式

RTSP应答消息的格式如右图所示。

其中RTSP版本一般都是RTSP/1.0。

状态码是一个数值，用于表示请求消息的执行结果，比如200表示成功。

短语是与状态码对应的文本解释。 [5]

RTSP消息交互过程

c表示客户端，s表示RTSP服务器端

第一步：查询服务器可用方法

1 c---s ：OPTIONS request //查询s有哪些方法可用

s---c：OPTIONS response //s回应信息的public头字段中提供的所有可用方法

第二步：得到媒体描述信息

2 c--s:describe request //要求得到s提供的媒体描述信息

s---c：describe response //s回应媒体描述信息，一般是sdp信息。

第三步：建立RTSP会话

3 c---s：setup request //通过transport头字段列出可接受的传输选项，建立s建立会话

s---c：setup response //s建立会话，通过transport头字段返回选择的具体传输选项，并返回建立

第四步：请求开始传输数据

4.C->S:PLAY request //C请求S开始发送数据

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

第五步： 数据传送播放中

S->C:发送流媒体数据 // 通过RTP协议传送数据

第六步：关闭会话，退出

6.C->S:TEARDOWN request //C请求关闭会话

6.S->C:TEARDOWN response //S回应该请求

上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。

其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成

原文 FFmpeg入门详解之110：RTSP协议讲解_ffmpeg解码rtsp_福优学苑@音视频+流媒体的博客-CSDN博客