硬解与软解：视频播放的两条技术路线
同事发的视频在你手机上流畅播放，在旧平板上却卡成幻灯片；反过来，另一个视频新手机也不顺。多数时候不是设备坏了，而是播放端走了不同的解码路线：硬解或软解。理解这两条路，播放卡顿的排查就有了抓手。
两条路线是什么
硬解是芯片里的专用解码电路在工作：手机 SoC 里的媒体引擎、显卡里的解码单元，为特定几种编码（H.264、HEVC、VP9、AV1 等）定制了流水线，解码过程不占用 CPU 通用核心。省电、低发热、4K 轻松，代价是“只会名单里的格式”。
软解是用通用 CPU 逐块跑解码算法：任何编码只要有算法实现就能解，不挑格式；代价是 CPU 满载、发热、耗电，高分辨率高码率时算力跟不上就掉帧。ffmpeg.wasm 这类浏览器内解码器，就是跑在 WebAssembly 里的纯软件解码。
编码世代与硬件支持的对应
硬解名单按芯片代际划分：H.264 是十多年的通用标准，几乎所有设备都支持；HEVC 需要 2015 年之后的多数中高端芯片；VP9 在近年设备普及；AV1 只有最新一代芯片支持。这解释了“为什么 HEVC 视频在旧手机上打不开”——不是文件坏了，是芯片名单里没有它。
名单之外还有封装与 Profile 的细分：同一个 H.264，Baseline/Main/High Profile 的硬解支持也可能不同；10bit 色深的 H.264 在部分老设备上同样无硬解。播放端的能力是一张二维表：编码 × Profile × 位深。
播放卡顿的排查思路
遇到卡顿或黑屏，先查文件的编码参数（用编码检测工具看编码、Profile、分辨率、码率四项），再对号入座：编码不在设备硬解名单→转 H.264；分辨率超出设备解码能力（老设备常见 4K 卡顿）→降到 1080p；参数都正常→看码率是否过高，存储卡的读取速度也可能是瓶颈。
卡顿还有一种易被忽略的原因：文件封装索引损坏或放置在末尾（moov box 后置），流式播放时需要下载完才能定位——这是封装问题不是解码问题，转封装即可解决。
浏览器本地处理的现实
在浏览器里跑 ffmpeg.wasm 处理视频，走的是纯软解：解码、滤镜、编码全在 CPU（经由 WebAssembly）上完成。好处是格式覆盖面广、不受芯片名单限制；代价是速度受 CPU 性能约束，大码率视频的处理时间明显更长。
浏览器的另一条硬件路线是 WebCodecs：浏览器把硬件编码器/解码器暴露给网页程序，符合条件的工具链路会优先调用硬件编码（速度接近本地软件的极限）。同一个工具在不同浏览器、不同设备上的处理路径可能不同，这是环境探测自动选择的正常行为。
硬解软解与文件选择的策略
为“给谁看”选编码，就是在选对方设备的硬解名单：发给不特定人群的内容用 H.264（名单覆盖率接近全员）；确定接收方都是新设备可以考虑 HEVC/AV1 换更高压缩率；存档母带可以选压缩率更高的编码，但播放时接受软解的算力代价。
反方向也成立：拿到打不开或卡顿的文件，第一反应是“对方设备硬解名单里有没有这个编码”，而不是文件损坏。先检测、再转换，多数“放不出来”的问题十分钟内可以解决。
常见误解澄清
误解一：“硬解画质比软解差”。现代硬件解码器在标准实现下输出一致，个别老芯片边缘行为有差异，日常观看不可分辨。误解二：“卡顿就是设备不行”。很多时候是编码不在名单、码率超能力、封装索引后置三类文件侧问题——先查文件再怪设备。
误解三：“浏览器处理视频一定很慢”。软解路径确实受 CPU 限制，但硬编路径（WebCodecs 可用时）的速度已接近桌面软件；处理速度取决于走了哪条路线，以及源视频的编码与分辨率。