HANDBOOK 03
在快播盒子里理解容器与编码的分工
把这一层关系想明白，「为什么这台能播那台不能」就不再是玄学。
盒子与盒子里的东西
容器是外面那个盒子：.mp4、.mkv、.webm、.avi、.ts。它负责把视频轨、音频轨、字幕轨、章节信息打包在一起，并记录它们的时间对应关系。
编码是盒子里每条轨道实际使用的压缩方式：视频常见 H.264、HEVC、VP9、AV1，音频常见 AAC、AC-3、E-AC-3、DTS、FLAC、Opus。
关键在于这两层是正交的。同一路 H.264 视频，封进 mp4 几乎处处能播，封进 mkv 就要看浏览器认不认这个容器——换的不是编码，是盒子。反过来，同样是 .mp4，里面装的是 H.264 还是 HEVC，结果也可能完全不同。
所以判断一个文件能不能播，要问两遍：这个盒子打得开吗？盒子里那几条轨解得了吗？两遍都过才能播。
常见组合与它们的处境
下面是普遍规律，具体到你这台设备，以格式自检台的现场结果为准。
| 容器 | 典型内容 | 在浏览器里的一般处境 |
|---|---|---|
.mp4 | H.264 + AAC | 支持面最宽的一组，网页播放的默认选择 |
.mp4 | HEVC + AAC | 要系统和硬件一起配合，差异最大的一类 |
.mp4 | AV1 + Opus | 较新的浏览器多半能软解，耗电高 |
.webm | VP9 + Opus | 开放格式，桌面浏览器支持普遍不错 |
.mkv | 什么都能装 | 不同浏览器与版本差别极大，必须现场测，不能凭印象 |
.avi / .rmvb / .wmv | 老格式 | 基本不被现代浏览器接受 |
.ts | H.264 + AAC | 录播与直播切片常用，浏览器直接播的支持有限 |
设备差异是从哪来的
能不能解码，取决于三样东西的交集：浏览器内核愿不愿意支持、操作系统有没有提供解码器、硬件有没有对应的解码单元。任何一环缺位，结果就是不支持。
- HEVC 差异最大。它牵涉专利授权，不同浏览器、不同系统版本的态度都不一样，而且常常依赖硬件解码。这就是为什么同一个 HEVC 文件在一台设备上流畅、另一台上直接黑屏。
- AV1 依赖浏览器版本。新版本软解没问题，老版本完全不认。它不怎么依赖硬件，但软解很吃电。
- H.264 最稳。二十年下来几乎所有能播视频的设备都支持它。这也是本站示例短片选它的原因：它要是也播不了，问题就不在编码这一层了。
不要相信任何「某某型号支持某某编码」的通用名单，包括这一页。系统更新、浏览器更新、同型号不同批次的解码芯片，都会让结论失效。唯一可靠的办法是拿那台设备自己测一遍。
自己探测浏览器能力
浏览器提供了 canPlayType 这个方法，传一个 MIME 字符串给它，它回答 probably、maybe 或者空字符串。注意它没有「一定能」这一档——规范就是这么定的，因为真正能不能播要到解码那一刻才知道。
const v = document.createElement('video');
v.canPlayType('video/mp4; codecs="avc1.640028"'); // 多半返回 probably
v.canPlayType('video/x-matroska'); // 多半返回空字符串codecs 参数写得越细，答案越有参考价值。只写 video/mp4 通常只能换回 maybe，因为浏览器不知道里面装的是什么。格式自检台把二十多组常见组合一次问完，并且有个输入框让你测任意 MIME。