H.265 网页播放：WebAssembly + FFmpeg 实现浏览器端硬解/软解方案

高性能渲染：WebGL 处理 YUV

FFmpeg 解码出来的数据通常是 YUV420p 格式。不要在 CPU 里把 YUV 转 RGB（这非常慢），要用 WebGL Shader 在 GPU 里转。

渲染流程：

1. 创建 3 个 WebGL 纹理 (Texture)，分别存放 Y、U、V 数据。
2. 编写 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);
}

难点攻克：音画同步 (AV Sync)

视频能播了，但声音和画面对不上怎么办？通常以 音频时钟 (Audio Clock) 为基准。

同步逻辑：

• 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，让渲染也在 Worker 线程完成，彻底解放主线程 UI。
4. WebCodecs 优先：始终检测 VideoDecoder API。如果支持硬件解码，直接 bypass 掉 Wasm 模块，这是性能的降维打击。

总结

通过 Wasm + FFmpeg + WebGL，我们填补了浏览器 H.265 支持的空白。虽然软解 4K 依然吃力（主要受限于单线程 JS 调度和 CPU 算力），但在 720p/1080p 监控流、会议流场景下，这是一套成熟且工业级的解决方案。

后续可以尝试结合 WebSocket 或 WebRTC，接收实时的 H.265 NALU 流（如 RTSP 转 WS），实现一个低延迟的网页版安防监控播放器。