7.1.5 三容器设计取向对比（Three Containers, Three Philosophies）
三份答卷已经摊开：MP4 的索引树、FLV 的 Tag 流、TS 的定长包。它们回答的是同一组问题——7.1.1 的索引、同步、复用与自描述——答案却几乎处处相反。把三份答案并排摆开，一条主线浮出水面：格式的每一处取舍，都能在它的目标场景里找到根因。
五维对照
| 维度 | MP4 | FLV | MPEG-TS |
|---|---|---|---|
| 定位场景 | 存储与点播 | 流式传输 | 广播与容错传输 |
| 索引方式 | moov 集中索引，随机访问 | 顺序扫描 + PreviousTagSize 回退 | 无索引；sync_byte + PUSI 任点切入 |
| 时间基准 | 各轨 timescale，stts/ctts 增量表 | 毫秒绝对时间戳（24+8 bit） | 90 kHz PTS/DTS + 27 MHz PCR 对钟 |
| 复用方式 | trak 静态分轨，类型不限 | Tag 类型分流，至多一音一视 | PID 动态复用，多节目数十路 |
| 容错能力 | 无（索引坏则全盘皆输） | 弱（单 Tag 损坏影响局部） | 强（重同步 + 连续计数 + PSI 重播） |
场景如何塑造格式
表格的每一行，都值得追问一句 "为什么恰好是这样"：
索引的深浅，由消费方式决定。 点播的用户会拖进度条，MP4 便把索引做到完全体——五张表接力，一次 seek 一次寻道；流式消费从头看到尾，FLV 只留一条回退链应急；广播根本没有 "回头" 的概念，TS 干脆不要索引，把功夫全下在 "任意点切入" 上——sync_byte 负责字节级重对齐，PUSI 负责内容级起点标记，PSI 周期重播负责补齐节目目录。三种深浅，恰好对应三种观看姿势。
时间的形态，由信道假设决定。 文件在手、随时翻页，MP4 可以用相对增量慢慢算（stts/ctts）；数据流单向奔涌，FLV 选择每个 Tag 自带绝对毫秒时刻，随到随判；信道连协商都没有，TS 只好把发送端的钟（PCR）随包寄出，让接收端锁相对钟。同步职责的三种实现，本质是 "接收端能信任什么" 的三种回答。
复用的宽窄，由内容规模决定。 MP4 的 trak 是一张静态清单，一部电影几条轨屈指可数；FLV 砍到一音一视，因为直播流本来就是一条一路；TS 的 PID 寻址则要撑起广电级别的胃口——同一路信号里几十套节目并行，机顶盒按 PID 滤出观众选中的那一套，其余原样流过。
容错的强弱，由重传的代价决定。 MP4 假设磁盘与文件系统可靠，索性把鸡蛋全放进 moov 一个篮子；FLV 假设 TCP 兜底，局部损坏顶多花屏一瞬；TS 面对的是无重传的电波，只好在每个包里都存一点冗余——定长、计数器、CRC、重播，四处补天。容错能力与信道可靠度之间，是一条严丝合缝的反比曲线。
边界正在流动
三种设计取向曾经井水不犯河水，如今却在互相借形：MP4 家族自己长出了 fMP4，把集中索引拆成分片自描述（7.4 节的主角之一），向流式场景靠拢；HLS 早年用 TS 分片、近年力推 fMP4 分片，一条协议横跨两种容器；TS 的 PID 复用思想，则在 RTP 的 SSRC 里换了一副面孔重生（7.2 节）。容器与传输的分工从来不是铁板一块——当 "装" 与 "运" 的场景开始交叠，格式之间的界限也随之流动起来。
这也给了我们观察后续各节的一副眼镜：RTP、RTMP、HLS、WebRTC 这些传输协议，并不是容器的替代品，而是站在容器肩膀上的又一层取舍——容器管 "装得下、找得到、对得齐"，传输协议管 "运得快、运得稳、运得远"。下一节，我们从实时传输的奠基者 RTP/RTCP 讲起，看它如何把同步职责从容器手里接过来，直接扛到协议层的头部字段上。