RTSP 流媒体实战：服务器搭建与协议基础
1-RTSP服务器搭建.mp42-RTSP基本原理.mp43-RTP协议讲解.mp4
一句话总览
这组三节课的主线是：先搭一个可运行的 RTSP 流媒体服务器，再通过抓包理解 RTSP 如何控制播放流程，最后深入到 RTP 报文格式，理解真正承载音视频数据的包长什么样。
RTSP 本身更像“遥控器”：负责告诉服务端要查询、建立会话、开始播放、暂停或结束。真正传输音视频负载的是 RTP，RTCP 则用于传输质量反馈和同步控制。SDP 常出现在 DESCRIBE 响应里，用来描述媒体会话信息，例如编码格式、媒体类型、端口、控制 URL 等。
1. RTSP 服务器搭建
第一节课围绕 ZLMediaKit 搭建 RTSP 服务。演示环境是远程 Linux 主机，通过浏览器查看项目说明，通过终端进入源码目录、查看第三方库、编译并启动 MediaServer。
搭建流程可以概括为：
- 准备 Linux 环境和编译依赖。
- 获取
ZLMediaKit源码，注意子模块或第三方依赖也要拉齐。 - 进入构建目录执行 CMake/Make 构建。
- 进入
release/linux/Debug或对应输出目录。 - 启动
MediaServer。 - 检查
554等端口是否被占用。 - 通过推流、拉流或抓包验证服务是否真正工作。
课程中比较重要的一点是端口问题。RTSP 默认端口通常是 554，如果启动时报 address already in use 或 permission denied，要先判断是端口被占用，还是普通用户没有权限监听低端口。
常见排查命令：
sudo lsof -i:554
sudo kill -9 <pid>
sudo ./MediaServer如果服务启动失败，优先看三类信息：
- 端口是否被占用：
address already in use - 是否缺少权限：
permission denied - 配置文件是否正确：例如
config.ini中 RTSP、RTP、HTTP 等端口配置
2. RTSP 基本原理
RTSP 的核心作用是建立和控制实时媒体会话。它不是用来直接传输大块音视频数据的协议，而是通过一组类似 HTTP 风格的请求命令来控制服务端。
典型 RTSP 请求序列如下：
OPTIONS -> 查询服务端支持哪些方法
DESCRIBE -> 获取媒体描述信息，通常返回 SDP
SETUP -> 为某一路音频/视频建立传输通道
PLAY -> 开始播放
PAUSE -> 暂停播放
TEARDOWN -> 释放会话资源OPTIONS
OPTIONS 用来询问服务器支持哪些 RTSP 方法。抓包里通常能看到服务端返回 Public 字段，列出 DESCRIBE、SETUP、PLAY、TEARDOWN 等能力。
DESCRIBE
DESCRIBE 是理解一条 RTSP 地址的关键步骤。客户端请求某个 rtsp://... URL 后，服务端通常返回 SDP。SDP 里会描述这个流有哪些媒体轨道、使用什么编码、时钟频率是多少，以及后续 SETUP 应该访问哪个控制路径。
SDP 中常见字段：
v= 协议版本
o= 会话所有者
s= 会话名称
t= 会话时间
m= 媒体类型、端口、传输协议、payload type
a= 附加属性，例如 codec、control、fmtpSETUP
SETUP 用来给具体媒体轨道建立传输通道。音频和视频通常会分别 SETUP，因为它们可能对应不同的 track。
这里最关键的是 Transport 字段。它决定 RTP 数据怎么传：
- RTP over UDP：RTSP 走 TCP 控制通道，RTP/RTCP 走 UDP 端口。
- RTP over TCP：RTSP、RTP、RTCP 都复用同一个 TCP 连接，RTP 包会以 interleaved 方式嵌入 RTSP 连接中。
课程里强调了多组传输通道：RTSP 负责控制，RTP video/RTP audio 负责媒体数据，RTCP 负责控制与反馈。
PLAY 和 TEARDOWN
PLAY 之后，服务端开始发送 RTP 数据。客户端继续通过 RTP 序列号、时间戳、payload type 等字段还原媒体帧。
TEARDOWN 用来释放会话。实际开发中不要忽略它，因为服务器端需要回收 session、socket、端口和相关缓存。
3. RTP 协议讲解
RTP 是真正承载实时音视频数据的协议。它通常跑在 UDP 上，也可以通过 RTSP 的 TCP 连接进行 interleaved 传输。
一个 RTP 包由两部分组成：
RTP Header + RTP PayloadHeader 负责描述这份媒体数据的顺序、时间、类型和来源；Payload 才是实际的音频或视频数据片段。
RTP 固定头部中最重要的字段：
| 字段 | 含义 |
|---|---|
V | RTP 版本，常见为 2 |
P | padding 标志，表示末尾是否有填充 |
X | extension 标志，表示是否有扩展头 |
CC | CSRC 个数 |
M | marker 标志，含义依媒体类型而定，视频里常用于标记一帧结束 |
PT | payload type，表示负载类型，例如 H.264、AAC、JPEG 等 |
sequence number | 序列号，每发送一个 RTP 包递增，用于检测丢包和乱序 |
timestamp | 时间戳，用于播放同步和抖动处理 |
SSRC | 同步源标识，用来区分同一个会话中的不同媒体源 |
CSRC | 贡献源标识，混音或混流场景可能使用 |
4. RTP 打包与还原
RTP 不保证一个视频帧正好对应一个网络包。真实情况通常是：
- 一个小帧可能放进一个 RTP 包。
- 一个大帧可能被拆成多个 RTP 包。
- 接收端需要根据序列号判断顺序和丢包。
- 接收端需要根据时间戳恢复播放节奏。
- 对 H.264/H.265 这类视频编码，还要按对应 RFC 的规则处理 NALU、分片和聚合包。
调试 RTP 时，Wireshark 里尤其要关注：
- RTP 包是否连续递增。
- Payload Type 是否和 SDP 里声明一致。
- 同一路流的 SSRC 是否稳定。
- 时间戳是否按媒体时钟递增。
- Marker 位是否符合一帧结束的语义。
- UDP 端口或 TCP interleaved channel 是否和
SETUP里的Transport字段对应。
5. RTSP、RTP、RTCP、SDP 的关系
可以把这几个协议按职责分开记：
| 协议 | 职责 | 典型出现位置 |
|---|---|---|
| RTSP | 控制播放会话 | OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN |
| SDP | 描述媒体会话 | DESCRIBE 响应体 |
| RTP | 承载音视频数据 | PLAY 之后持续传输 |
| RTCP | 传输统计、同步、质量反馈 | 与 RTP 配套 |
RTSP 控制“什么时候播、播哪一路、怎么传”；SDP 说明“这路流是什么”；RTP 负责“把音视频数据送过去”；RTCP 负责“反馈传输质量和同步信息”。
6. 开发和排错速查
服务器侧
- 启动前确认端口是否被占用。
- RTSP 默认端口一般是
554，监听低端口可能需要 root 权限或能力配置。 - 修改配置后重启服务，确认日志里没有绑定失败。
- 如果使用 ZLMediaKit，重点关注
MediaServer的启动日志和config.ini。
客户端侧
- 先确认 RTSP URL 是否正确。
- 用 VLC、ffplay 或自写客户端验证拉流。
- 如果
DESCRIBE都拿不到，优先查网络、URL、鉴权、服务端状态。 - 如果
DESCRIBE正常但播放失败，重点查SETUP的Transport和 RTP/RTCP 端口。
抓包侧
- 过滤 RTSP：
rtsp - 过滤 RTP：
rtp - 查看完整流程：先看 RTSP 控制消息，再跳到 RTP 包。
- 检查
CSeq是否连续，对应请求和响应。 - 检查
Session是否在SETUP后被后续请求持续携带。 - 检查
Transport中的 UDP 端口或 TCP channel 是否与实际 RTP 包匹配。
7. 总结下
RTSP = 控制协议，像遥控器
SDP = 媒体说明书，告诉你有几路流、什么编码、怎么 setup
RTP = 媒体数据包，真正装音频/视频
RTCP = RTP 的控制与反馈通道抓包时按这个顺序看：
OPTIONS -> DESCRIBE -> SETUP(video/audio) -> PLAY -> RTP data -> TEARDOWN搭服务器时按这个顺序查：
源码/依赖 -> 编译输出 -> 配置文件 -> 端口监听 -> 拉流验证 -> Wireshark 抓包
评论
...正在读取评论。