浏览器端播放 H.265：WebAssembly、FFmpeg 与 WebCodecs 的组合方案

这段逻辑的关键点不在'能不能解出来'，而在'怎么把数据送出去'。如果每一帧都在主线程和 Worker 之间来回复制，性能很快就会被拖垮，所以尽量用 Transferable Objects 或共享内存，少做中间拷贝。

用 WebGL 处理 YUV 渲染

FFmpeg 解出来的常见结果是 YUV420p。先转 RGB 再画出来当然能用，但纯 CPU 转换通常不划算。更顺手的方式是把 YUV 直接交给 WebGL，在 GPU 里做颜色空间转换。

做法很直接：准备 3 个纹理，分别放 Y、U、V，然后用 Fragment Shader 做矩阵变换。

Fragment Shader (GLSL)：

precision mediump float;
uniform sampler2D textureY;
uniform sampler2D textureU;
uniform sampler2D textureV;
varying vec2 vTexCoord;

void main() {
  float y = texture2D(textureY, vTexCoord).r;
  float u = texture2D(textureU, vTexCoord).r - 0.5;
  float v = texture2D(textureV, vTexCoord).r - 0.5;
  
  // YUV 转 RGB 公式 (BT.601)
  float r = y + 1.402 * v;
  float g = y - 0.34414 * u - 0.71414 * v;
  float b = y + 1.772 * u;
  
  gl_FragColor = vec4(r, g, b, 1.0);
}

这里比较值得坚持的一点是：别在 JS 里手工转颜色。那样写起来看似简单，性能却很容易在高分辨率下出问题。把这件事留给 GPU，通常更省心。

音画同步怎么收

视频能播不代表体验就正常。音画不同步时，问题一般先从视频帧调度开始看。比较常见的基准是音频时钟：视频帧的 PTS 跟音频时间对齐，差得太多就丢帧或等待。

同步逻辑可以粗略理解成这样：

• PTS < AudioTime：视频落后了，先追赶。
• PTS > AudioTime：视频超前了，等等再画。
• PTS 接近 AudioTime：正常渲染。

JS 主线程同步逻辑：

function renderLoop() {
  const audioTime = audioContext.currentTime;
  const frame = frameBuffer[0]; // 获取队列头部的帧
  if (!frame) return requestAnimationFrame(renderLoop);

  const diff = frame.pts - audioTime;

  if (diff < -0.03) {
    // 视频落后超过 30ms -> 丢帧追赶
    frameBuffer.shift();
    renderLoop();
  } else if (diff > 0.03) {
    // 视频超前 -> 等待下一帧绘制
    requestAnimationFrame(renderLoop);
  } else {
    // 同步 -> 渲染
    drawYUV(frame);
    frameBuffer.shift();
    requestAnimationFrame(renderLoop);
  }
}

这套逻辑不是绝对精确，但在网页播放器里够用了。真要做得更细，还得把解码队列、音频缓冲和渲染节奏一起看。

几个容易决定成败的优化点

要让 1080p 甚至 4K 播得顺，几个优化基本绕不开：

1. 开启 SIMD：支持 SIMD 的浏览器上，软解通常能明显好一截，2-3 倍这个量级在实践里并不夸张。
2. SharedArrayBuffer：主线程和 Worker 共享内存，能少掉不少拷贝；代价是要配好 HTTP Header，Cross-Origin-Opener-Policy: same-origin 这类配置不能漏。
3. OffscreenCanvas：把 Canvas 控制权交给 Worker，渲染也一起挪过去，主线程会轻松很多。
4. 优先 WebCodecs：只要 VideoDecoder 能用，就别硬上 Wasm。硬解在这类场景里就是更省事的路径。

结论

Wasm + FFmpeg + WebGL 能补上浏览器对 H.265 的缺口，尤其适合 720p、1080p 这类监控流、会议流场景。软解 4K 依然会吃紧，这不是某个实现细节的问题，更多是浏览器运行环境和 CPU 预算决定的。

如果后面还要接实时流，WebSocket 或 WebRTC 都能接进来，比如把 RTSP 转成 WS，再把 H.265 NALU 喂给这套解码链路。延迟压得住的话，网页版安防播放器是能做出来的。