手上有一段 60 秒的 1080p 街头演奏视频，116.7 MB。我在网页里把输出格式换成 MP4 H.265，档位选高清均衡。8.5 秒就出了片，43.99 MB。后来换了一段本身就是 H.265 的一分钟录屏，又把浏览器的硬件视频编码关掉再导。这回等了 55.5 秒。同一个导出按钮，等几秒还是等将近一分钟，差别全在这台机器有没有能用的硬件编码器。我干脆把几档都跑了一遍，耗时、体积和界面上冒出来的提示都记了下来。
我用的是图映 ImgIng（imging.cn/）的视频压缩，机器是一… Apple M4 的 Mac。系统 macOS 26.5，浏览器 Chromium 149。片子有两段。一段是维基共享资源上 Isak Zvegelj 拍的街头吉他演奏（CC BY 3.0）。我截了中间 60 秒再按手机常见的码率重新编码过，它不是手机原片。另一段是我拿脚本合成的 60 秒假讲义录屏，画面比真实录屏更静也更干净。每个档位只跑了一次。下面的秒数只代表这台机器。
能力面板写着原生硬件才是快路线
选 H.265 之前我会先看右边的「本机能力」。里面有一格叫「H.265 / HEVC 输出」，我一共见过它的三种状态：原生硬件、本地 WASM、当前设备不可用。正常打开 Chromium 时写的是原生硬件。格式选项下面的说明也写得很直白：优先用当前设备的硬件编码器，不下载 AI 模型。后两种状态是我把浏览器的硬件视频编码关掉以后才看到的。原片本身是 H.265 时它变成本地 WASM。原片是 H.264 时变成当前设备不可用。这一格基本决定了你后面是等几秒还是等将近一分钟。我现在导出前都先瞄它一眼。
硬件编码几秒就出片
面板写着原生硬件的时候 H.265 跑得和 H.264 差不多快。街头演奏那段选「高清均衡」用了 8.5 秒。「体积优先」4.0 秒，智能推荐 10.7 秒。讲义录屏的高清均衡是 8.5 秒，体积优先 3.9 秒。同一台机器上我还拿 HandBrake 的「Fast 1080p30」预设换成 x265 编码器编了街头演奏那段，花了 52.4 秒。两边的参数和画质目标都不一样。这个数只能说明硬件编码确实快，不能当成同档比较。
这张图先看右上角那一格「原生硬件 · H.265 / HEVC 输出」，再看右边的进度卡和结果卡。116.7 MB 的街头演奏选了高清均衡和 H.265。已用时间 0:08，出来的成品是 43.99 MB。左上那段灰字是 H.265 选项自带的说明，里面提到已经高度压缩的视频成品可能接近原大小。画面里的吉他手来自维基共享资源：Ljubljana Street Country Guitar Performance，Isak Zvegelj，CC BY 3.0，经截取压缩。
有两处是上手用了才注意到的。压完它只是先生成成品。要点「保存」才会写进磁盘，原视频不动。界面上的 MB 是按 1024×1024 字节算的。那份 43.99 MB 的成品实际有 46,131,638 字节，放进访达里看会显示得大一点。我第一次还以为保存时多出了什么东西，算了一下才对上。开始之前它还会给一个「码率预算估算（未试压）」。街头演奏选体积优先和 H.264 的时候估的是 10.05 MB，压完是 10.00 MB。这一回估得挺准。
换成HEVC同档体积小两到三成
体积是我最在意的部分。每个档位我都用 H.264 和 H.265 各导了一次。画质用 VMAF 打分，满分 100。成品先放大回 1080p，再拿去和原片逐帧比。
| 片子 · 档位 | H.264 体积 / VMAF | H.265 体积 / VMAF | H.265 的变化 |
|---|---|---|---|
| 街头演奏 · 高清均衡 | 54.51 MB / 97.16 | 43.99 MB / 96.67 | 比 H.264 小 19.3% |
| 街头演奏 · 体积优先 | 10.00 MB / 58.16 | 7.49 MB / 54.95 | 比 H.264 小 25.1% |
| 讲义录屏 · 高清均衡 | 8.93 MB / 98.03 | 6.28 MB / 98.42 | 比 H.264 小 29.7% |
| 讲义录屏 · 体积优先 | 9.58 MB / 55.81 | 7.37 MB / 55.68 | 比 H.264 小 23.0% |
体积优先那两行的分数偏低。这一档会降到 1080×608 和 24 fps，打分时帧对不齐，只能当参考。我真正想看的是右边那一列。四行里 H.265 都更小。少的 19%，多的接近 30%。高清均衡档的分数两边只差零点几，我自己来回切着看也分不出来。
没有硬件时HEVC原片慢六倍多
关掉硬件视频编码之后我又拿一段 H.265 格式的讲义录屏试了试，19.69 MB。界面提示检测到 H.265 原片，当前设备没有可用的匹配硬件编码器。它会按需加载本地的 x265 核心接着压。体积收益不够或者编码失败的话就保留原片，这句它也写明了。这一次多下载了大约 24 MB 的编码核心。从点开始到出结果用了 55.5 秒。有硬件时同一段只要 8.5 秒。体积反倒小了一点：5.73 MB 对 6.01 MB。VMAF 是 97.97 对 98.32。我开着网络面板看完了全程。下载的是编码核心，没有一条上传视频的请求。原片是 H.264 的话就没有这条退路。能力面板显示当前设备不可用时，它会让你把格式换成 MP4（H.264）或者 WebM。
导出的HEVC文件四个浏览器都能播
压出来的东西别人能不能看，对我来说比省几兆要紧得多。我在同一台 Mac 上用 Chromium 149、Chrome 155、Firefox 151 和 WebKit 26.5 把三个 H.265 成品各播了一遍。四个浏览器都出了画面。Windows 上的 Chrome 和 Edge、安卓手机、iPhone 的 Safari 和微信内置浏览器我都没测。这几处还是空白。
现在我导 H.265 前后各多做一步。导之前看能力面板那一格。写着原生硬件再选 H.265，写着别的就先想想值不值得等。导完把成品拖进 Firefox 和 Safari 各开一下，两边都出画面再发出去。拿不准对方用什么设备，就另导一份 H.264 跟着发。另外这个视频压缩只能在电脑浏览器里用，手机上打开会提示去电脑端继续。没有硬件编码器的老电脑上 H.265 原片到底要等多久，我也说不好。手边没有这样的机器，我只在关掉硬件的 Chromium 上见过那 55.5 秒。
