Remote desktop codec: H.264 vs H.265 vs AV1

If your remote sessions feel either sluggish because the CPU is busy encoding, or flaky because the network can’t keep up, the codec choice is usually why. This guide compares H.264, H.265 and AV1 for real remote-desktop workloads — with numbers you can act on: bitrates, CPU load, latency and sensible presets for 1080p and 60fps use cases.

Why codec choice matters for remote desktop

Remote desktop workloads aren’t the same as streaming Netflix. Most sessions are text-and-ui heavy with occasional video; that mixture favors codecs and presets tuned for stillness and low-latency rather than long-GOP, ultra-compressed video. The trade-offs you’ll balance are:

• Bandwidth: how many megabits per second you can continuously afford over WAN/mobile links.
• CPU cost: encoding takes cycles. On-device CPU usage matters for responsiveness and battery life.
• Latency: encode latency and keyframe intervals affect perceived input lag.
• Compatibility: what the client and browser support for decoding and hardware acceleration.

Test setup and methodology (what these numbers actually mean)

To keep results practical and repeatable I used a representative modern desktop and common software encoders. Important parameters were controlled so the numbers map to real deployments.

• Hardware: Intel Core i7-10700K (8 cores / 16 threads) on Windows 11.
• Capture: desktop screen (1920×1080), three scenarios — static desktop (text & windows), mixed (web video + scrolling), and high-motion (60fps gameplay).
• Encoders and versions: x264 (FFmpeg build with x264), x265 3.5, SVT-AV1 1.8.0 and libaom 3.6.0 where noted. For hardware encode: NVIDIA NVENC on an RTX 2060.
• Presets: compared practical presets (x264 veryfast, x265 veryfast, SVT-AV1 superfast) because remote desktops need low latency; CRF-equivalent quality tuning was used where applicable.
• Measurements: steady-state average bitrate (Mbps), average whole-system CPU load (percent of all logical cores), and measured encoder latency (ms) under the same scene for 60 seconds.

These are not lab-grade codec-vs-codec academic benchmarks — they are practical, real-world figures you’ll see when you wire a remote tool to a mixed desktop workload. Variations arise with different CPU generations, number of concurrent sessions, or faster AV1 builds; treat the numbers as guidance and use the tuning checklist below to validate on your hardware.

Numbers: bitrate, CPU and latency for typical scenarios

Table: observed steady-state numbers for 1080p captures. Bitrates and CPU are averages over representative runs. Latency is the encoder-side added time (round-trip depends on network and relay).

Key takeaways from the table:

• H.265 (x265) reduces bitrate by roughly 30–40% vs H.264 for the same visual quality, but it costs 2–3× more CPU in these presets and adds encoder-side latency.
• AV1 (SVT-AV1) can cut bitrate another 10–30% beyond H.265 in many cases, but at a steep CPU and latency cost. On a modern desktop it often consumes most available cores for decent presets.
• Hardware encoders (NVENC) shift load off the CPU to GPU hardware. Bitrate is close to x264 veryfast quality with near-zero CPU impact and low latency, making them the obvious choice when available.

Practical recommendations — which codec when

• If you have a GPU with a modern NVENC (Turing or later), use it for most interactive sessions. NVENC gives low CPU cost, low latency and predictable bitrate. It is the fastest path to good UX for 1080p and 60fps.
• If you are severely bandwidth constrained (mobile tethering or remote office with a 2–3 Mbps budget) and CPU is plentiful on both ends, H.265 (x265) can save 30–40% bandwidth versus H.264 at the expense of higher CPU and latency; useful for unattended connections or screen recordings where latency is less critical.
• Use AV1 only when bandwidth savings are essential and you control endpoints with enough CPU headroom (or a dedicated encoder). For interactive sessions AV1’s latency and CPU cost are often a worse UX than the bandwidth savings unless you run a dedicated encoding server or hardware AV1 encoder.
• Browser-based clients today limit encoding choices. AV1 encoding in browsers is still immature — if you rely on the browser client (Tenvo’s browser client is in public beta) prefer server-side encoding or hardware assist at the relay for best UX.
• For mixed remote-work use (text, occasional videos) x264 with tuned presets (see next section) still represents the best overall latency-to-bandwidth compromise on CPU-limited machines.

Tenvo positioning: managed relay vs self-hosting and hardware options

Operationally, the cost of running your own relay (patching, certificate renewal, multi-region failover, key custody) is significant. For most teams a multi-region managed relay is the right default — that’s what Tenvo’s managed relay provides (multi-region, Free $0 / Lite $2.99/mo / Pro $7.99/mo plans), and it simplifies deploying hardware-accelerated servers when you need them.

Self-hosting the relay is the right move only when you have a written requirement that forbids third-party infrastructure (regulatory data-residency, an isolated network, or a formal compliance demand). If that’s your case, follow the advice in Self-Hosted Remote Desktop: Why, How, and What Breaks — otherwise expect the managed relay to cost less once on-call and patching work is counted.

Note on security: when a session uses a relay, TLS terminates at the relay and the relay operator has the technical ability to access session traffic. Tenvo uses per-device certificates for connections; a direct peer-to-peer path avoids relay termination, but fallbacks to relays are common and should be assumed in threat models. See Remote desktop encryption: what actually protects a session and Is Remote Desktop Secure? An Honest Threat Model for details.

Tuning checklist and sample encoder commands

Practical knobs to tune in the field:

• Prefer hardware encode (NVENC / QSV / VideoToolbox) when available for interactive sessions.
• For software encoders, pick faster presets (x264 veryfast or ultrafast) and increase CRF/bitrate conservatively; remote desktop is more sensitive to latency than perfect compression.
• Use a short keyframe interval (1–2s) to keep visual recovery quick after packet loss; don't set massive GOPs as for VOD.
• Enable 'zerolatency' options where available (x264 tune=zerolatency) when interactive responsiveness matters.
• Profile for the actual content — text-heavy screens compress far better than video; adapt bitrate or switch codecs when the session moves into constant high motion (game/video).

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.

When to choose a codec — short decision flow

1. Do you have a capable GPU with hardware encode? Use it (NVENC/QSV/VideoToolbox).
2. Is bandwidth your strictest constraint and you control both endpoints? Consider H.265 (x265) if license/policy allows.
3. Is bandwidth extremely tight and you can afford high CPU or a dedicated encoder? Consider AV1 (SVT-AV1) but only for sessions where latency and CPU load are acceptable.
4. Are you using browser-only clients or mixed devices? Stick with H.264 or hardware encode fallbacks for widest compatibility.

If you want deeper reading on bandwidth strategies and real measurement approaches, see Remote desktop bandwidth: the maths and how to cut it and Remote desktop low bandwidth: optimization guide. If remote gaming or 60fps interactivity is a requirement, the trade-offs match the ones in our Best remote desktop for gaming: Parsec vs Moonlight analysis.

Practical final note: run a quick validation on your most common target machine. Measure steady-state bitrate with a 60–120 second capture of the typical workload, and profile CPU and end-to-end latency. Small adjustments to preset or keyframe interval usually give large UX wins.

Ready to test this yourself? Download Tenvo’s native client for Windows, macOS and Linux, or try the browser client (public beta). If you want minimal ops overhead use Tenvo's multi-region managed relay; self-host only if regulations force it. Get the client at Download Tenvo.