1. 课程导入
在实时音视频系统里，FFmpeg 与 RTP 往往同时出现：前者负责“把媒体变成可处理的帧与包”，后者负责“把包按时间与顺序送到对端”。很多开发者第一次接触流媒体时，会把问题简单理解为“调用一个推流接口”，但真正上线后才发现，卡顿、花屏、延迟抖动、CPU 飙高、丢包重传等问题，几乎都落在编码参数、时间戳、分包策略、缓冲与网络反馈这些细节上。本课程的目标，是让你既能用 FFmpeg 完成采集、解码、编码、封装与推流，又能理解 RTP 的性能边界，并具备定位与调优的能力。
一、FFmpeg 与流媒体开发全景
FFmpeg 不是一个单一工具，而是一组库与命令行工具的集合。流媒体开发中常用的核心组件包括：libavformat 负责封装与解封装（如 MP4、FLV、RTSP、RTP），libavcodec 负责编解码（H.264、H.265、AAC、Opus 等），libavfilter 负责滤镜处理（缩放、裁剪、叠加、格式转换），libswscale 与 libswresample 负责图像与音频的格式转换和重采样，libavutil 提供时间基、帧、包、缓冲区等基础结构。命令行工具 ffmpeg、ffprobe、ffplay 则是验证与排障的利器。
从数据流角度看，一条典型的实时链路是：采集设备或文件 → 解封装/解码 → 滤镜处理 → 编码 → 封装为 RTP 包 → 通过 UDP/TCP 发送 → 接收端收包、抖动缓冲、解码、渲染。FFmpeg 覆盖了其中大部分环节，而 RTP 则位于“封装与传输”这一段。理解这条链路，才能明白为什么一个参数改动会同时影响延迟、画质与 CPU 占用。
二、RTP 性能调优的价值
RTP 是实时传输协议，它本身不保证可靠，而是通过序列号、时间戳、负载类型与 SSRC 等字段，让接收端能够重组、排序、同步与统计。RTP 的性能问题通常表现为：端到端延迟高、抖动大、丢包后画面长时间花屏、音频断续、带宽利用率低或突发拥塞。调优的价值在于，把“能跑”变成“稳定可交付”。
例如，在弱网环境下，如果 RTP 包过大，UDP 分片会增加丢包概率；如果 pkt_size 设置过小，包数量增多，头部开销与处理开销上升；如果 GOP 过长，关键帧间隔大，丢包后恢复慢；如果发送端没有根据 RTCP 反馈调整码率，就会持续拥塞。调优不是单点参数，而是“编码—分包—发送—反馈”的闭环。
核心认知：RTP 调优的目标不是追求最低延迟或最高画质，而是在给定网络条件下，让延迟、流畅度、清晰度与资源消耗达到可接受的平衡。
三、学习路径与实战目标
本课程按“基础能力 → 协议理解 → 性能调优 → 实战排障”推进。建议按以下路径学习：
- FFmpeg 基础：掌握
AVFormatContext、AVCodecContext、AVPacket、AVFrame的生命周期与时间基转换。 - 流媒体协议：理解 RTSP、RTMP、RTP/RTCP、SRT 的差异与适用场景。
- RTP 分包与发送：掌握 H.264/H.265 的 NAL 单元、FU-A 分片、时间戳与序列号生成。
- 性能调优：围绕码率控制、GOP、
pkt_size、发送缓冲、抖动缓冲、FEC 与重传策略进行实验。 - 排障与复盘：用
ffprobe、ffplay、Wireshark 与日志定位问题，形成可复用的调优清单。
实战目标可以概括为：能够独立搭建一条“采集→编码→RTP 发送→接收播放”的链路，并能在模拟弱网条件下，通过参数调整把延迟、丢包恢复与 CPU 占用控制在合理范围。下面是一个常用的验证命令示例：
# 查看流信息与时间基
ffprobe -v error -show_streams -show_format input.mp4
# 以 RTP 方式发送 H.264 到本地端口
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast \
-tune zerolatency -f rtp rtp://127.0.0.1:5004
# 接收并播放 RTP 流（需配合 SDP 文件）
ffplay -protocol_whitelist file,rtp,udp -i stream.sdp
四、常见误区与复盘清单
初学者最容易陷入的误区包括：只关注“能不能播”，忽略时间戳与抖动；把 RTP 当成可靠传输，认为丢包会自动重传；盲目追求低延迟而把缓冲设得过小，导致网络稍有波动就卡顿；只调编码参数，不看网络反馈。复盘时，建议按“现象→指标→链路环节→参数→验证”的顺序推进，而不是凭感觉改参数。
| 常见现象 | 可能环节 | 优先检查项 | 验证方式 |
|---|---|---|---|
| 画面花屏、马赛克 | RTP 丢包或分片错误 | pkt_size、FU-A 分片、序列号 | Wireshark 抓包、统计丢包 |
| 延迟持续增大 | 发送缓冲或抖动缓冲过大 | 缓冲时长、码率、GOP | ffplay 延迟观测、RTCP 反馈 |
| 音频断续 | 时间戳或重采样问题 | 采样率、时间基、RTP 时钟频率 | ffprobe 查看流参数 |
| CPU 占用过高 | 编码预设或滤镜过重 | preset、分辨率、像素格式 | top/性能分析、逐步简化 |
| 弱网下卡顿严重 | 缺乏码率自适应与 FEC | 码率控制、FEC、重传策略 | 模拟弱网、对比调优前后 |
学习建议：每学一个参数，都问三个问题：它影响链路的哪一段？它的代价是什么？如何用指标验证？把这三个问题回答清楚，调优就不会变成“玄学”。
注意：RTP 本身不提供可靠性，丢包、乱序与抖动是常态。任何“零丢包”的假设都会导致设计偏差。调优时应以统计指标和实际播放体验为准，而不是只看单次命令是否成功。
当你能够把 FFmpeg 的处理链路与 RTP 的传输特性放在同一张图上思考，就已经具备了流媒体开发的核心视角。接下来的章节会逐步深入每个环节，从基础 API 到协议细节，再到性能调优与实战排障，帮助你建立一套可落地、可验证、可复用的工程方法。