FFmpeg 4.3 音视频-多路H265监控录放C++开发二十一.1，RTSP协议-RTSP协议概述,详情，使用VLC搭建RTSP服务器，使用开源项目ZLMediakit 搭建RTSP服务器。

前提0：

RTSP 指是的 RTSP协议，RTP协议，RTCP协议，SDP协议 的四者的和。

一个知识点：RTSP 指是的 RTSP协议，RTP协议，RTCP协议，SDP协议 的四者的和。这四个协议一般一起使用，才能构架成一个完整的RTSP应用。具体的说明和连接如下

RTSP协议：负责客户端和服务器端的请求和响应；RTSP协议详情。

FFmpeg 4.3 音视频-多路H265监控录放C++开发二十一，RTSP协议-RTSP协议概述，协议详情，使用VLC搭建RTSP服务器，使用开源项目ZLMediakit 搭建RTSP服务器。-CSDN博客

RTP协议：负责客户端和服务器端之间传递媒体数据；RTP协议详情。FFmpeg 4.3 音视频-多路H265监控录放C++开发二十一.2，RTP协议-RTP协议概述，协议详情-CSDN博客

RTCP协议：负责提供有关RTP传输质量的反馈，就是确保RTP传输的质量。例如可以监视RTP协议发送的数据的内容是否丢失或者重复。 RTCP协议详情。

FFmpeg 4.3 音视频-多路H265监控录放C++开发二十一.3，RTCP协议, RTCP协议概述，RTCP协议详情-CSDN博客

四 者的关系

RTSP并不会发送发送媒体数据，只是完成服务器和客户端之间的信令交互；

完成交互后，RTP负责媒体数据传输

RTCP 负责RTP 数据包的监视和反馈。

rtsp规定传输层必须是tcp; rtp 和 rtcp并没有规定传输层的类型，传输层可以是tcp或者udp。

额外的说明：关于流媒体相关的协议的大致介绍和说明

RTMP、RTSP、RTP、HLS、MPEG-DASH协议的简介，以及应用场景-CSDN博客

前提1：为什么要学习 RTSP 协议？Real Time Streaming Protocol

RTSP协议在如下的音视频应用的场景下都能用到。

1.视频监控系统，

• RTSP在视频监控系统中扮演着重要角色。通过RTSP，监控摄像头可以将实时视频流传输到监控中心或客户端，实现远程监控和实时查看。这种应用常见于城市安防、企事业单位、交通监控等场景。
• 优势：RTSP提供了实时控制功能，允许用户通过发送控制指令（如播放、暂停、快进、快退等）来操作视频流，增强了视频监控的灵活性和实用性。

2. 会议系统

• 应用场景：在视频会议系统中，RTSP可以用于实现音频和视频的实时传输。通过RTSP，多方参与者可以将各自的音视频流组合成一个统一的流，并发送给其他参与者，实现实时通信和协作。
• 优势：RTSP的低延迟特性保证了视频会议的流畅性，同时其可扩展性和灵活性也支持了大规模会议的需求。

3. 直播与点播服务

• 应用场景：RTSP广泛应用于直播和点播服务中。在直播场景中，RTSP服务器可以从实时视频源获取音视频流，并通过RTSP将其传输到客户端进行播放。在点播服务中，用户可以通过RTSP请求服务器上的特定媒体文件进行播放。
• 优势：RTSP支持多种流媒体格式和传输协议，能够满足不同平台和设备的需求，同时其控制功能也提升了用户体验。

4. 媒体播放器与服务器交互

• 应用场景：RTSP允许媒体播放器与流媒体服务器之间进行交互，实现播放控制、媒体信息获取等功能。用户可以通过媒体播放器发送RTSP请求给服务器，以控制媒体流的播放、暂停、停止等操作。
• 优势：RTSP为媒体播放器提供了一种标准化的控制接口，使得不同品牌和型号的播放器能够兼容不同的流媒体服务器，提高了系统的兼容性和可扩展性。

5. 虚拟现实与增强现实应用

• 应用场景：在虚拟现实（VR）和增强现实（AR）应用中，RTSP可以用于实现远程场景的实时音视频流传输。通过RTSP，用户可以将远程场景的音视频流传输到本地设备，实现沉浸式的虚拟现实体验或增强现实效果。
• 优势：RTSP的低延迟和实时控制功能保证了虚拟现实和增强现实应用的流畅性和互动性，提升了用户体验。

前提2：如何学习：

从前面的我们了解到：要学通 RTSP，至少有要将RTSP协议，RTP协议，RTCP协议这三个都学习明白了，才算真的明白。

这一章我们就针对RTSP学习。那么如何学习呢？

合理的方法是：

先baidu看一下，RTSP的重点介绍。包括协议的重点条款。

搭建一个RTSP的服务器 ，然后给这个RTSP的服务器发送数据，再从RTSP服务器上拉去数据。在这个过程中，使用wireshark在这几个过程中 抓取数据，结合 RTSP 协议 进行对照分析。以理解RTSP协议上的知识点。

一 .RTSP简介以及重要协议条款

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

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

​

二 .RTSP协议的中文版和英文版

中英文对照版，在 当前网页的 资源绑定 中，需要的童鞋可以下载。

英文原版 也在资源绑定中，需要的童鞋可以下载

这里要说明的是：如何找到这些资源–参考这篇博客 互联网的两大标准制定组织(IETF、IRTF)和一协会(ISOC) – jinzi – 博客园

核心是：三个网站，一些常用的标准都是这些组织创建的，可以在这些组织的网站上查找对应的文档。

Internet 工程任务组( IETF ) 是 Internet 的标准组织，负责组成Internet协议套件(TCP/IP)的技术标准。因此只要是和网络相关的协议都是IETF定制的，对应的官网如下：  

https://www.ietf.org/

在该网页上找Search IETF Datatracker ，在该栏目中search 你的要的网络协议的关键字，一般都能找到

结果：

三 .搭建RTSP 服务器

之所以先要搭建一个RTSP 服务器 ，目的是：分析流媒体发送到服务器和 从流媒体拉取流媒体数据这两个过程中，这些成熟的服务器 是如何使用RTSP，RTP，RTCP，SDP 协议的。

在搭建好RTSP 服务器后，需要执行如下的步骤：

0.  通过wireshark 抓包，

1.推送流媒体数据到RTSP， 

2.通过ffplay命令 或者 vlc工具 拉取流媒体数据

3.在 wireshark 过滤行 rtsp or rtp or rtcp or sdp 。

方法一：使用VLC 搭建 RTSP 服务器

使用VLC 搭建 RTSP 服务器-CSDN博客

方法二：使用ZLMediaKit 开源项目搭建RTSP 服务器

使用ZLMediaKit 开源项目搭建RTSP 服务器-CSDN博客

四. RTSP 协议学习以及分析

到这里，我们需要通过搭建好的RTSP 服务器 来学习 RTSP 协议，分为4步：

1.启动服务器，当前使用的linux上的 ZLMediaKit 的RTSP的服务器

2.使用wireshark 抓 网关数据

3.从windows 使用ffmpeg 命令 推送数据到 ZLMediaKit

4.从windows 使用ffplay 命令 拉取 数据到 ZLMediaKit

第一步 启动服务器

进入到 linux 中启动的 安装 ZLMediaKit 的RTSP的服务器。

1.cd到ZLMediaKit/release/linux/Debug 目录

cd /home/hunandede/software/ZLMediaKit/release/linux/Debug

2. 启动服务器

./MediaServer

./MediaServer  -d ./MediaServer  -d & nohup ./MediaServer -d &

第二步 使用wireshark 抓 网关数据

1.首先要知道抓那个网关的数据

当打开wireshark后，先要 调整到 "显示所有接口"，然后看到有7个网关，那么应该抓取那个网关的数据呢？

推流的时候，是从windows 给  linux 上的 RTSP 服务器发送数据，因此抓取的数据应该是经过 linux对应的网关的数据。

2. 根据 VMware 和 linux的设置来判断抓取那个网关的数据。

查看 ubuntu 网络设置。

查看NAT 模式对应的网络是那个

也就是说，linux 的网关是 VMnet8，也就是说，我们要使用wireshark要抓取的VMnet8 网关的数据 

查看 linux 的 ip  命令为  ifconfig 

查看 windows 的 ip，命令为 ifconfig -all

到这里我们就知道了如下的

查看这里，是为了知道是 NAT 模式还是 桥接模式，

对于  桥接模式，linux的IP 和 windows IP 是在同一网段。

对于 NAT 模式，linux 的IP 和 windows IP 不会在同一网段。

那么知道这个有啥用呢？不在同一网段，意味着通过 linux 网关，  抓取的数据一定是通过 xxx.xxx.xxx.1

例如 linux  的Ip 是192.168.245.129    

window 的IP 是    192.168.31.202

那么从windows 推流 到 linux 服务器中，由于 linux 和windows 不在同一网段，因此 从wireshark抓取linux 网关的数据，源IP 会是 192.168.245.1

那么从windows 推流 到 linux 服务器中，由于 linux 和windows 不在同一网段，因此 从wireshark抓取windows 网关的数据，目的IP 会是 192.168.31.1

启动wireshark，监视 VMnet8 网卡

第三步 从windows 使用ffmpeg命令推送数据到 linux

cmd 命令，进入到 有mp4文件的目录，

cd D:\\resource

C:\\Users\\Administrator>d:

通过命令 推送 5s.mp4 到   linux 服务器（IP为192.168.245.129）：

ffmpeg -re -i "5s.mp4" -vcodec h264 -acodec aac -f rtsp -rtsp_transport tcp rtsp://192.168.245.129/0015smp4

（从后面的结果看，这中写法是错误的，原因是要求 最少两级，将 rtsp://192.168.245.129/0015smp4 变成 rtsp://192.168.245.129/test/0015smp4 ）

这里要保证 5s.mp4的视频 是h264编码的 ，也就是命令中的  -vcodec h264

要保证  5s.mp4的音频 是acc编码的，也就是命令中的 -acodec aac

-f rtsp 表示是使用  rtsp 发送

-rtsp_transport tcp  表示的是 rtsp使用 tcp 链接

rtsp://192.168.245.129/test/0015smp4 的意义是 ：192.168.245.129 代表的是linux IP。/test/0015smp4是我们对于5s.mp4在linux 上的映射名称，可以随便起。但是注意的是最少要有两层。（最开始使用rtsp://192.168.245.129/0015smp4，结果失败，失败提示 最少两层。。。提示内容： rtsp推流url非法,最少确保两级rtsp url:rtsp://192.168.245.129:554/0015smp4,耗时(s):0 ）

这里因为在测试 NAT 模式和 桥接模式 切换的时候，IP地址发生了变化，变成了 192.168.245.130

因此后面 linux的IP 以 192.168.245.130为准

我们发送  ffmpeg -re -i "5s.mp4" -vcodec h264 -acodec aac -f rtsp -rtsp_transport tcp rtsp://192.168.245.130/0015smp4

结果有error，看服务器提示说：至少两级，这说明我们前面

等发送完毕后，在wireshark 保存 推流，我们命名为tuiliu5smp4.pcapng

第四步：在windows 使用 ffplay 命令 从linux 拉取数据

ffplay -rtsp_transport tcp rtsp://192.168.245.130/test/0015smp4  

由于从linux 拉取数据的时候，要有从 windows 推流的数据才行。我们刚开始的推流的5s.mp4的时间只有5秒，因此换个长一点的mp4推流，然后拉这个

推

ffmpeg -re -i "zerenlian.mp4" -vcodec h264 -acodec aac -f rtsp -rtsp_transport tcp rtsp://192.168.245.130/test/002zerenlianmp4  

拉

ffplay -rtsp_transport tcp rtsp://192.168.245.130/test/002zerenlianmp4

然后保存wireshark数据。

第五步：结合 RTSP 协议 分析 tuiliu5smp4.pcapng

1.打开 RTSP 协议的中英文 对照版，

2.使用wireshark 打开上次推流保存的 tuiliu5smp4.pcapng

在wireshark中过滤 rtsp or rtp or rtcp,然后一行一行的分析 pcapng

推流过程中 RTSP 的发送过程：

1.从客户端发送 OPTION request 到服务器，目的是问服务器，您支持哪些方法呢？

RTSP 部分一行一行的分析：

Real Time Streaming Protocol
    Request: OPTIONS rtsp://192.168.245.130:554/test/0015smp4 RTSP/1.0\\r\\n
        Method: OPTIONS
        URL: rtsp://192.168.245.130:554/test/0015smp4
    CSeq: 1\\r\\n
    User-Agent: Lavf60.3.100\\r\\n
    \\r\\n

Request: OPTIONS rtsp://192.168.245.130:554/test/0015smp4 RTSP/1.0\\r\\n

Request 表示请求

: 是格式要求

OPTIONS 表示 请求关键字是option，这个关键字目的是问服务器，您支持哪些方法呢？

rtsp://192.168.245.130:554/test/0015smp4 表示推送给服务器的IP+文件的URL。

        Method：OPTION  这一行是 wireshark 帮我们解析出来的，可忽略

        URL: rtsp://192.168.245.130:554/test/0015smp4  这一行是wireshark 帮我们解析出来的，可忽略

RTSP/1.0 表示的用的协议版本。这个版本是是ffmpeg 中的使用的版本，因为我们发送的是

\\r\\n 是rtsp 一行结束符

CSeq: 1\\r\\n

每个消息都有序号来标记，第一个包通常是option请求消息，与之对应的回复的的CSeq也是一样的，例如在这个中，序号标记是1，那么与之对应的回复的消息的CSeq也应该是1.我们看一下这个回复，确实是1.

与之对应回复的部分
Real Time Streaming Protocol
Response: RTSP/1.0 200 OK\\r\\n
Status: 200
CSeq: 1\\r\\n
Date: Sat, Dec 28 2024 12:30:08 GMT\\r\\n
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE, RECORD, SET_PARAMETER, GET_PARAMETER\\r\\n
Server: ZLMediaKit(git hash:8bf48ed/2024-12-15T11:43:31+08:00,branch:master,build time:2024-12-19T12:43:26)\\r\\n
\\r\\n

我们看在在RTSP 协议中有更加详细的说明：

发送顺序可由CSeq头及其序列号确定。对于TCP，两个代理（agent）之间的交互顺序与发送顺序相同。在处理来自同一代理(agent)的下一个请求之前，请求的处理也必须已经完成。响应必须按照处理请求的顺序发送。

通过允许请求代理（agent）有多个未完成的请求并通过相同的持久连接发送它们，管道是一种提高请求/响应协议性能的通用方法。
对于RTSP，请求的相对顺序很重要，因此维护请求的顺序很重要。
因此，响应代理（agent）必须按照发送顺序处理传入的请求。
发送顺序可由CSeq头及其序列号确定。
对于TCP，两个代理（agent）之间的交互顺序与发送顺序相同。
在处理来自同一代理(agent)的下一个请求之前，请求的处理也必须已经完成。
响应必须按照处理请求的顺序发送。

但是这里并没有search 到关于UDP 这个部分的说明，注意这是RTSP的协议，走的都是TCP的协议。

User-Agent: Lavf60.3.100\\r\\n

在option 中的 User-Agent 标明了 我使用ffmpeg 的 avformat版本是多少。

使用ffmpeg命令查看，可以看到 avfromat和要发送的 user-Agent是一样的

那么为什么 要发送的avformat 给 服务器呢？还记得推流的命令吗？因为我们windows 是使用ffmpeg 推流的。而服务器端并不能确定客户端推流的时候用的ffmpeg的版本，因此猜测在服务器端应该是有ffmpeg 的各个版本的不同的代码去处理推流。同理，在拉流的时候应该也一样有客户端和服务器端关于ffmpeg 的 衡量。如果我们的客户端用的不是ffmpeg 命令，而是服务器厂家开发的客户端，例如虎牙直播，那么客户端一定是和服务器端关于ffmepg的版本会保持一致。

可能得疑惑1：关于源IP 和 目的IP

我们的window 的IP 是192.168.31.202

linux 的IP 是 192.168.245.130 

那么为什么这个source 在wireshark中是 192.168.245.1？这是因为的linux 使用的NAT模式，因此和windows的IP不在同一网段，不在同一网段的两个IP 通数据，需要经过网关。而linux的网关就是192.168.245.1，因此source就变成了 192.168.245.1

可能得疑惑2:Method：OPTION 这一行的分析

为什么说这一行是 wireshark 帮我们的分析出来的呢？也就是说：这个method 不是RTSP中本来就带的字符串呢？这里主要学习一下方法

对照wireshark查看：

可能得疑惑3：在RTSP 前面还有TCP/IP的相关，那么RTSP 协议和 TCP/IP 协议是如何关联的。

TODO

2.服务器关于OPTION的回复如下：

Real Time Streaming Protocol
Response: RTSP/1.0 200 OK\\r\\n
Status: 200
CSeq: 1\\r\\n
Date: Sat, Dec 28 2024 12:30:08 GMT\\r\\n
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE, RECORD, SET_PARAMETER, GET_PARAMETER\\r\\n
Server: ZLMediaKit(git hash:8bf48ed/2024-12-15T11:43:31+08:00,branch:master,build time:2024-12-19T12:43:26)\\r\\n
\\r\\n

Response: RTSP/1.0 200 OK\\r\\n

Response 表示的回复

: 是格式

RTSP/1.0 表示的是版本

        Status: 200 

                服务器返回的状态，200表示成功

    CSeq: 1\\r\\n

                CSeq 表示的是，我的这个回复是 回复 CSeq = 1的request

    Date: Sat, Dec 28 2024 12:30:08 GMT\\r\\n

                服务器的回复时间

    Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE, RECORD, SET_PARAMETER, GET_PARAMETER\\r\\n

                Public开头，Pubilc也是服务器传递过来的字符串，不是wireshark帮忙解析的。服务器回复：服务器支持的方法，这是重点，需要明白每个参数的含义

    Server: ZLMediaKit(git hash:8bf48ed/2024-12-15T11:43:31+08:00,branch:master,build time:2024-12-19T12:43:26)\\r\\n

                  Server 开头，表示了服务器的名字啥的信息。     \\r\\n

rtsp 支持的方法的说明

OPTIONS

一般由客户端发出，询问服务器有哪些方法可用。一般是推流的第一步，一般也是拉流的第一步

DESCRIBE

一般由客户端发出，要求得到S提供的媒体描述信息。一般在拉流的第二步使用，

SETUP

SETUP建⽴RTSP会话，一般由客户端发起，通过Transport头字段列出可接受的传输选项，请求S建⽴会话

TEARDOWN

C请求关闭会话

PLAY

C请求S开始发送数据

PAUSE

ANNOUNCE 

客户端发送媒体描述信息给服务器端，一般用于 推流的第二步。

RECORD

RECORD请求传送数据

SET_PARAMETER

GET_PARAMETER

3. 客户端发送 ANNOUNCE，目的是客户端发送媒体描述信息给服务器端

这很好理解，在第一步询问了服务器支持的有哪些方法，发现服务器支持 ANNOUNCE后，理论上就要告诉服务器，我要发送的 流媒体数据的URL是啥，我的发送的流媒体的格式是啥等，其中描述流媒体数据的描述，需要通过SDP协议格式发送，因此要读懂这块内容，需要学习SDP 协议：TODO

Frame 9: 553 bytes on wire (4424 bits), 553 bytes captured (4424 bits) on interface \\Device\\NPF_{13ABD455-B09A-4657-9731-83547FC8A4AF}, id 0
Ethernet II, Src: VMware_c0:00:08 (00:50:56:c0:00:08), Dst: VMware_6c:26:fe (00:0c:29:6c:26:fe)
Internet Protocol Version 4, Src: 192.168.245.1, Dst: 192.168.245.130
Transmission Control Protocol, Src Port: 59322, Dst Port: 554, Seq: 246, Ack: 280, Len: 499
[2 Reassembled TCP Segments (648 bytes): #7(149), #9(499)]
Real Time Streaming Protocol
Request: ANNOUNCE rtsp://192.168.245.130:554/test/0015smp4 RTSP/1.0\\r\\n
Method: ANNOUNCE
URL: rtsp://192.168.245.130:554/test/0015smp4
Content-type: application/sdp
CSeq: 2\\r\\n
User-Agent: Lavf60.3.100\\r\\n
Content-length: 499
\\r\\n
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): – 0 0 IN IP4 127.0.0.1
Session Name (s): No Name
Connection Information (c): IN IP4 192.168.245.130
Time Description, active time (t): 0 0
Session Attribute (a): tool:libavformat 60.3.100
Media Description, name and address (m): video 0 RTP/AVP 96
Media Attribute (a): rtpmap:96 H264/90000
Media Attribute (a): fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAKKzZQHgGWwFqAgICgAAAAwCAAAAYB4wYyw==,aOvjyyLA; profile-level-id=640028
Media Attribute (a): control:streamid=0
Media Description, name and address (m): audio 0 RTP/AVP 97
Bandwidth Information (b): AS:128
Media Attribute (a): rtpmap:97 MPEG4-GENERIC/44100/2
Media Attribute (a): fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3; config=121056E500
Media Attribute (a): control:streamid=1

我们先来学习一下 非 SDP的部分

Request: ANNOUNCE rtsp://192.168.245.130:554/test/0015smp4 RTSP/1.0\\r\\n         Method: ANNOUNCE         URL: rtsp://192.168.245.130:554/test/0015smp4     Content-type: application/sdp     CSeq: 2\\r\\n     User-Agent: Lavf60.3.100\\r\\n     Content-length: 499

Content-type 表示，内容的部分是 sdp 的

CSeq  每个消息都有序号来标记，可以看到这个CSeq 是自增的。

SDP 的

Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): – 0 0 IN IP4 127.0.0.1
Session Name (s): No Name
Connection Information (c): IN IP4 192.168.245.130
Time Description, active time (t): 0 0
Session Attribute (a): tool:libavformat 60.3.100
Media Description, name and address (m): video 0 RTP/AVP 96
Media Attribute (a): rtpmap:96 H264/90000
Media Attribute (a): fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAKKzZQHgGWwFqAgICgAAAAwCAAAAYB4wYyw==,aOvjyyLA; profile-level-id=640028
Media Attribute (a): control:streamid=0
Media Description, name and address (m): audio 0 RTP/AVP 97
Bandwidth Information (b): AS:128
Media Attribute (a): rtpmap:97 MPEG4-GENERIC/44100/2
Media Attribute (a): fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3; config=121056E500
Media Attribute (a): control:streamid=1

五. NEXT :学习 RTP 协议

我们先学习 RTP 协议，可以再学习了RTP协议后，再反过来 学习 RTSP 协议，这是两个原因决定的：

第一： RTSP协议中的一些概念以及为什么这么设计的学习 是基于RTP设计的，也就是说，我们明白了RTP中协议的一些基本概念或者要求，就能对 RTSP 协议为什么这么设计，能有更加明确的了解。

第二：RTP 协议比 RTSP协议重要的多，在后面的webrtc相关的知识中，很多都是用 RTP 和 RTCP直接做的，就用不到RTSP协议。

 RTP协议：负责客户端和服务器端之间传递媒体数据；RTP协议详情。FFmpeg 4.3 音视频-多路H265监控录放C++开发二十一.2，RTP协议-RTP协议概述，协议详情-CSDN博客