ffmpeg抓取rtsp流并保存_详细解析RTSP框架和数据包分析(1)

0.引言

本文主要讲解RTSP框架和抓取RTSP数据包，进行详细分析。可以阅读以下几篇文章，能够帮助你更详细理解。

手把手搭建RTSP流媒体服务器

HLS实战之Wireshark抓包分析

HTTP实战之Wireshark抓包分析

1.RTSP协议简述

RTSP：Real Time Streaming Protocol是⼀种实时⽹络流传输协议，旨在发送低延迟流。该协议由RealNetworks，Netscape和哥伦⽐亚⼤学的专家在1996年开发。它定义了应如何打包流中的数据以进⾏传输。

其实 TCP/IP 协议体系中的一个应用层协议，该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。

RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。行以CRLF中断，包括消息类型、消息头、消息体和消息长。但接收者本身可将CR和LF解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用SDP作为描述语言。

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

RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但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添加方法。

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

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

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

关于更详细的描述，可以参考如下链接:

https://baike.baidu.com/item/RTSP/1276768?fromtitle=RTSP%E5%8D%8F%E8%AE%AE&fromid=3361755&fr=aladdin

个人觉得RTSP协议相比RTMP协议，更加的复杂。

RTSP协议家族由RTSP部分，RTP部分，RTCP部分，SDP部分组成。RTSP(应用层)也是一个控制命令协议，能够播放、暂停、停止码流。音视频数据不走RTSP协议。RTP是负责音视频的数据发送，RTP(传输层)即可以基于TCP(可能会有点延时，丢包会重传)，也可以基于UDP(实时性更好，丢包不会重传)。RTCP(应用层)是对RTP进行控制同步机制。SDP(应用层)是描述多媒体会话，如包含音视频的编解码信息，源地址信息，时间信息等。RTSP整个协议系统如下图:

注意:这里的RTP实际也是应用层，只是在该协议系统中的位置是传输层。只是所处的位置不一样。

2.RTSP家族协议框架

音视频数据是通过RTP协议传输数据，控制部分主要是由RTCP和RTSP协议部分，其中RTCP与RTP是有一定关系，控制部分的RTSP是基于TCP协议，RTCP与RTP既可以走TCP传输，也可以走UDP传输。也就是RTSP协议系统涉及多组传输通道，这与RTMP协议的出入还是很大，RTSP会更加复杂。

注意:SDP是封装在控制部分的RTSP去传输，并不是单独的。并且RTSP部分和SDP部分，只能基于TCP去传输，切记！

3.推流端使用TCP方式，Wireshark抓取RTSP协议数据包

关于RTSP流媒体服务器环境搭建，可以参考上面一篇文章。手把手搭建RTSP流媒体服务器

通过Wireshark抓包，获取数据和控制协议部分。

(1)首先运行ZLMediakit流媒体服务器

(2)然后开启rtsp推流，拉流。

(3)推流命令，先选择TCP的方式传输。

ffmpeg -re -i source.200kbps.768x320.flv -vcodec h264 -acodec aac -f rtsp -rtsp_transport tcp rtsp://172.16.204.139/live/test

(4)运行Wireshark

注意:网卡一定要选择对，我这里选择如下网卡。

(5)设置过滤器，在窗口输入命令:

rtsp or rtp or rtcp

如下界面:

(6)通过wireshark抓包工具，可以更清楚的看看这个协议的组成。如下界面；

注意:下面看到的OPTIONS、Reply、ANNOUNCE都是信令，

(7)第一个包是通过RTSP协议，客户端发给服务端，数据如下:

(8)第二个包是通过RTSP协议，服务端发给客户端，数据如下:

(9)第三个包是通过RTSP和SDP协议，客户端发给服务端，数据如下:

通过抓包数据可以看到，这里SDP协议专用于传输文本。

注意:这里的RTSP和SDP都是用的统一端口号，默认是554。

(10)第四个包是通过RTSP协议，服务端发给客户端，数据如下:

(11)第五个包是通过RTSP协议，客户端发给服务端，数据如下:

(12)第六个包是通过RTSP协议，服务端发给客户端，数据如下:

(13)第七个包是通过RTSP协议，客户端发给服务端，数据如下:

(14)第八个包是通过RTSP协议，服务端发给客户端，数据如下:

(15)第九个包是通过RTSP协议，客户端发给服务端，数据如下:

(16)第十个包是通过RTSP协议，服务端发给客户端，数据如下:

(17)第十一个包是通过RTCP协议，客户端发给服务端，数据如下:

注意:RTCP协议也是通过端口号554发送。

(18)从第十二个包开始，后面就是一直通过RTP协议发送音视频数据，中间会有RTCP协议从客户端到服务端去发送“Sender Report”。如下界面:

通过查看数据含义可以看出，这里的"96"表示H264，如下:

通过查看数据含义可以看出，这里的"97"表示AAC，如下:

注意:RTP协议发送真正的音视频数据默认也是通过端口号554发送。

(19)当客户端终止推流时，也会向服务器上发送，终止命令"TEARDOWN"。如下界面:

4.推流端使用udp方式，Wireshark抓取RTSP协议数据包

ffmpeg -re -i source.200kbps.768x320.flv -vcodec h264 -acodec aac -f rtsp -rtsp_transport udp rtsp://172.16.204.139/live/test

注意:下面看到的OPTIONS、Reply、ANNOUNCE、SETUP、RECORD都是信令。

(1)第一个包是通过RTSP协议，客户端发给服务端，数据如下:

这里的RTSP端口号(RTSP协议部分始终是基于tcp)，还是使用的554。

(2)第二个包是通过RTSP协议，服务端发给客户端，数据如下:

(3)第三个包是通过RTSP/SDP协议，客户端发给服务端，数据如下:

这里的RTSP/SDP协议还是使用的同一端口号554。

发送SDP信息(音视频文本描述信息)很重要，推流客户端会把码流相关的信息告诉服务端，比如这里的SPS信息，这个是很重要的，这样服务端就可以很清楚知道客户端码流的基本信息。如下界面:

(4)第四个包是通过RTSP协议，服务端发给客户端，数据如下:

(5)第五个包是通过RTSP/SDP协议，客户端发给服务端，数据如下:

(6)第六个包是通过RTSP协议，服务端发给客户端，数据如下:

这里服务器回复客户端，设置了视频传输的专用端口号。

(7)第七个包是通过RTSP协议，客户端发给服务端，数据如下:

(8)第八个包是通过RTSP协议，服务端发给客户端，数据如下:

这里服务器回复客户端，设置了音频传输的专用端口号。

(9)第九个包是通过RTSP协议，客户端发给服务端，数据如下:

(10)第十个包是通过RTSP协议，服务端发给客户端，数据如下:

从数据来看，回复的是一些流地址信息。

(11)第十一个包是通过RTSP协议，客户端发给服务端，数据如下:

(12)从第十一个包以后，就会发送音频和视频数据了，推流端设置的UDP方式，就会影响这里的RTP和RTCP的方式，即通过UDP传输。

(13)这时候可以看到RTCP使用的就是UDP协议传输，端口号使用的是40451。

(14)这时候可以看到RTCP使用的就是UDP协议传输，视频传输端口号使用的是40450。

(15)这时候可以看到RTCP使用的就是UDP协议传输，音频传输端口号使用的是55034。

(16)这时候可以看到RTCP使用的就是UDP协议传输，在音视频中间传输的还有使用RTCP协议，这里使用的端口号为55035。

(17)客户端首先发送“SETUP”给服务端，服务端回应“Reply”给客户端，并指定了端口号40450，专用于视频传输。

(18)客户端紧接着又发送“SETUP”给服务端，服务端回应“Reply”给客户端，并指定了端口号55034，专用于音频传输。

综上所述，在基于udp协议传输的时候，RTP和RTCP通道端口号都是独立。而且RTP对于audio、video也是独立，RTCP对于audio、video也是独立。同时也可以得出，设置的推流基于UDP协议，仅仅是针对RTP和RTCP，不针对RTSP部分，因为RTSP部分依然还是TCP。这是一定要记住的。

使用udp会使用很多端口号，这是与基于TCP协议很大的不同地方。

5.总结

本文重点讲解了RTSP家族协议的组成和框架，并通过抓包更详细的分析了每个协议的数据，能够让大家更清楚的认识RTSP家族协议每个部分的功能。通过设置TCP和UDP两种不同的推流方式，抓取数据包，能够理解推流客户端与服务端之间的数据关系。希望能够帮助到大家。欢迎关注，转发，点赞，收藏，分享，评论区讨论。

后期关于项目的知识，会在微信公众号上更新，如果想要学习项目，可以关注微信公众号“记录世界 from antonio”