1. WebRTC与H265的结合价值

H265（HEVC）作为新一代视频编码标准，相比H264能在相同画质下节省50%带宽。但在Web端实现H265实时传输一直是个技术难点，直到WebRTC开始支持H265编码。我去年在智能安防项目中首次尝试这套方案时，发现它特别适合监控摄像头这类高分辨率低码率场景——4K视频用H265传输只需4Mbps，而H264需要8Mbps以上。

传统方案通常需要在服务端转码成H264，但这会带来两个问题：一是转码服务器成本飙升（实测每路4K转码需要2核CPU），二是额外增加200ms以上的延迟。通过WebRTC直传H265，我们不仅省去了转码环节，还实现了端到端300ms内的超低延迟。

2. WASM软解码实战细节

2.1 FFmpeg编译为WASM的关键步骤

用Emscripten编译FFmpeg到WASM时，我踩过最深的坑是编解码器选项配置。推荐使用以下编译参数：

emconfigure ./configure \
  --target-os=none \
  --arch=x86_64 \
  --enable-cross-compile \
  --disable-x86asm \
  --disable-inline-asm \
  --disable-stripping \
  --disable-programs \
  --disable-doc \
  --enable-decoder=hevc \
  --disable-encoder \
  --disable-demuxers \
  --disable-muxers \
  --disable-filters \
  --disable-postproc \
  --disable-parsers \
  --enable-parser=hevc

实测发现必须禁用所有非必要模块，否则生成的WASM文件会超过浏览器内存限制。有次我忘记禁用x86asm，导致编译出的文件在Chrome直接崩溃。

2.2 SIMD加速的实战效果

开启SIMD指令集能让解码速度提升2-3倍，具体方法是在Emscripten编译时添加：

-s SIMD=1 -msimd128

这是我们在不同分辨率下的测试数据：

分辨率	普通解码帧率	SIMD解码帧率	CPU占用下降
1080p	35fps	78fps	42%
4K	12fps	28fps	55%

但要注意，SIMD目前存在兼容性问题：iOS版Safari和部分安卓浏览器不支持。我的解决方案是运行时检测SIMD支持情况，动态加载不同版本的WASM模块。

3. WebGL渲染优化策略

3.1 纹理上传的隐藏陷阱

刚开始用WebGL渲染YUV420P格式时，我傻傻地创建了三个纹理分别上传Y、U、V分量，结果在4K视频上GPU利用率直接爆表。后来改用单纹理三通道方案：

// 创建RGBA纹理但只使用前三个通道
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 
  width/2, height/2, 0, gl.RGBA, gl.UNSIGNED_BYTE, null);

// Y分量占用R通道，U分量占用G通道，V分量占用B通道
gl.texSubImage2D(gl.TEXTURE_2D, 0, 0, 0, 
  width, height, gl.RED, gl.UNSIGNED_BYTE, yData);

这样修改后，4K视频的渲染耗时从18ms降到6ms，GPU内存占用减少60%。核心原理是减少纹理绑定次数和内存拷贝。

3.2 异步渲染的奇技淫巧

浏览器主线程的卡顿会直接影响视频流畅度。我通过OffscreenCanvas+WebWorker实现了解码与渲染分离：

// 主线程
const offscreen = canvas.transferControlToOffscreen();
worker.postMessage({ canvas: offscreen }, [offscreen]);

// Worker线程
onmessage = (e) => {
  const gl = e.canvas.getContext('webgl');
  // 在此执行所有WebGL操作
};

实测在低端设备上，这种方式能将卡顿次数减少80%。但要注意：iOS 14以下的Safari不支持OffscreenCanvas，需要做降级处理。

4. 网络适应性优化方案

4.1 动态码率调整算法

当检测到网络带宽下降时，我们开发了一套智能降码率策略：

1. 优先降低帧率（从30fps→15fps）
2. 保持分辨率但增加QP值（画质优先模式）
3. 最后才降低分辨率（流畅优先模式）

实现关键是用WebRTC的RTCP反馈包获取网络状态：

// 监听带宽估计变化
pc.getStats().then(stats => {
  const reports = stats.get('remote-inbound-rtp');
  const availableBitrate = reports[0].availableOutgoingBitrate;
});

4.2 数据通道的可靠性配置

WebRTC DataChannel在弱网环境下表现差异很大，经过多次测试我推荐以下配置：

const dc = pc.createDataChannel('video', {
  ordered: true,          // 保证帧顺序
  maxRetransmits: 5,      // 最大重传次数
  maxPacketLifeTime: 2000 // 包存活时间
});

在跨国传输测试中，这种配置能在20%丢包率下保持视频连续播放。但要注意：maxRetransmits设置过大会增加延迟，需要根据场景权衡。

5. 多场景实施方案对比

5.1 纯视频监控方案

这是最适合H265+WebRTC的场景，我们的部署架构如下：

[摄像头] --H265--> [媒体服务器] --WebRTC--> [浏览器WASM解码]

关键优势：

• 端到端延迟<500ms
• 服务器成本降低70%（无需转码集群）
• 支持4K/8K超高清

5.2 音视频会议方案

对于需要音频的场景，我强烈建议在服务端做H265→H264转码。原因有三：

1. 浏览器对H265+音频的同步支持不完善
2. WebRTC默认音频编码(Opus)与H265时间戳对齐困难
3. iOS设备对H265的支持度参差不齐

6. 性能调优实战记录

最近在给某无人机厂商做方案时，遇到WASM内存泄漏问题。最终发现是FFmpeg的av_frame_free没有正确调用。正确的内存管理姿势应该是：

Module._free(framePointer);  // 释放AVFrame结构体
Module._free(dataPointers);  // 释放YUV数据内存

另外建议在Emscripten初始化时预分配内存：

Module = {
  INITIAL_MEMORY: 256 * 1024 * 1024,  // 256MB初始内存
  DYNAMICTOP_PTR: 2960                // 防止内存增长冲突
};