H.264 / H.265 / H.266 Web 前端播放选型：2026 年该用哪一代

在 MiBee NVR 监控大屏项目里，前端到底给 16 路摄像头拉 H.264 还是 H.265 流？这是个看似简单但越挖越深的问题。H.265 同画质码率只有 H.264 的一半，带宽和存储都省；但网上不少资料又说"H.265 浏览器支持差、Firefox 不支持、要装扩展"。到底哪些说法还成立？

这篇把 H.264/AVC、H.265/HEVC、H.266/VVC 三代编码放在 Web 前端播放的同一维度下做横向对比，覆盖浏览器原生解码、WebCodecs、MSE、WASM 软解、播放器库、流媒体协议、摄像头网关、多路并发、NAT 穿透与硬件解码生态。文中的浏览器版本号、CPU 实测数据、播放器 star 数会持续变化，落地前请到对应官方仓库核对最新状态；CPU 占用与多路性能是典型参考值，实际表现取决于硬件与负载。

三代标准的核心差异

三代编码标准由 ITU-T VCEG 与 ISO/IEC MPEG 联合制定，发布间隔约 7 年一代，每一代压缩效率提升约 50%，复杂度提升约 10 倍。

每代相对前代的码率节省是经过 JVET 官方 Common Test Conditions 验证的客观指标。以 1080P@30fps 业务视频为基准，三代典型码率差距很大：

压缩效率的提升伴随复杂度指数级上升。Bross 等人在 IEEE TCSVT 2021 的 VVC 综述里给出 VVC 编码复杂度相对 HEVC 提升 8–12 倍、解码复杂度提升 1.5–2 倍。结合业界对 AVC/HEVC 的实测：

解码复杂度直接决定 WASM 软解的可用性——这是后面"为什么 H.266 现在不能上 Web"的根因。

浏览器原生支持矩阵

浏览器原生支持是前端播放的第一道门槛。

H.264 / AVC：全平台可用

H.264 是 WebRTC 规范 RFC 7742 强制要求的视频编码（VP8 也是强制项，但实际部署中 H.264 占绝对主流）。所有主流浏览器均原生解码，支持率长期在 98–99%（CanIUse 数据有波动，没有精确到小数点的权威值）。

H.265 / HEVC：生态分散但有明显改善

H.265 的浏览器支持依赖系统级硬件扩展。Windows 10/11 需要从 Microsoft Store 装"HEVC 视频扩展"（付费或 OEM 预装），macOS 10.13+/iOS 11+ 系统级支持，Android 5.0+ 看芯片硬解能力。

这里要专门讲一下 Firefox 的 HEVC 转折，因为绝大多数中文资料没跟上：

Mozilla 长期以"MPEG-LA 专利授权费与开源策略冲突"为由，在 Bugzilla bug 1534864 里拒绝桌面端 HEVC。这个立场在 Firefox 134（2025 年 1 月） 被打破——该版本开始调用 Windows 系统的 HEVC 硬件解码器；Firefox 136 起扩展到 macOS。也就是说，到 2026 年中，“Firefox 不支持 HEVC"的说法只在 Firefox 133 及更早的旧版本上成立。如果你的部署目标用户里 Firefox 占比不可忽视，要求 ≥134 即可。

Linux 桌面仍是盲区：Chromium 与 Firefox 在 Linux 上都不原生支持 HEVC（专利问题），这块短期内不会有解。

H.266 / VVC：零支持

截至 2026 年 7 月，所有主流浏览器均无 VVC 原生解码支持。Chromium Issue Tracker 上有公开 issue 跟踪 WebCodecs VVC 支持需求，但目前只停留在讨论阶段，无实现计划。CanIUse 上 VVC 条目显示全球支持率为 0%。

对比之下，开放授权的 AV1 在 Chrome 70+、Firefox 65+ 已普及到 80%+ 浏览器。商业上 VVC 专利池（Access Advance 主导，对消费设备收约 0.4–0.6 美元/台）让浏览器厂商缺乏动力。AV1 在 Web 端实际上占据了"下一代"位置，VVC 可能永远到不了。

WebCodecs / MSE / WASM 三条解码路径

前端拿到视频流之后，有三种解码路径。选错路径会直接导致 CPU 飙升或黑屏。

flowchart TD
    A[视频流] --> B{WebCodecs 硬解可用?}
    B -->|是| C[VideoDecoder 渲染]
    B -->|否| D{MSE 原生支持?}
    D -->|是| E["video 标签 + fMP4"]
    D -->|否| F{分辨率 ≤1080P?}
    F -->|是| G["WASM 软解<br/>libde265.js"]
    F -->|否| H[无法播放]
    style C fill:#4CAF50,color:#fff
    style E fill:#2196F3,color:#fff
    style G fill:#9C27B0,color:#fff
    style H fill:#f44336,color:#fff

WebCodecs API（2023 年后的首选）

WebCodecs 是 W3C 标准化的浏览器底层编解码接口，让前端能直接拿到原始 NALU 与解码后的 VideoFrame，无需走 MSE 的封装层。对于零延迟播放、自定义渲染、AI 推理前置处理，这是首选路径。

• H.264：Chrome 94+、Edge 94+、Safari 16.4+、Firefox 130+ 全部支持 VideoDecoder，是支持率最高的编码。
• H.265：支持率随平台波动——Chrome/Edge/Safari 在系统装了 HEVC 扩展时可用，Firefox ≥134 起在 Windows 上也可用。网上流传的"85%“数字来源不清，更可能是 AV1-via-WebCodecs 的统计，HEVC-via-WebCodecs 实际更低（取决于用户机器是否装了 HEVC 扩展）。
• H.266：完全无支持。

WebCodecs 的 H.265 用法示例：

1
2
3
4
5
6
7
8
9

const decoder = new VideoDecoder({
  output: frame => renderToCanvas(frame),
  error: e => console.error(e)
});
decoder.configure({
  codec: 'hvc1.1.6.L150.B0',  // HEVC Main Profile, Level 5.0
  codedWidth: 1920, codedHeight: 1080,
  hardwareAcceleration: 'prefer-hardware'  // 不写会回退软解，CPU 飙升
});

HEVC WebCodecs 的三个常见坑：

1. hvc1 与 hev1 不能混用。hvc1（带内参数集）适合大多数场景；hev1（带外参数集）需手动配置 description 字段，否则 configure() 抛错。网关转封装 RTSP/H.265 → fMP4 时务必输出 hvc1，否则 Chrome/Edge 会花屏。SRS、ZLMediaKit、MediaMTX 默认输出 hvc1。
2. 必须在 HTTPS 下访问，且写 hardwareAcceleration: 'prefer-hardware'，否则回退软解。
3. Edge 在某些版本上 MediaSource.isTypeSupported('video/mp4; codecs="hvc1.1.6.L150.B0"') 返回 true 但实际黑屏——只校验 codec string 语法，不检查解码器是否真的存在。正确做法是再用 VideoDecoder.isConfigSupported 二次验证，并播一段最小 HEVC fMP4 试播监听 video.error。

MSE（最稳定的兜底）

Media Source Extensions 让前端用 JS 把分片视频追加到 <video>。H.264 + fMP4 在所有现代浏览器上稳定可用，是 HLS.js、flv.js、mpegts.js 的基础。H.265 + fMP4 则取决于浏览器 MSE 是否支持 HEVC，支持矩阵与上面 H.265 原生支持一致。

1
2
3
4
5
6

const ms = new MediaSource();
video.src = URL.createObjectURL(ms);
ms.addEventListener('sourceopen', () => {
  const sb = ms.addSourceBuffer('video/mp4; codecs="avc1.640028"');
  sb.appendBuffer(fmp4Segment);
});

WASM 软解（最后的兜底）

当浏览器原生不支持某编码（Firefox 旧版本不支持 H.265、所有浏览器不支持 H.266），WASM 软解是唯一方案。代价是 CPU 占用高、内存大、移动端体验差。

Wieckowski 等人在 ACM Multimedia 2021 的论文《VVC in the Cloud and Browser Playback: It Works》是当前公开 VVC Web 解码器里最系统的性能评估。结论是 VVC WASM 在 2026 年仍无法支撑实时 1080P 播放。

WASM 多线程依赖 SharedArrayBuffer，要求站点部署 COOP/COEP 头（Cross-Origin-Opener-Policy: same-origin + Cross-Origin-Embedder-Policy: require-corp）。站点有第三方 iframe 或图片资源时要配 cross-origin isolation，部署复杂度高。iOS Safari 的 SharedArrayBuffer 受限，移动端 WASM 多线程方案基本不可用。

前端播放器库

播放器库封装了 MSE/WebCodecs/WASM + 渲染 + 控制条 + 错误恢复。监控场景的国内主流选择是这几个：

国产播放器（Jessibuca、EasyPlayer、WXInlinePlayer、libmedia）原生支持 H.265 软解 + 硬解自动切换，是国内监控大屏的主流选择。海外开源方案（Video.js、hls.js、flv.js、Plyr）大多只支持 H.264，H.265 需自行基于 WebCodecs + MSE 二次开发。

纯 H.264 场景选择最广：普通 VOD 与直播用 hls.js；监控低延迟用 mpegts.js（WS-TS / HTTP-FLV）；需要自定义 UI 用 Video.js 或 Plyr。

没有任何主流前端播放器库原生支持 VVC。可选路径只有自行基于 VVdeC WASM 开发 POC，或等 2027-2028 年浏览器原生支持。

流媒体协议与摄像头网关

RTSP 是 IP 摄像头最普遍的接入协议，但浏览器无法直接播放 RTSP。必须通过流媒体网关转换。

协议 × 编码支持

WebRTC 是唯一支持亚秒级延迟的协议，RFC 7742 强制要求 H.264（VP8 也是强制项）。H.265 进入 WebRTC 是 2025 年的关键进展——Chrome 136（2025 年 4 月发布）开始支持 WebRTC HEVC，前提是客户端硬件支持。这给低延迟 4K 监控直播打开了窗口：H.264 4K 在 WebRTC 下要 25 Mbps+ 带宽，H.265 4K 只要 8–12 Mbps。但 Safari、Firefox 暂未跟随，跨浏览器能力不对等。

FLV 与 H.265 的坑：FLV 官方规范（Adobe 2009）只定义了 H.264 codec ID（7），H.265 codec ID（12）是 FFmpeg 扩展。flv.js 不支持 H.265，要用 mpegts.js 或国产播放器。

主流流媒体网关

按规模选：

• 100+ 摄像头：SRS v6+，源站集群 + 边缘节点。
• 10–100 路：ZLMediaKit，C++ 性能好、API 丰富。
• 快速 POC / 边缘设备：MediaMTX，单二进制无依赖。
• 智能家居 / HomeAssistant：go2rtc，零配置。

网关转码 vs 直通的代价：转封装（passthrough）不改编码只改容器（RTSP → fMP4），CPU 占用极低（1–2%）；转码（transcode）重新解码+编码，单路 1080P H.265→H.264 软转码要 CPU 30–50%。生产环境尽量用直通；摄像头是 H.265 但前端必须 H.264 时，建议在前端做 UA 检测分流——目标浏览器支持 H.265 就走直通流，不支持的走转码流并降分辨率（如 720P）省服务器负载。

多路播放性能与降级策略

监控大屏、视频墙、安防指挥中心是 Web 前端视频的性能极限场景。

桌面端 H.264 软解能稳定 10 路 1080P，H.265 软解仅 5 路；H.265 硬解 6 路，明显少于 H.264 硬解 16 路——HEVC 解码器并发度受 GPU 视频解码器数量限制（一般桌面 GPU 只有 2–3 个 NVDEC 单元）。VVC 当前完全无法多路播放。

多路播放的瓶颈分解：

• CPU：WASM 软解每路 H.264 占一个核的 20–30%，H.265 占 40–50%。8 核 CPU 软解上限约 16–24 路 H.264 或 8–12 路 H.265。
• GPU：NVDEC 单元数决定硬解路数。RTX 3060 有 3 个 NVDEC，可同时硬解 3 路 4K 或 12 路 1080P H.265。
• 内存：每路 1080P 解码占用 30–80 MB。100 路 H.265 软解约需 8 GB。
• 渲染：Canvas/WebGL 是隐式瓶颈。16 路渲染约占用 100% GPU，需用 OffscreenCanvas + Worker 分摊。
• 网络：H.264 1080P@30fps 约 4 Mbps，H.265 约 2 Mbps。100 路并发 H.264 需 400 Mbps 入口带宽，H.265 需 200 Mbps。

16 路 1080P 监控大屏的推荐配置：前端 Jessibuca Pro + WebCodecs 优先硬解 + OffscreenCanvas 渲染；H.265 1–6 路用硬解，7–12 路降级到软解 + 半分辨率（540P），13–16 路用静态缩略图轮播；服务端 SRS 边缘节点 + ZLMediaKit 源站，按地区分集群，带宽预留 50%；浏览器 Chrome 130+ 或 Edge 120+，开 GPU 硬件加速，关省电模式。

Jessibuca、EasyPlayer、libmedia 都提供"焦点路 + 缩略图"模式：用户选中的 1–4 路用原始帧率与分辨率，其余路降至 5–10 fps 或 540P。这是 16 路以上场景必备的优化。

NAT 穿透与带宽成本

内网摄像头、边缘网关需要被公网访问时，必须解决 NAT 穿透。方案本身工作在传输层以下，对上层视频编码透明——无论 H.264、H.265 还是 H.266，方案选择只看延迟、带宽、运维成本。

带宽成本与编码选择

虽然穿透方案与编码无关，但编码选择直接影响按流量计费的带宽成本。TURN 服务器流量、CDN 流量、FRP 服务器带宽都按流量计费。

以 100 路并发 1080P 监控、按 0.5 元/GB、每天 8 小时算：H.264 每月带宽约 26,400 元；H.265 约 15,800 元，省 40%。这是 H.265 在公网直播场景被强烈需求的根本原因。

按流量计费的 TURN 服务同理。Cloudflare TURN 0.25 元/GB，100 路 1080P 用 H.265 每月约 7,900 元，H.264 约 13,200 元。前提是所有客户端浏览器支持 H.265 硬解——2026 年这个前提已基本成立（Chrome 107+/Edge 120+/Safari 11+/Firefox 134+）。

硬件解码生态与 VVC 现状

硬件解码是高清视频播放的最终保障。三编码标准的硬件解码普及率：

VVC 硬件解码芯片自 2024 年开始进入消费市场：

Snapdragon 8 Elite 与 NVIDIA RTX 50 系列是否支持 VVC 硬解，目前没有官方规格表确认（高通官方只列出 H.265/VP9/AV1，RTX 50 的 VVC 支持也无公开证据），落地前请向厂商核实。

Apple Silicon 不支持 VVC 是最大阻碍。iOS/macOS 用户在高端市场占比超 25%，VVC 浏览器支持若要超过 50% 覆盖率必须等 Apple 跟进。Apple 当前选了 AV1 而非 VVC（M3/M4 芯片支持 AV1 硬解）。

浏览器能否调用硬件解码取决于三层：芯片支持 → 操作系统暴露 API（Windows Media Foundation / macOS VideoToolbox / Android MediaCodec / Linux VAAPI）→ 浏览器通过 codec string 白名单与解码器实现暴露给 Web。三层缺一不可。VVC 当前在 Intel Lunar Lake 上硬件支持，但 Chromium 与 Firefox 均未实现 VVC 的 codec string 解析，前端无法使用。

选型建议

按场景给首选 + 备选：

推荐部署流程：

1. 能力探测：前端首屏跑探测脚本，调 VideoDecoder.isConfigSupported 与 MediaSource.isTypeSupported 检测 H.264/H.265 支持。
2. 编码协商：根据探测结果与服务端协商拉流编码。支持 H.265 的浏览器拉 H.265 流省 40% 带宽；不支持的拉 H.264 流走直通。
3. 解码路径：优先 WebCodecs 硬解 → 退回 MSE 原生 → 退回 WASM 软解（仅 720P/1080P 单路）→ 拒绝播放（4K+ 无硬解）。
4. 渲染优化：多路播放用 OffscreenCanvas + Worker 分摊渲染负载，焦点路原始帧率，其余降帧。
5. 降级策略：硬解失败自动降 WASM 软解，WASM CPU 飙升时降分辨率或帧率，记录失败日志用于运维定位。

待观察事件

几个仍需关注的技术事件，会影响后续选型决策：

• Firefox HEVC 解码质量：Firefox 134+ 已支持 HEVC，但解码性能/延迟与 Chrome/Safari 的对比仍需实测，监控大屏场景尤其要验证。
• Apple VVC 硬解：决定 VVC 整体覆盖率曲线斜率。预计 2026-2027 年 M5 系列可能跟进，但当前迹象是 Apple 选 AV1 而非 VVC。
• Chrome VVC WebCodecs：Chromium Issue Tracker 上 VVC 支持需求的进展是 Web 前端 VVC 落地的风向标。预计 2027 年开始进入实验阶段。
• AV1 替代效应：AV1 浏览器支持率已达 80%+ 且免授权费。若 AV1 硬解设备覆盖率快速提升，VVC 在 Web 端可能永远无法占据主流。

2026 年的 Web 视频前端，默认选 H.264，特定场景引入 H.265，VVC 仅做技术储备。公网直播与监控大屏主用 H.264 + WebRTC / HLS；带宽敏感的 4K 监控与公网直播用 H.265 + WebCodecs（控设备）；VVC 等 2027-2028 年浏览器与硬件生态成熟后再评估。AV1 是开放授权的下一代候选，应同步跟踪其硬件解码设备覆盖率增长。