封装格式与容器：MP4、TS、FLV、MKV 的适用场景与优劣
封装格式这事儿，说白了就是视频的「包装盒」。你想想看，视频编码（H.264、H.265）是内容本身，而容器格式决定了这个内容怎么被组织、怎么被播放器解析。我在转码流水线上踩过不少容器的坑，今天就把 MP4、TS、FLV、MKV 这四种最常见的格式掰开揉碎了讲清楚。
核心观点：没有「万能」的封装格式，只有「最合适」的场景。选错了容器，轻则播放卡顿，重则兼容性翻车。
MP4：行业通用标准
MP4 是目前兼容性最好的容器格式。几乎所有设备、浏览器、播放器都支持它。我个人习惯把 MP4 作为「交付格式」的首选——尤其是需要分发给用户端播放的场景。
优势：
- 兼容性极强：从 iOS 到 Android，从 Chrome 到 Safari，通吃
- 支持元数据：封面、章节、字幕轨道都能内嵌
- 流式播放友好：支持 moov box 前置，实现边下边播
劣势：
- 录制时如果中断，文件直接损坏——我遇到过直播录制到一半服务器宕机，MP4 文件完全打不开
- 对实时场景不友好：需要写完整的 moov box 才能播放
- 字幕支持有限：虽然能内嵌，但很多播放器不认
我的经验：做点播转码时，输出 MP4 一定要做 faststart 优化，把 moov box 挪到文件头部。否则用户打开视频要等好几秒才能开始播放，体验极差。
TS：直播与实时传输的硬通货
TS（Transport Stream）这玩意儿，最初是为数字电视广播设计的。它的最大特点就是「容错」。我记得有一次做 HLS 直播流，源端网络抖动得厉害，但 TS 切片愣是没丢帧——因为它每个包都是独立的。
优势：
- 抗丢包能力强：每个 TS 包（188 字节）都可以独立解码
- 支持实时录制：录制过程中断，已录制的部分依然可用
- HLS 标准切片格式：苹果钦定的直播流容器
劣势：
- 文件体积大：因为每个包都带完整头部信息，冗余度高
- 播放器支持差：浏览器原生不支持直接播放 .ts 文件
- 元数据支持弱：封面、章节这些基本别想
避坑指南：我曾经把 TS 直接给用户下载，结果对方用手机打不开，投诉说「视频坏了」。后来我学乖了——TS 只用在传输链路里，最终交付必须转成 MP4。
FLV：Flash 时代的遗产，但还没死透
FLV 是 Adobe Flash 时代的产物。按理说 Flash 都凉了，FLV 也该退场了。但奇怪的是，它在直播领域活得还挺好——因为 RTMP 协议默认就用 FLV 封装。
优势：
- 结构简单：头部 + 标签体，解析成本极低
- 延迟低：适合 RTMP 推流，端到端延迟可以做到 1 秒以内
- 支持脚本数据：可以内嵌 AMF 格式的元数据
劣势：
- 浏览器不支持：除非你还在用 Flash Player
- 编码支持有限：H.265、VP9 这些新编码基本不兼容
- 文件体积大：同样的内容，FLV 比 MP4 大 10%-20%
我的建议：如果你还在用 FLV 做直播推流，可以考虑转成 fMP4（Fragmented MP4）。兼容性更好，而且支持 CMAF 标准，未来迁移成本低。
MKV：开源界的瑞士军刀
MKV（Matroska）是开源社区的作品。它几乎什么都能装：任意编码、任意字幕格式、任意章节信息。我个人很喜欢 MKV 的灵活性，但说实话，它在生产环境里用得不多。
优势：
- 功能最全：支持无限数量的视频、音频、字幕轨道
- 容错性好：即使文件损坏，也能播放未损坏的部分
- 元数据丰富：章节、标签、封面、菜单都能内嵌
劣势：
- 流式播放差：不支持边下边播，必须下载完整文件
- 浏览器不支持：需要安装插件或使用特殊播放器
- 编码兼容性：部分播放器对 MKV 内的编码支持不完整
适用场景：MKV 最适合做「存档格式」。我在做蓝光原盘转码时，会把无损音轨、多语言字幕、章节信息全部塞进 MKV 里保存。但交付给用户时，一定会转成 MP4。
四种容器格式对比
| 特性 | MP4 | TS | FLV | MKV |
|---|---|---|---|---|
| 浏览器兼容性 | ★★★★★ | ★★☆☆☆ | ★☆☆☆☆ | ★★☆☆☆ |
| 流式播放 | ★★★★☆ | ★★★★★ | ★★★☆☆ | ★☆☆☆☆ |
| 容错性 | ★★☆☆☆ | ★★★★★ | ★★★☆☆ | ★★★★☆ |
| 元数据支持 | ★★★★☆ | ★★☆☆☆ | ★★★☆☆ | ★★★★★ |
| 编码兼容性 | ★★★★★ | ★★★★☆ | ★★☆☆☆ | ★★★★★ |
| 文件体积 | 小 | 大 | 中 | 中 |
封装格式选择决策流程
下面这张图是我在实际项目中总结的决策流程。你想想看，每次选容器格式时，其实就是在问自己三个问题：用户怎么播放？网络条件如何？是否需要实时性？
实际项目中的选择策略
我在做转码平台时，总结了一套「容器格式选择策略」，分享给你：
- 点播交付：一律用 MP4，做 faststart 优化。这是最稳妥的选择。
- 直播传输：内部链路用 TS 或 FLV，边缘节点转成 HLS（TS 切片）或 DASH（fMP4 切片）。
- 存档备份：用 MKV，保留所有轨道和元数据。万一以后需要重新编码，素材都在。
- 特殊场景：比如广电设备对接，可能只能用 TS；老旧 RTMP 推流，只能选 FLV。
注意：不要在一个流程里混用多种容器格式。我见过有人推流用 FLV，录制用 TS，转码输出 MP4，最后存档又转 MKV——每次转封装都有质量损耗，虽然很小，但积少成多。
转封装时的注意事项
转封装（Remux）只是换容器，不重新编码。但有几个坑你得知道：
- 时间戳精度：不同容器的时间戳精度不同。MP4 用毫秒，TS 用 27MHz 时钟。转封装时如果精度转换不对，音画会不同步。
- 编码兼容性：不是所有编码都能放进所有容器。比如 H.265 在 FLV 里就不被官方支持，虽然有些工具能强行塞进去，但播放器不一定认。
- 元数据丢失：从 MKV 转 MP4 时，字幕、章节信息可能会丢失。我建议先提取元数据，转完再重新注入。
工具推荐：FFmpeg 是转封装的神器。比如 ffmpeg -i input.mkv -c copy output.mp4 就能快速转封装。但记得加 -movflags +faststart 参数做流式优化。
嗯，封装格式这块儿就讲这么多。记住一句话：选容器就是选场景。没有最好的格式，只有最合适的用法。