1. 为什么现在还有人在 Web 端研究 H265 软解码先说个实际场景最近接了个播放器需求要在一个网页里播放一批安防摄像头导出的录像文件。摄像机那哥们儿给的视频流清一色 H265 编码分辨率不高但数量不少而且要求拖到哪一帧都能立刻看。听起来挺常规的活儿结果第一步就卡住了——浏览器原生支持的视频编码就那么几种H265 并不在其中。拿 Chrome 直接塞一个.mp4进去视频控件能加载画面大概率是黑屏控制台里还会蹦出Cant play video之类的提示。这不是个别现象。H264 是十几年前的老将浏览器全都支持H265 压缩率更好尤其在监控领域几乎成了默认编码然而浏览器厂商因为专利授权、实现成本这些原因始终没有把 H265 的硬解能力做成默认开放的能力。就算部分浏览器在 MSE 里能播放 H265 的 TS 流那也是看环境换到 MP4 封装、换到某些浏览器版本又不行了。指望浏览器原生支持这条路不确定性太大。于是软解码成了最稳的保底方案不依赖浏览器原生编解码器把解码这一层完全拿过来自己做。听起来有点倒退——都什么年代了还拿 CPU 解视频但在 Web 场景里软解码意味着可控解码库可以用 WASM 方式独立集成不挂靠在浏览器的黑盒上行为完全由你自己掌控。这篇文章我想把整套思路从头到尾理一遍包括解码器到底在干什么、为什么选 WASM 这条路、具体怎么落地、以及我踩过的几个最隐蔽的坑。对前端开发、音视频从业者、还有做监控或车载录像系统对接的朋友这篇应该都能直接当参考材料用。2. 先搞明白软解码这三个字到底在解什么2.1 H265 压缩原理的极简版要想理解软解码起码得知道解码器面对着什么样的数据。H265也叫 HEVC本质上是一个从像素块推算出像素块的编解码协议。编码端会把画面切成一个个编码树单元CTU每个 CU 可以是 64x64、32x32、16x16 甚至更小然后对每个块做预测、变换、量化、熵编码。预测分两种帧内预测用同一帧里已经解码的相邻像素去推测当前块帧间预测用参考帧里的像素块去推测再记录一个运动矢量表示这个块从上一帧的哪个位置挪过来的。解码端做的是完全镜像的操作先熵解码拿到残差系数再去反量化、反变换恢复出残差像素接着根据运动补偿或者帧内预测模式从参考帧或当前帧已解码区域拉出预测像素。预测像素加残差像素就得出了重建像素。这个过程没有任何魔法纯粹是 CPU 按照标准里定义好的数学公式一步步算出来的。软解码之所以比硬解慢不是因为算法更复杂而是硬解在芯片里用并行电路干这件事软解只是让通用 CPU 用 SIMD 指令去模拟这个过程效率天然有差距。2.2 解码器面前的数据长什么样播放器接收到的文件或者流不是一帧一帧干净的 YUV 数据而是封装层 编码层的混合体。拿最常见的 MP4 封装来说里面有一串 sample每个 sample 是一个或几个 NALU 的打包体。NALU 是 H265 基本单元头里带一个 2 字节的 NAL header前 6 位是 nal_unit_type标识这个 NALU 是 SPS、PPS、IDR 帧、非 IDR 帧还是其他类型。解码流程里有个容易被忽略的顺序问题SPS序列参数集和 PPS图像参数集必须比帧数据先到。SPS 里写明了分辨率、帧率、profile、levelPPS 里写了熵编码模式、预测相关参数。解码器不拿到这两个 NALU遇到帧数据也只能干瞪眼。很多人在 Web 端自己解析 H265 时发现怎么第一个 IDR 帧也黑屏排查一圈才发现是丢掉了 SPS/PPS或者把它们放在了错误的位置。帧与帧之间还有个编码顺序和显示顺序的差异。编码器为了压缩效率会引入 B 帧它会参考未来的帧所以输入码流的帧顺序不一定是显示顺序。解码器输出的帧也不能直接按序上屏要看每帧的 PTS显示时间戳。软解码方案里如果你不管 PTS 直接按解码顺序画画面动作就是跳跃的、扭曲的。这是新手最容易困惑的地方明明解码器没报错看起来却不对劲。2.3 所以软解码的完整链路是什么放在 Web 这个环境里完整链路是拿到的封装文件 → 解封装提取 H265 裸流也就是一个个 NALU→ 喂给解码器 → 解码器输出 YUV 帧 → 做像素格式转换一般是 YUV 转 RGB/RGBA→ 通过 Canvas 渲染上屏或者转成 video 帧再上屏。注意解封装和解码是两件事。有人把文件往解码器里一丢就想出画面那是上了 FFmpeg 的当——FFmpeg 的 API 通常把解封装和解码包在了一起可你要是用轻量级的纯解码库比如只解码 H265 的独立库就必须自己先做封装解析。前端工程里最常见的组合是用 mp4box 之类的库解析 MP4 拿 sample然后用 WASM 版解码器处理 sample 里的 NALU。这里还要处理 Annex-B 格式和 AVCC 格式的 NALU 长度字段差异MP4 里面 NALU 用的是 4 字节长度前缀裸流文件用的可能是 3 字节起始码。这个细节不处理好解码器会各种报错。3. 技术选型为什么我没有选 WebCodecs而是选了 WASM先说结论在 2024 年的浏览器环境下三条主流路线都有应用场景但没有一条是全设备通吃的。3.1 WebCodecs官方 API 的诱惑与限制WebCodecs 是浏览器给 Web 开发者开的解码后门通过VideoDecoder接口直接调用浏览器内核的解码能力。它最大的优势是性能好、内存管理省心而且 API 设计比较现代。但问题也很直接VideoDecoder是否能解 H265取决于浏览器是否实现了对应 codec 且系统是否提供解码器。Chrome 在桌面端很多时候能触发但移动端、某些系统上就是不支持该 codecSafari 自己有一套私有的实现Firefox 则长期没太大动静。所以 WebCodecs 目前更适合做成检测到能用就用不能用就走软解的双轨方案。要是你只依赖它遇到不支持的环境就彻底挂了。我自己的做法是 WebCodecs 做前锋后端加一个软解兜底。3.2 WASM FFmpeg最通用的软解路径业界流传最广的 Web 软解方案是把 FFmpeg 裁剪后通过 Emscripten 编译成 WASM。它的好处是强悍FFmpeg 库对 H265 的支持成熟各种奇奇怪怪的 profile、像素格式都见过解封装、解码、滤镜在 FFmpeg 里都是现成的。缺点是体积大完整的 libavcodec 编译出来可能好几 MB就算 gzip 完也得一两 MB对首屏加载有压力。代价是可裁剪的。用 configure 参数--disable-everything再把用不到的功能全关掉只留 H265 解封装和解码可以把 WASM 体积控制到一个可接受的范围。我实测过只保留 HEVC 解码、MP4/FLV 解封装、必要的解析器最终产物 gzip 后可以压到几百 KB 这个量级加载成本完全可以接受。这就是为什么大家宁可费劲裁剪也要用 FFmpeg——项目基本全是现成的不用自己啃 H265 标准的每一行字。3.3 为什么不直接用自研解码器或现成封装自研一个 H265 解码器属于硬核玩家的选择——从标准的 2000 多页文档里把参考模型算法工程化这绝对是几十人月的工作量还要处理各种厂商编码器的边界情况监控摄像头和海思芯片出来的码流经常带奇怪的 SEI 和参考帧结构。除非你是在做课题研究否则真不建议在业务里走这条路。现成封装方案也不是没有比如纯 JS 实现的 H265 播放组件或者基于 libde265 的 WASM 封装。它们的优点是接入快十几行代码就能出画。但问题在于这类封装通常把像素转换、渲染也一起做了遇到帧率不稳、码流特殊的情况你很难定位是解码器的问题还是渲染层的问题。而且很多封装不支持自定义 Worker 调度性能上限被卡死在单线程里。对我来说既然最后还是要做多线程和帧缓冲优化不如直接从 FFmpeg 这套更透明的底座开始。三条路线我最后的选择组合是优先探测 WebCodecs 硬解不支持则自动切换 WASM 软解。这个架构在绝大多数设备上都能稳定播放同时保住了极端情况的下限。方案性能兼容性开发成本适合场景WebCodecs高看浏览器实现不稳定低有 H265 硬解的设备WASM FFmpeg中但可控只要有 WASM 就行覆盖面最广中设备不统一、需要稳定下限自研纯 JS 解码低高极高学习/研究性质项目4. 实操从编译解码器到把第一帧画到 Canvas 上4.1 环境准备与 FFmpeg 裁剪编译这一步是整个项目里最像工程的地方。我用的是 Emscripten 工具链从 FFmpeg 源码开始交叉编译。如果你不想读长文档下面这套 configure 参数可以直接参考emconfigure ./configure \ --disable-everything \ --enable-decoderhevc \ --enable-parserhevc \ --enable-demuxermov \ --enable-protocolfile \ --enable-pthreads \ --enable-wasm \ --ccemcc \ --disable-programs \ --disable-doc \ --disable-debug \ --disable-asm \ --target-osnone \ --archx86_32几个参数逐个说下理由。--disable-everything先关掉全部功能再按需打开hevc解码器、parser、MP4 解封装是为了避免把 H264、AAC 这类乱七八糟的东西也编进去体积差异非常明显。--enable-pthreads对应的是 WASM 多线程支持不加这个的话解码器只能用单核性能折一半不止。--disable-asm会关闭汇编优化别慌WASM 环境本来也跑不了 x86 汇编加上这个参数纯粹是让编译过程不在汇编检测上出幺蛾子。编译出来的产物通常是一个.js加一个.wasm。前者是 Emscripten 的胶水层负责把 C 函数的调用封装成 JS 可调的 wrapper后者才是真正的解码逻辑。4.2 初始化解码器从文件到裸流在 JS 里初始化 FFmpeg 的 WASM 模块一般是这样import createFFmpeg from ffmpeg/ffmpeg; const ffmpeg createFFmpeg({ corePath: /wasm/ffmpeg-core.js, mainName: main, worker: true, }); await ffmpeg.load();注意worker: true——FFmpeg 的解码跑在 Web Worker 里这样主线程不会因为解码计算卡到掉帧。这一步做完基本就可以把文件二进制喂进去了。如果你手里的是一个完好的 MP4 文件直接让 FFmpeg 走avformat_open_input那套解封装流程就行先打开输入avformat_find_stream_info找到视频流拿到AVCodecParameters然后用avcodec_find_decoder搭配avcodec_open2打开解码器。这一整套接口在 WASM 里都能通过导出的 C 函数调用只是参数传递稍微麻烦——因为指针和内存都在 WASM heap 里JS 侧要用_malloc、HEAPU8.set这些方式把数据拷进去。这个过程我习惯把它封装成一个小类对外只暴露decode(buffer)和getFrame()两个方法。4.3 Worker 循环送包、取帧、转像素、渲染解码循环的核心逻辑是不断把 PTS 有序的包喂给avcodec_send_packet再循环调用avcodec_receive_frame拿解码后的帧。注意send_packet和receive_frame不是一一对应的一个包可能产生一帧也可能产生零帧比如 B 帧顺序还没到所以要循环receive到返回AVERROR(EAGAIN)为止才算处理完当前包。拿到的帧默认是 YUV 格式最常见的布局是 YUV420P也就是一个 Y 平面加两个色度平面。Canvas 的 2D 上下文不支持 YUV 直接绘制必须先转换成 RGBA然后再通过ImageData拿到putImageData或drawImage去渲染。我不想在 JS 里逐像素地转——那太慢了——而是直接在 WASM 侧写一个yuv420pToRgba的小函数用 C 的指针挨个处理每次转换只做一次 heap 内存拷贝。这一步在软解码架构里是高开销但不是最高开销后面会细说。while (true) { const ret ffmpeg._avcodec_receive_frame(ctx, frame); if (ret -11) break; // EAGAIN说明需要送下一个包 if (ret 0) throw new Error(解码错误: ret); ffmpeg._yuv420p_to_rgba(frame, rgbaBuffer, width, height); const imageData new ImageData(new Uint8ClampedArray(rgbaBuffer), width, height); offscreenCtx.putImageData(imageData, 0, 0); }这段代码是核心循环的简化版实际项目里要考虑 Worker 间通信解码在解码 Worker渲染可能想放另一个 Worker 里干中间通过transferable把 ArrayBuffer 传过去可以避免拷贝大数组。4.4 让软解码不卡的关键多线程与 SharedArrayBufferFFmpeg 的 H265 解码器本身支持多线程解码一个 slice 用一核但 WASM 场景下要真正跑起来需要页面处于跨源隔离的环境也就是服务端要返回这两个响应头Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp没有这两个头SharedArrayBuffer 用不了Emscripten 的 pthread 多线程也就跑不起来。很多人死活开不了多线程90% 都是因为这个头没配。如果你不想动服务端退而求其次还可以用解码 Worker 池的方式拆成多个 Worker每个 Worker 各解一段 GOP最后主线程再按 PTS 合并排序。这种方案绕开了 SAB 限制但实现复杂度和同步成本都不低我通常先配头实在无法配头才走 Worker 池。5. 性能瓶颈到底卡在哪几个地方5.1 解码本身不是最大的瓶颈写软解码之前很多人直观以为瓶颈是解码器本身——毕竟 H265 复杂度摆在那。但实际跑起来你会发现解码一个 1080p30 的 H265 流现代桌面 CPU 其实能轻松跑到三四十帧真正把帧率拖垮的反而是数据转换和拷贝。先说像素转换。YUV420P 转 RGBA1080p 一帧需要处理 1920x1080 个像素每个像素要做三次左右的乘加运算。如果纯用 JS 写循环一帧大概要几十毫秒用 C 在 WASM 里转能快一个数量级。但就算 WASM 里转一帧也得 5 到 10 毫秒这已经占到 33 毫秒预算的三分之一了。做软解的时候能少转一次格式就少转一次。比如有些解码器能直接输出 NV12你就不要强行转成 YUV420P 再转 RGBA能直接 YUV 上屏的地方就少走一步。再说拷贝。FFmpeg 解码输出的帧内存和你的渲染 Buffer 是两个空间中间至少要 memcpy 一次。如果你用copyToHeap这种接口去拿解码数据它可能又多了一次拷贝。我建议是把 WASM heap 里的帧结构直接用指针拿到渲染端让 Canvas 用texImage2D直接读那个地址的数据省掉中途复制。5.2 帧缓冲策略这个坑会越蓄越深软解码最典型的翻车现场是播放器跑着左下角是监控画面内存占用像血压一样持续走高延迟越来越大。原因通常是解码端送包太快渲染端跟不上中间队列里的帧越积越多。我的处理策略是控制输入流速度解码 Worker 每解码出一帧不会立刻往渲染端丢而是先放入一个有长度上限的待渲染队列队列长度超过比如 3 帧时解码 Worker 就暂时不向 FFmpeg 送新包等渲染端消费掉一帧再继续。这比简单丢帧更稳妥因为 H265 的参考帧结构意味着你不能随便丢帧丢掉非参考帧还好丢掉参考帧后面的帧全得跟着花屏。另一个经验是优先丢 P 帧而不是 B 帧如果确实要降负载可以主动跳掉一部分非关键帧用 FFmpeg 的帧级选项把参考帧保留后面画面能保持基本完整。监控场景对这个容忍度很高但电影场景就得谨慎了。5.3 实测下来的数据参考我拿一台普通配置的笔记本做过一轮实测解码一个 1080p、30fps、码率 4Mbps 的 H265 监控流单线程解码CPU 占用约 60% 到 70%掉帧明显开启两个解码线程后解码部分降到了 25% 到 35%能跑满 30fps再加上正确的像素转换方案整条链路的 CPU 占用可以控制在 40% 上下。注意这只是软解部分如果渲染端还有 WebGL 滤镜、页面 UI 动画CPU 预算还要往上加。如果目标设备是性能很弱的机型建议做降级策略检测到解码耗时超过阈值时把分辨率降到 720p帧率降到 15fps牺牲画质保住流畅。这个逻辑在软解方案里不难实现因为解码前你可以先按分辨率判断是否需要缩放。6. 一堆隐蔽的坑逐个记下来免得你重踩6.1 颜色空间和像素格式的坑H265 解码出的常见格式并不只有 YUV420P还可能输出 YUV422、YUV444而且现在的监控摄像头动不动就是 10bit 的 YUV420P。10bit 的 YUV 数据不能直接按 8bit 处理否则画面偏色或者出现诡异的色带。我在前端踩过一次用 8bit 的查找表去转换 10bit 帧画面一片绿中带紫排查了大半天才发现是位深问题。对策是解码后先检查frame-format遇到 10bit 就先做一次位深转换再处理 YUV 到 RGB。颜色空间里还有个 BT.601 与 BT.709 之分。标准清晰度视频通常按 BT.601 转 RGB高清视频用 BT.709 转 RGB。FFmpeg 解码时会给帧带上 colorspace 标记但很多转码站没有正确写入这个标记导致解码端拿到的是默认值。结果就是同样的 YUV 数据有的画面发灰有的饱和度过高。通用解法是如果发现标记缺失或为AVCOL_SPC_UNSPECIFIED就按 BT.709 来转因为绝大多数 H265 内容都是高清以上。6.2 内存泄漏的正确排查姿势WASM 内存泄漏和普通 JS 泄漏不太一样。JS 引擎的 GC 会自己清理WASM heap 里的 C 内存完全靠自己管理。如果你每次解码都_malloc一个新 buffer 又忘记_free页面内存会一路飙升直到崩溃。排查方法也别靠看任务管理器直接在代码里统计每次解码前后的_get_total_memory()看差值是不是持续增长。解码帧本身也是要释放的av_frame_free必须每帧都调而且要注意在消费完帧数据之后再释放。很多人把av_frame_free写在 Worker 的传输回调外面结果渲染端还没拿到数据内存就被塞回去了表现出来就是画面抖动加偶发花屏。6.3 兼容性边界不是所有 H265 流都能喂同一个解码器H265 有好几个 profileMain、Main 10、Main Still Picture 等还有不同的 tier 和 level。FFmpeg 的 hevc 解码器绝大部分都能吃但 Main 10 的位深转换、高分辨率下的 level 限制这些都需要你提前判断。另外监控摄像头对流结构普遍不太讲究码流里可能没有 SPS/PPS或者在关键帧之前插了一堆自定义 SEI。我的一个建议是尽量在解析阶段就把 SPS/PPS 规范化如果源流缺失尝试从容器的时间信息或扩展数据里补实在补不了就提前给用户一个无法识别该视频流的明确提示而不是卡在那黑屏。还有一种情况是编码器用了参考帧重排序的奇怪配置解出来的帧 PTS 顺序完全打乱这种情况下如果播放器渲染逻辑直接按解码输出顺序画画面是绝对对不上的。正确做法是解码输出后按 PTS 排序并丢弃 PTS 重复或异常倒退的帧。6.4 画面上屏putImageData 与 WebGL 的效率之争用 Canvas 2D 的putImageData上屏是最直观的每帧把 RGBA 数据硬塞进去就行。但在大分辨率下putImageData有额外开销因为每次调用都要在引擎内部做一个较大的内存块拷贝。更高效的做法是用 WebGL 纹理上屏把 RGBA 数据作为纹理推到 GPU然后画一个铺满 canvas 的三角面。这样 CPU 只负责把一帧 RGBA 数据送到 GPU之后的缩放、色彩处理全都交给显卡流畅度明显更好。如果你解码后输出的是 YUV 而不是 RGBAWebGL 甚至可以直接用三个纹理分别放 Y、U、V 平面然后在着色器里做 YUV 到 RGB 的换算。这个方案省掉了 CPU 侧的像素转换性能是最高的代价是着色器代码要自己写。我自己的播放器在支持 WebGL2 的设备上优先走三条纹路上屏不支持再退回到putImageData。聊到最后我再补一句掏心窝子的经验软解码不是银弹它适合的是浏览器原生解码不可控这个前提下的工程兜底。如果你们的目标设备相对固定、系统内核都支持 H265优先去挖掘 WebCodecs 硬解路线更划算但如果你想做一个覆盖面广、行为可控的 Web 播放器软解码这套底座是绕不开的形态。我前后花了两周多时间把 0.9 版本从黑屏调到流畅跑满中间最耗神的不是解码器本身而是一个接一个的封装差异、内存细节和 Canvas 性能陷阱。把这些踩过的坑写下来就是希望后来的人能少走几趟弯路——第一帧画面成功上屏的那一刻你会有种整个标准都被我抻开了的成就感。