7.1 从封装说起：容器的使命（The Mission of Containers）

第六章结束时，我们手里已经握着一套完整的编码技术栈：H.264、H.265、H.266 与 AV1 能把像素压成高效的比特流，AAC 与 Opus 能让声音同样瘦身。但请留意一个此前从未深究的细节：编码器的输出只是裸码流（Elementary Stream）——一串 "如何还原画面与声音" 的解码指令。把它直接存成文件、直接发上网络，会发生什么？

答案并不乐观：你无法快进，不知道文件有多长，音视两条流各走各的钟，甚至说不清手里的文件是 H.264 还是 H.265。裸码流缺的东西，正是容器要补的课。

本节按 "问题 → 三种答案" 的顺序递进：

• 7.1.1 裸码流缺什么：索引、同步、元数据、复用——从四个具体困境出发，提炼容器的三大职责
• 7.1.2 MP4：为随机访问而生的索引树：Box 嵌套结构与 stbl 五张索引表，存储与点播场景的标准答案
• 7.1.3 FLV：为流式传输而生的标签序列：三段式 Tag 流 + PreviousTagSize 回退链，Flash 时代的轻量设计
• 7.1.4 MPEG-TS：为容错传输而生的定长包：188 字节定长、PID 复用与 PSI 表族，广播场景的不倒翁
• 7.1.5 三容器设计取向对比：同一份内容，三种封装哲学——场景如何决定格式

完成本节后，我们将带着 "场景决定封装" 的视角进入后续各节：RTP、RTMP、HLS 乃至 WebRTC，无不是在容器之上再加一层传输的考量。