1. RTSP 推流概述：协议基础、架构与丢包问题

各位同学好，我是你们的流媒体工程讲师。今天咱们正式进入《RTSP推流中的丢包恢复方案》这门课。第一讲，我想先聊聊 RTSP 推流最基础的东西——协议本身、整体架构，以及那个让所有流媒体工程师都头疼的丢包问题。

说实话，我入行那会儿，RTSP 还是个很“纯粹”的协议。后来随着直播、安防、视频通话的爆发，大家发现光靠 RTSP 那套老规矩，在公网上根本扛不住丢包。嗯，这也是为什么我会把这门课的重点放在“丢包恢复”上。

1.1 RTSP 协议基础——它到底是个啥？

RTSP，全称 Real-Time Streaming Protocol，实时流媒体协议。你想想看，它其实就是一个“遥控器”。

它不负责传输视频数据本身，而是负责控制——比如让播放器发起播放、暂停、快进、后退这些操作。真正的视频流，是通过 RTP（Real-time Transport Protocol）来传的。

RTSP 的语法长得跟 HTTP 很像，也是请求-响应模式。常用的方法就那么几个：

方法	作用	我常用的场景
OPTIONS	查询服务器支持哪些方法	刚连上时先探探路
DESCRIBE	获取媒体描述信息（SDP）	拿到视频编码、分辨率等参数
SETUP	建立传输通道（UDP/TCP）	这一步决定了后续丢不丢包
PLAY	开始播放	推流端发这个，服务器开始收流
TEARDOWN	终止会话	断开连接，清理资源

我个人习惯把 RTSP 会话比作一次电话通话：SETUP 是拨号，PLAY 是接通后开始说话，TEARDOWN 是挂断。简单吧？

1.2 推流架构——数据从哪来，到哪去？

搞清楚了协议，咱们再看看典型的推流架构长什么样。我在项目中遇到过不少新手，上来就写代码，结果连数据流都没理清，调试时一头雾水。

一个标准的 RTSP 推流架构，通常包含这几个角色：

• 推流端（Publisher）：摄像头、编码器、或者你的手机。负责采集音视频，编码后打包成 RTP 包。
• 流媒体服务器（Server）：比如 Live555、SRS、Nginx-RTMP 模块。负责接收推流，并分发给拉流端。
• 拉流端（Player）：VLC、FFplay、或者你的 App。负责从服务器拉取流并播放。

数据流向大概是这样的：

推流端（摄像头） 
    ↓ 采集 → 编码（H.264/H.265）→ 打包（RTP）
    ↓ RTSP 推流（SETUP + PLAY）
流媒体服务器
    ↓ 转分发 / 转封装
拉流端（播放器）
    ↓ RTSP 拉流 → 解包 → 解码 → 渲染

这里有个关键点：推流端和服务器之间，通常走的是 UDP 传输 RTP 包。为什么？因为 UDP 延迟低，适合实时场景。但代价就是——丢包。

1.3 丢包问题引入——为什么非解决不可？

好了，咱们终于聊到核心了。丢包，说白了就是 RTP 包在传输过程中“失踪”了。

为什么会这样？原因很多：

• 网络拥塞：路由器缓冲区满了，直接丢弃后续包。
• 链路不稳定：Wi-Fi 信号差、4G 切换基站、网线接触不良。
• MTU 限制：RTP 包太大，被 IP 层分片，其中一片丢了，整个包都废了。
• 防火墙/ NAT：某些设备会随机丢弃 UDP 包。

丢包带来的后果，你想想看：

• 花屏：视频画面出现马赛克、绿块。
• 卡顿：播放器等待重传或丢帧，画面停滞。
• 音画不同步：音频包丢了，视频还在播，嘴型对不上。
• 断流：关键帧（I帧）丢了，后续所有帧都无法解码，直接黑屏。

所以，丢包恢复不是“锦上添花”，而是“雪中送炭”。尤其是在实时性要求高的场景——比如直播带货、远程手术、无人机图传——丢包恢复方案直接决定了用户体验。

1.4 本章知识体系总览

为了让你对本章内容有个整体印象，我画了一张图。它把 RTSP 推流的核心要素、数据流向、以及丢包问题的引入点都串起来了。

从这张图你可以看到，推流端把 RTP 包扔进网络，网络环境的好坏直接决定了丢包率。而我们的丢包恢复方案，就是在推流端和服务器之间，或者服务器内部，加入各种“补丁”来对抗丢包。

后面的课程，我会逐一拆解这些方案：FEC（前向纠错）、ARQ（自动重传请求）、以及各种混合策略。但今天，你只需要记住一句话：丢包是常态，恢复是刚需。