1. 课程导入
做流媒体优化这些年，我最大的感受是：基础不牢，地动山摇。很多同学一上来就追着调参数、改配置，结果卡顿问题反而更严重。说白了，你得先搞清楚数据是怎么从摄像头跑到用户屏幕上的，才能知道瓶颈在哪。
这一章，咱们就把地基打扎实。我会从传输协议对比、延迟与卡顿的根源、核心性能指标三个维度展开。嗯，都是我在项目里踩过的坑，希望能帮你少走弯路。
1.1 三大流媒体传输协议对比
目前主流的流媒体协议就三个：RTMP、HLS、DASH。我习惯把它们分成两类：实时型和分段型。RTMP 是实时型的代表，HLS 和 DASH 则是分段型的双雄。
核心观点：没有完美的协议，只有适合的场景。选协议就是做权衡——延迟、兼容性、成本，你总得放弃一个。
RTMP（Real-Time Messaging Protocol）
RTMP 是 Adobe 搞出来的老协议，基于 TCP 长连接。数据流是连续的，没有分片等待。我在做直播推流时，RTMP 几乎是标配——延迟能控制在 1-3 秒。
但它有个致命伤：浏览器不支持原生播放。你想想看，用户点开网页还得装 Flash，这体验谁受得了？所以现在 RTMP 基本只用在推流端，播放端已经很少见了。
HLS（HTTP Live Streaming）
苹果推出的 HLS 协议，把视频切成一个个小片段（通常是 2-10 秒的 TS 文件），通过 m3u8 索引文件来管理。它最大的优势是基于 HTTP，CDN 随便配，防火墙基本不拦。
我遇到过一家客户，他们的直播延迟高达 30 秒。一查，HLS 默认切片 6 秒，加上 GOP 对齐和缓冲区，延迟就这么堆上去了。后来我帮他们把切片改成 2 秒，延迟降到 8 秒左右——虽然还是比 RTMP 高，但兼容性好了太多。
DASH（Dynamic Adaptive Streaming over HTTP）
DASH 是 MPEG 推出的国际标准，思路和 HLS 类似，但更灵活。它使用 MPD 文件描述媒体信息，支持多种编码格式。说白了，HLS 是苹果的封闭生态，DASH 是开放标准。
不过在实际项目中，DASH 的普及度还是不如 HLS。为什么？因为苹果设备对 HLS 有原生支持，而 DASH 需要额外的播放器库。我建议你优先考虑 HLS，除非你的目标平台明确要求 DASH。
| 特性 | RTMP | HLS | DASH |
|---|---|---|---|
| 传输方式 | TCP 长连接 | HTTP 分段 | HTTP 分段 |
| 典型延迟 | 1-3 秒 | 6-30 秒 | 6-30 秒 |
| 浏览器支持 | 需插件 | 原生（Safari） | 需 MSE |
| 推流端使用 | 广泛 | 较少 | 较少 |
| 播放端使用 | 极少 | 广泛 | 中等 |
| CDN 友好度 | 一般 | 优秀 | 优秀 |
我的建议：推流用 RTMP，播放用 HLS。如果对延迟有极致要求（比如互动直播），可以考虑 WebRTC，那是另一个赛道了。
1.2 延迟与卡顿的根源分析
延迟和卡顿，是流媒体优化的两个核心矛盾。你压了延迟，卡顿可能就上来；你保了流畅，延迟又下不去。为什么会这样？咱们拆开来看。
延迟的来源
延迟说白了就是数据从源头到目的地的时间。我把它分成四个环节：
- 采集延迟：摄像头、麦克风把模拟信号转成数字信号，需要时间。这个一般很小，几十毫秒。
- 编码延迟：这是大头。H.264 编码需要参考帧，B 帧的存在会让编码器缓存好几帧才能输出。我遇到过编码延迟 500ms 的情况，后来关了 B 帧，降到 100ms。
- 网络传输延迟：数据包在网络上跑的时间。这个取决于物理距离和网络质量。国内跨运营商，延迟经常飙到 100ms 以上。
- 播放缓冲延迟：播放器为了对抗网络抖动，会预存几秒数据。缓冲越大，延迟越高。
避坑指南：我曾经帮一个客户排查延迟问题，发现他们的播放器缓冲设了 10 秒。问为什么，答曰「默认配置」。嗯，很多时候延迟高不是技术问题，是配置问题。
卡顿的根源
卡顿的本质是播放速度跟不上数据到达速度。原因主要有三个：
- 带宽不足：视频码率超过了当前可用带宽。比如你推 4Mbps 的流，但用户只有 2Mbps 的网速，不卡才怪。
- 网络抖动：带宽忽高忽低。前一秒 10Mbps，后一秒 500Kbps，播放器根本来不及适应。
- 缓冲区耗尽：播放器把缓冲数据播完了，新的数据还没到。这就是典型的「转圈圈」。
我做过一个统计：在移动网络下，70% 的卡顿是由网络抖动引起的，只有 20% 是带宽不足，剩下 10% 是服务器或播放器问题。所以优化卡顿，重点要放在抗抖动上。
1.3 核心性能指标定义
做优化，你得先知道怎么衡量。没有指标，你都不知道自己优化得好不好。我常用的指标有这几个：
延迟类指标
- 端到端延迟：从采集到播放的总时间。直播场景一般要求 < 5 秒，互动场景要求 < 1 秒。
- 编码延迟：编码器从输入到输出的时间。通常 < 200ms 算合格。
- 播放缓冲延迟：播放器缓冲区的数据时长。这个值越低越好，但太低会导致卡顿。
质量类指标
- 卡顿率：播放过程中卡顿次数占总播放时长的比例。我一般要求 < 1%。
- 卡顿时长比：卡顿总时长 / 播放总时长。这个比卡顿率更准确，因为一次卡顿可能持续好几秒。
- 首帧时间：用户点击播放到第一帧画面出现的时间。超过 3 秒，用户就可能流失。
体验类指标
- MOS 分：主观体验评分，1-5 分。4 分以上算优秀。
- VMAF：Netflix 推出的客观质量评分，0-100 分。90 分以上算高清。
| 指标类别 | 指标名称 | 典型阈值 | 测量方法 |
|---|---|---|---|
| 延迟 | 端到端延迟 | < 5 秒（直播） | 时间戳对比 |
| 延迟 | 编码延迟 | < 200ms | 编码器日志 |
| 质量 | 卡顿率 | < 1% | 播放器事件 |
| 质量 | 首帧时间 | < 3 秒 | 用户点击到首帧 |
| 体验 | MOS 分 | > 4.0 | 主观评分 |
| 体验 | VMAF | > 90 | 客观算法 |
小技巧：我习惯在播放器 SDK 里埋点，实时上报卡顿事件和延迟数据。这样不用等用户投诉，自己就能发现问题。
1.4 本章知识体系
下面这张图，把本章的核心知识点串起来了。你可以把它当作一个思维导图，方便回顾。
这张图把本章的三个核心模块串起来了。你从「流媒体性能优化」出发，先搞清楚选什么协议，再分析延迟和卡顿从哪来，最后用指标量化效果。嗯，这就是咱们后续所有优化的基础。
本章小结：流媒体优化不是玄学，是有章可循的工程实践。协议选型决定了你的天花板，延迟和卡顿分析决定了你的优化方向，指标定义决定了你的优化效果。这三件事做好了，后面的事情就顺了。