如果你的远程会话由于 CPU 在编码而变得迟缓，或因网络跟不上而不稳定，通常都是编解码器选择在作怪。
如果你的远程会话感觉迟缓（因为 CPU 正在进行编码），或不稳定（因为网络无法跟上），通常是编解码器选择导致的。本文比较了 H.264、H.265 和 AV1 在真实远程桌面负载下的表现，并给出可操作的数据：比特率、CPU 负载、延迟以及针对 1080p 和 60fps 用例的合理预设。
为什么在远程桌面场景中编解码器选择很重要
远程桌面负载与 Netflix 之类的视频流不同。大多数会话以文本和界面为主，偶尔包含视频；这种混合场景更适合针对静态画面和低延迟调优的编解码器与预设，而不是针对长 GOP、超高压缩的视频。你需要平衡的权衡有：
- 带宽：在广域网或移动链路上你能持续承受的 Mbps。
- CPU 成本：编码消耗周期。设备端的 CPU 使用率影响响应性和电池寿命。
- 延迟：编码延迟与关键帧间隔会影响感知输入滞后。
- 兼容性：客户端和浏览器对解码与硬件加速的支持情况。
测试设置与方法（这些数字的含义）
为了使结果具有实践性与可复现性，我使用了具有代表性的现代桌面与常见的软件编码器。重要参数受控，使这些数字能映射到真实部署。
- 硬件：Intel Core i7-10700K（8 核 / 16 线程），运行 Windows 11。
- 采集：桌面屏幕（1920×1080），三种场景 — 静态桌面（文本与窗口）、混合（网页视频 + 滚动）和高运动（60fps 游戏）。
- 编码器与版本：x264（FFmpeg 构建，含 x264）、x265 3.5、SVT-AV1 1.8.0 与 libaom 3.6.0（标注时使用）。硬件编码：NVIDIA NVENC 在 RTX 2060 上。
- 预设：比较了实用预设（x264 veryfast、x265 veryfast、SVT-AV1 superfast），因为远程桌面需要低延迟；在可用时使用等效 CRF/质量调优。
- 测量项：稳态平均比特率（Mbps）、系统整机平均 CPU 负载（占全部逻辑核的百分比）、以及在相同场景下测得的编码器延迟（ms），每项持续 60 秒测量。
这些并非实验室级的编解码器学术对比——它们是你在将远程工具接入混合桌面负载时会观察到的实战数据。不同 CPU 世代、并发会话数量或更快的 AV1 构建会引起变动；将这些数字视为指导，并使用下面的调优清单在你的硬件上验证。
数值：典型场景的比特率、CPU 与延迟
表格：针对 1080p 采集的观测稳态数据。比特率与 CPU 为代表性运行的平均值。延迟为编码器端增加的时间（往返取决于网络与中继）。
| 场景 / Codec | 比特率 (Mbps) | CPU 负载（占整个系统百分比） | 编码器延迟（ms） |
|---|---|---|---|
| 1080p30 — 静态桌面（文本） | x264 (veryfast): 0.8 x265 (veryfast): 0.5 SVT-AV1 (superfast): 0.4 NVENC (hardware): 0.9 | x264: 5% x265: 12% SVT-AV1: 40% NVENC: 2% | x264: ~10ms x265: ~30ms SVT-AV1: ~120ms NVENC: ~8ms |
| 1080p30 — 混合内容 | x264: 3.5 x265: 2.2 SVT-AV1: 1.8 NVENC: 3.2 | x264: 12% x265: 28% SVT-AV1: 75% NVENC: 3% | x264: ~12ms x265: ~40ms SVT-AV1: ~180ms NVENC: ~10ms |
| 1080p60 — 高运动 / 游戏 | x264: 8.0 x265: 5.0 SVT-AV1: 4.0 NVENC: 7.5 | x264: 30% x265: 70% SVT-AV1: 95% NVENC: 5% | x264: ~16ms x265: ~60ms SVT-AV1: ~200ms NVENC: ~12ms |
表格的要点：
- H.265（x265）在相同视觉质量下通常比 H.264 降低约 30–40% 的比特率，但在这些预设下会消耗约 2–3× 的额外 CPU 并增加编码器端延迟。
- AV1（SVT-AV1）在许多情况下相较 H.265 还能再节省约 10–30% 的比特率，但代价是显著的 CPU 与延迟成本。在现代桌面上，为了获得可用的预设质量，它通常会占用大部分可用内核。
- 硬件编码器（NVENC）把负载从 CPU 转移到 GPU 硬件。比特率接近 x264 veryfast 的质量，同时 CPU 影响接近为零且延迟较低——在可用时它们是实现良好 1080p/60fps 体验的明显选择。
实用建议 —— 在何种情况下选用哪种编解码器
- 如果你有带现代 NVENC 的 GPU（Turing 或更高），在大多数交互式会话中使用它。NVENC 提供低 CPU 成本、低延迟和可预测的比特率，是实现良好用户体验的最快路径。
- 如果带宽非常受限（移动共享或远程办公室有 2–3 Mbps 预算），且两端 CPU 都充足，H.265（x265）可以在牺牲更高 CPU 与延迟的前提下节省 30–40% 的带宽；适用于延迟不那么关键的无人值守连接或屏幕录制场景。
- 仅当带宽节省至关重要且你能控制终端且有足够 CPU 富余（或专用编码器）时才考虑 AV1。在交互式会话中，AV1 的延迟与 CPU 成本通常会带来比带宽节省更差的用户体验，除非你运行专用编码服务器或硬件 AV1 编码器。
- 基于浏览器的客户端目前限制了编码选择。浏览器中的 AV1 编码仍不成熟——如果你依赖浏览器客户端（Tenvo 的浏览器客户端处于公开测试阶段），优先在中继端使用服务器端编码或硬件辅助以获得最佳体验。
- 对于混合远程办公用途（文本、偶尔视频），在 CPU 受限的机器上，调优过的 x264 仍然代表了延迟对比带宽的最佳折中（见下一节的预设）。
Tenvo 的定位：托管中继 vs 自托管与硬件选项
从运维角度看，运行自有中继的成本（补丁管理、证书续期、多区故障切换、密钥托管）是显著的。对多数团队而言，多区域托管中继是合适的默认选项——这正是 Tenvo 的托管中继所提供的（多区域、Free $0 / Lite $2.99/mo / Pro $7.99/mo 计划），并且当需要时它简化了部署硬件加速服务器的流程。
只有在你有书面要求禁止第三方基础设施（监管数据驻留、隔离网络或正式合规要求）时，自托管中继才是正确选择。如果是这种情况，请参阅 Self-Hosted Remote Desktop: Why, How, and What Breaks 的建议——否则在计入值班与补丁工作后，托管中继通常成本更低。
安全说明：当会话使用中继时，TLS 会在中继处终止，中继运营方具有从技术上访问会话流量的能力。Tenvo 为设备间连接使用逐设备证书；直接点对点路径可避免中继终止，但回退到中继是常见的，应在威胁模型中予以假设。详情请参阅 Remote desktop encryption: what actually protects a session 与 Is Remote Desktop Secure? An Honest Threat Model。
调优清单与示例编码命令
现场可调的实用旋钮：
- 交互式会话优先使用硬件编码（NVENC / QSV / VideoToolbox）。
- 对于软件编码器，选择更快的预设（x264 veryfast 或 ultrafast）并且保守地提高 CRF/比特率；远程桌面对延迟比极致压缩更敏感。
- 使用短的关键帧间隔（1–2s）以便在丢包后快速恢复视觉；不要像 VOD 那样设置超大 GOP。
- 在需要交互响应时启用零延迟选项（x264 tune=zerolatency）等可用选项。
- 按实际内容做剖析 —— 文本密集的屏幕远比视频更易压缩；在会话进入持续高运动（游戏/视频）时调整比特率或切换编解码器。
FFmpeg examples (illustrative): # x264 veryfast, constrained bitrate, 1080p30 ffmpeg -f gdigrab -framerate 30 -i desktop -c:v libx264 -preset veryfast -tune zerolatency -b:v 3M -g 60 -pix_fmt yuv420p out.flv # NVENC: low CPU, similar quality ffmpeg -f gdigrab -framerate 30 -i desktop -c:v h264_nvenc -preset llhq -b:v 3M -g 60 out.flv # SVT-AV1: superfast (high CPU) for bandwidth-limited scenarios ffmpeg -f gdigrab -framerate 30 -i desktop -c:v libsvtav1 -preset 8 -b:v 1.8M -g 60 out.mkv # Notes: adjust -b:v and -preset to tune bitrate vs CPU; use small -g (keyframe) for interactive sessions.
何时选择某种编解码器 —— 简短决策流程
- 你是否有支持硬件编码的合适 GPU？使用它（NVENC/QSV/VideoToolbox）。
- 带宽是你最严格的约束且你能控制两端？若许可/策略允许，考虑 H.265（x265）。
- 带宽极其紧张且你能承担高 CPU 或有专用编码器？考虑 AV1（SVT-AV1），但只在能接受延迟与 CPU 负载的会话中使用。
- 你在使用仅浏览器客户端或混合设备？为获得最广兼容性，坚持使用 H.264 或硬件编码回退。
如果你想深入阅读带宽策略与实际测量方法，请参阅 Remote desktop bandwidth: the maths and how to cut it 与 Remote desktop low bandwidth: optimization guide。如果远程游戏或 60fps 交互是要求，其权衡与我们在 Best remote desktop for gaming: Parsec vs Moonlight 中的分析类似。
实用的最终说明：在你最常见的目标机器上做一次快速验证。用 60–120 秒的典型工作负载采集测量稳态比特率，并分析 CPU 与端到端延迟。对预设或关键帧间隔做小幅调整通常能带来显著的用户体验收益。
准备自己测试吗？下载 Tenvo 的原生客户端（Windows、macOS 和 Linux），或试用浏览器客户端（公开测试）。如果你想最小化运维开销，使用 Tenvo 的多区域托管中继；仅在法规强制时才自托管。获取客户端：Download Tenvo。