03. 编码、容器与在线格式
压缩编码解决“数据太大”，容器解决“如何把多条轨道和时间信息组织起来”，在线格式解决“怎样交付给播放器”。选型时先问目标是存档、局域网预览还是公网分发，再看设备和浏览器支持。
视频编码
视频压缩同时利用空间冗余和时间冗余：
| 单元 | 主要作用 | 对随机访问的影响 |
|---|---|---|
| I 帧 | 只依赖帧内信息 | 可以作为访问起点，但不一定是 IDR |
| P 帧 | 参考已编码的前后关系中的参考帧 | 体积小，依赖参考帧 |
| B 帧 | 可双向参考 | 压缩率高，但会增加重排和延迟 |
GOP 是一段连续图像的编码结构。H.264 中的 IDR 是常见的随机访问边界，不能把所有 I 帧都当成 IDR。GOP 越长通常越省码率，但切流、丢包恢复和首帧等待会变差；直播要按恢复时间和带宽一起定关键帧间隔。
H.265/HEVC 在合适的质量目标下常能用更低码率表达相近画面，但编码计算、硬件支持和终端兼容性必须实测。浏览器、硬件解码器和播放器支持会随平台与版本变化，不能写成绝对的“支持”或“不支持”。
音频编码
AAC 是有损音频编码族。AAC-LC 常用于音乐、点播和设备录制；HE-AAC 通过额外工具面向较低码率场景。码率、声道、算法延迟和目标设备支持要一起评估。低延迟语音还应比较 Opus，而不是只在 AAC 与 MP3 之间做名称对比。
AAC 码流可以放进 MP4，也可以使用 ADTS 等结构传输。封装形式和编码配置是两件事：改变容器不等于改变 AAC 配置，播放器支持的也可能只是其中一部分。
容器与交付格式
| 名称 | 它是什么 | 典型用途 | 需要额外核对 |
|---|---|---|---|
| MP4 | ISO BMFF 的常见容器 | 点播、存档、下载 | moov 位置、Range、MIME 和轨道 Codec |
| FLV | 容器格式 | 直播服务内部或 HTTP-FLV | 音视频 Codec 是否适配目标服务 |
| HLS | m3u8 播放列表加媒体分片的交付机制 | 公网点播、直播分发 | 分片时长、缓存、TS/fMP4 和播放器能力 |
| MKV | 灵活的 Matroska 容器 | 本地存档、调试 | 目标设备对轨道和字幕的支持 |
HTTP-FLV 不是一种视频编码，而是通过 HTTP 持续传输 FLV 数据。HLS 也不是一个单独的视频文件，播放列表会指向多个媒体分片。MP4 能否边下边播，取决于索引布局和服务器是否正确支持 Range。
选择时的判断
- 需要长期保存和下载：先确认 MP4/MKV 对目标 Codec、索引和元数据的支持。
- 需要局域网摄像头预览：先验证 RTSP/RTP，再决定是否转成浏览器能直接播放的格式。
- 需要大规模公网分发：把 HLS 的缓存和分片开销纳入端到端延迟预算。
- 需要低延迟双向互动：优先评估 WebRTC 的 ICE、TURN、DTLS、SRTP 和带宽反馈。
所有比较都要固定输入、分辨率、质量目标和终端。只比较文件大小，不能证明画质或延迟更好。
下一篇把这些格式放进推流、源站、CDN 和拉流链路，说明协议选择与延迟的关系。