1. 系统概述与性能指标
各位同学好，我是老张。做多媒体流系统性能优化这行，掐指一算也有十几年了。今天咱们开始第一讲，先把地基打牢——聊聊系统长什么样，以及我们到底该关注哪些指标。
说实话，我见过太多团队一上来就调参数、改代码，结果折腾半天发现瓶颈根本不在那。为什么？因为连系统架构都没搞清楚，性能目标也是拍脑袋定的。所以这一章，咱们先把这些基础问题理清楚。
1.1 多媒体流系统架构
一个典型的多媒体流系统，说白了就是一条数据流水线。从采集到播放，中间经过编码、传输、解码、渲染这几个核心环节。我习惯把它分成四个逻辑层：
- 采集层：摄像头、麦克风、屏幕录制等源设备，负责原始音视频数据的获取。
- 处理层：编码、转码、封装、解封装、解码等计算密集型操作。
- 传输层：网络协议栈、CDN、P2P 等，负责数据包的可靠或不可靠传递。
- 呈现层：渲染、同步、播放控制，最终呈现给用户。
嗯，这里要注意：每一层都可能成为瓶颈。我在项目中遇到过好几次，大家拼命优化编码器，结果发现是网络丢包导致花屏——方向完全错了。
下面这张图，是我自己画的一个简化架构，你可以对照着理解：
你看，数据从采集层一路往下流到呈现层。但实际系统中，还有反馈回路——比如接收端会通过 RTCP 告诉发送端网络状况，从而调整编码码率。这个我们后面章节会细讲。
1.2 关键性能指标
做性能分析，你得先知道「好」和「坏」怎么定义。多媒体流系统有四个核心指标，我管它们叫「四大金刚」：
| 指标 | 英文 | 单位 | 通俗理解 |
|---|---|---|---|
| 延迟 | Latency | ms | 从采集到播放，等了多久 |
| 吞吐量 | Throughput | Mbps / fps | 单位时间能处理多少数据 |
| 抖动 | Jitter | ms | 延迟的波动幅度 |
| 丢包率 | Packet Loss Rate | % | 数据包在传输中丢失的比例 |
这四个指标不是孤立的，它们之间会互相影响。举个例子：你为了降低延迟，把缓冲区设得很小，结果网络一波动就丢包，画面反而卡顿。这就是典型的「按下葫芦浮起瓢」。
核心原则：性能优化不是追求单个指标极致，而是在四个指标之间找到平衡点，满足业务场景的实际需求。
1.2.1 延迟
延迟是用户最直观的感受。你想想看，视频通话里对方说完话你等两秒才听到，这体验能好吗？
延迟可以细分为几个阶段：
- 采集延迟：从物理世界到数字信号的时间，比如摄像头 CMOS 曝光时间。
- 编码延迟：编码器处理一帧所需的时间。帧内编码比帧间编码快，但压缩率低。
- 网络传输延迟：数据包从发送端到接收端的物理传播时间 + 排队时间。
- 解码渲染延迟：解码器解出图像 + 显示到屏幕的时间。
我记得有一次做远程手术直播项目，要求端到端延迟低于 100ms。我们测出来编码延迟就占了 40ms，后来换成硬件编码器才压下来。所以你看，分析延迟一定要拆解到每个环节。
1.2.2 吞吐量
吞吐量决定了系统能支持多少路并发流，或者多高的分辨率/帧率。常见的衡量方式有两种：
- 数据吞吐量：单位时间传输的数据量，单位 Mbps。
- 帧率吞吐量：单位时间处理的帧数，单位 fps。
这里有个坑：很多人只看数据吞吐量，忽略了帧率。我曾经遇到一个项目，码率只有 2Mbps，但分辨率是 4K，结果画面全是马赛克。为什么？因为码率不够，编码器只能大幅降低画质来满足帧率要求。
我的经验：评估吞吐量时，一定要同时看「分辨率 × 帧率 × 码率」这个三角关系。任何一个角被压得太低，都会影响最终体验。
1.2.3 抖动
抖动，说白了就是延迟的「忽快忽慢」。它比高延迟更讨厌——高延迟你还能适应，但抖动会让你感觉画面一卡一卡的。
抖动的主要来源：
- 网络抖动：路由器排队、链路切换、无线信号波动。
- 处理抖动：CPU 调度、编解码器处理时间不稳定。
- 时钟抖动：发送端和接收端的时钟不同步。
应对抖动，最常用的手段就是抖动缓冲区（Jitter Buffer）。但缓冲区设多大是个学问——设大了延迟高，设小了抗抖动能力差。我一般建议先测量实际网络抖动值，然后设成 1.5 倍左右。
1.2.4 丢包率
丢包率，就是数据包在传输过程中「失踪」的比例。对于视频来说，丢包会导致花屏、马赛克；对于音频来说，丢包会导致声音断续、杂音。
不同场景对丢包率的容忍度不一样：
| 场景 | 可容忍丢包率 | 说明 |
|---|---|---|
| 直播 | < 1% | 丢包会直接体现在画面上 |
| 视频通话 | < 3% | 可以通过 FEC 和重传恢复 |
| VoIP 语音 | < 5% | 人耳对语音丢包有一定容忍度 |
| 文件传输 | 0% | 必须可靠传输，不允许丢包 |
注意：丢包率和延迟之间存在 trade-off。比如你开启 ARQ（自动重传请求），丢包率会下降，但重传带来的额外延迟可能让实时性变差。我曾经在项目中把重传次数从 3 次改成 2 次，丢包率从 0.1% 升到 0.3%，但延迟从 200ms 降到了 120ms——对于视频通话来说，这个交换是值得的。
1.3 性能目标设定
指标知道了，怎么定目标？我见过不少团队直接抄网上的「最佳实践」——延迟 100ms、丢包率 0.1%……结果要么达不到，要么达到了但用户还是不满意。
定目标，得看业务场景：
- 实时互动（视频通话、云游戏）：延迟 < 150ms，抖动 < 30ms，丢包率 < 1%。
- 直播（赛事、演唱会）：延迟 < 5s（传统 HLS），或 < 2s（低延迟直播），丢包率 < 0.5%。
- 点播（视频网站）：首帧时间 < 2s，卡顿率 < 2%，丢包率 < 0.1%。
- 监控（安防、工业）：延迟 < 500ms，连续丢帧数 < 3 帧。
你看，差别很大。实时互动对延迟极其敏感，但对丢包率可以稍微放宽——因为可以用 FEC 和 PLC（丢包隐藏）来弥补。而点播场景，用户更在意的是「点开就能看」和「别卡」，延迟反而不是首要问题。
我的建议：先定一个「可接受」的底线，再定一个「理想」的目标。比如视频通话，底线是延迟 < 300ms，理想是 < 100ms。这样优化起来有层次，不会一上来就追求极致。
好，这一章的内容就到这里。记住：架构是骨架，指标是尺子，目标是方向。这三样东西没搞清楚，后面的优化都是瞎忙活。