Skip to content
Alle Systeme betriebsbereitv0.16.44AGPL-3.0KOSTENLOSE STUFE · 30 GERÄTETenvo AI · MCP FÜR CLAUDE & CURSOR
Zurück zum BlogTechnical

Remote-Desktop-Codec: H.264 vs H.265 vs AV1

Tenvo Editorial Team7 Min. Lesezeit
Remote-Desktop-Codec: H.264 vs H.265 vs AV1

Wenn Ihre Remote-Sitzungen träge wirken, weil die CPU mit dem Encoden beschäftigt ist, oder instabil erscheinen, weil das Netzwerk nicht mithält, liegt es meist an der Codec-Wahl. Dieser Leitfaden vergleicht H.264, H.265 und AV1 mit praxisnahen Messwerten zu Bitraten, CPU-Last, Latenz und sinnvollen Presets für 1080p/60fps.

Wenn Ihre Remote-Sitzungen entweder träge wirken, weil die CPU mit dem Encoden beschäftigt ist, oder instabil erscheinen, weil das Netzwerk nicht mithält, ist die Codec-Wahl in der Regel die Ursache. Dieser Leitfaden vergleicht H.264, H.265 und AV1 für reale Remote-Desktop-Workloads — mit verwertbaren Zahlen: Bitraten, CPU-Last, Latenz und sinnvolle Presets für 1080p- und 60fps-Anwendungen.

Warum die Codec-Wahl für Remote-Desktop wichtig ist

Remote-Desktop-Workloads sind nicht mit Streaming wie Netflix gleichzusetzen. Die meisten Sitzungen bestehen überwiegend aus Text und UI mit gelegentlichem Video; diese Mischung begünstigt Codecs und Presets, die auf Ruhigstellung und niedrige Latenz statt auf lange GOPs und maximale Kompression ausgelegt sind. Die Abwägungen, die Sie treffen müssen, sind:

  • Bandbreite: wie viele Megabit pro Sekunde Sie dauerhaft über WAN-/Mobilverbindungen aufbringen können.
  • CPU-Kosten: Encodieren benötigt Rechenzeit. Die CPU-Auslastung auf dem Gerät beeinflusst Reaktionsfähigkeit und Akkulaufzeit.
  • Latenz: Encode-Latenz und Keyframe-Intervalle beeinflussen das wahrgenommene Eingabeverzögerung.
  • Kompatibilität: welche Decoding- und Hardwarebeschleunigungsoptionen der Client und Browser unterstützen.

Testaufbau und Methodik (was diese Zahlen tatsächlich bedeuten)

Um die Ergebnisse praxisnah und reproduzierbar zu halten, habe ich eine repräsentative moderne Desktop-Maschine und gängige Software-Encoder verwendet. Wichtige Parameter wurden kontrolliert, damit die Zahlen auf reale Deployments übertragbar sind.

  • Hardware: Intel Core i7-10700K (8 cores / 16 threads) unter Windows 11.
  • Erfassung: Desktop-Bildschirm (1920×1080), drei Szenarien — statischer Desktop (Text & Fenster), gemischt (Webvideo + Scrollen) und hohe Bewegung (60fps Gameplay).
  • Encoder und Versionen: x264 (FFmpeg-Build mit x264), x265 3.5, SVT-AV1 1.8.0 und libaom 3.6.0, wo vermerkt. Für Hardware-Encode: NVIDIA NVENC auf einer RTX 2060.
  • Presets: Vergleich praxisnaher Presets (x264 veryfast, x265 veryfast, SVT-AV1 superfast), weil Remote-Desktops niedrige Latenz benötigen; CRF-äquivalente Qualitätsanpassung wurde verwendet, wo anwendbar.
  • Messungen: stationäre durchschnittliche Bitrate (Mbps), durchschnittliche System-CPU-Last (Prozent aller logischen Kerne) und gemessene Encoder-Latenz (ms) unter derselben Szene für 60 Sekunden.

Dies sind keine rein akademischen, laborbasierten Codec-Gegenüberstellungen — sondern praxisnahe, reale Zahlen, die Sie sehen, wenn Sie ein Remote-Tool an eine gemischte Desktop-Workload anschließen. Abweichungen entstehen durch andere CPU-Generationen, mehrere gleichzeitige Sitzungen oder schnellere AV1-Builds; betrachten Sie die Zahlen als Richtwerte und validieren Sie anhand der Tuning-Checkliste unten auf Ihrer Hardware.

Zahlen: Bitrate, CPU und Latenz für typische Szenarien

Tabelle: beobachtete stationäre Werte für 1080p-Erfassungen. Bitraten und CPU sind Durchschnitte aus repräsentativen Läufen. Latenz ist die am Encoder hinzugefügte Zeit (Round-Trip hängt von Netzwerk und Relay ab).

Szenario / CodecBitrate (Mbps)CPU-Auslastung (% des Gesamtsystems)Encoder-Latenz (ms)
1080p30 — statischer Desktop (Text)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 — gemischte Inhaltex264: 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 — hohe Bewegung / Spielx264: 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

Wichtigste Erkenntnisse aus der Tabelle:

  • H.265 (x265) reduziert die Bitrate gegenüber H.264 um etwa 30–40 % bei gleicher visueller Qualität, kostet aber in diesen Presets 2–3× mehr CPU und erhöht die Encoder-seitige Latenz.
  • AV1 (SVT-AV1) kann die Bitrate in vielen Fällen nochmals um 10–30 % gegenüber H.265 senken, allerdings zu hohen CPU- und Latenzkosten. Auf einem modernen Desktop belegt AV1 für brauchbare Presets häufig den Großteil der verfügbaren Kerne.
  • Hardware-Encoder (NVENC) verlagern die Last von der CPU auf GPU-Hardware. Die Bitrate liegt nahe an x264 veryfast-Qualität bei nahezu null CPU-Impact und niedriger Latenz, was sie zur offensichtlichen Wahl macht, wenn sie verfügbar sind.

Praktische Empfehlungen — welcher Codec wann

  • Wenn Sie eine GPU mit modernem NVENC (Turing oder neuer) haben, nutzen Sie diese für die meisten interaktiven Sitzungen. NVENC bietet geringe CPU-Kosten, niedrige Latenz und vorhersehbare Bitraten. Es ist der schnellste Weg zu guter UX für 1080p und 60fps.
  • Wenn Ihre Bandbreite sehr knapp ist (Mobile-Tethering oder Remote-Büro mit 2–3 Mbps Budget) und CPU auf beiden Enden reichlich vorhanden ist, kann H.265 (x265) 30–40 % Bandbreite gegenüber H.264 sparen — auf Kosten höherer CPU und Latenz; nützlich für unbeaufsichtigte Verbindungen oder Bildschirmaufzeichnungen, bei denen Latenz weniger kritisch ist.
  • Verwenden Sie AV1 nur, wenn Bandbreitenersparnis essentiell ist und Sie die Endpunkte kontrollieren bzw. genügend CPU-Reserve (oder einen dedizierten Encoder) haben. Für interaktive Sitzungen sind AV1-Latenz und CPU-Kosten oft schlechter für die UX als die erzielte Bandbreiteneinsparung, es sei denn, Sie betreiben einen dedizierten Encoding-Server oder eine Hardware-AV1-Lösung.
  • Browser-basierte Clients schränken heute die Encoding-Optionen ein. AV1-Encoding im Browser ist noch unausgereift — wenn Sie auf den Browser-Client angewiesen sind (der Browser-Client von Tenvo befindet sich in öffentlicher Beta), bevorzugen Sie serverseitiges Encoding oder Hardware-Unterstützung am Relay für die beste UX.
  • Für gemischten Remote-Arbeitsgebrauch (Text, gelegentliche Videos) bleibt x264 mit angepassten Presets (siehe nächsten Abschnitt) das beste Gesamt-Verhältnis aus Latenz und Bandbreite auf CPU-limitierten Maschinen.

Tenvo-Positionierung: verwaltetes Relay vs Self-Hosting und Hardware-Optionen

Operativ sind die Kosten für den Betrieb eines eigenen Relays (Patching, Zertifikatserneuerung, Multi-Region-Failover, Schlüsselverwaltung) erheblich. Für die meisten Teams ist ein Multi-Region-verwalteter Relay-Dienst die richtige Voreinstellung — das bietet auch der verwaltete Relay-Dienst von Tenvo (Multi-Region, Free $0 / Lite $2.99/mo / Pro $7.99/mo-Pläne) und vereinfacht das Bereitstellen hardware-beschleunigter Server, wenn Sie diese benötigen.

Self-Hosting des Relays ist nur dann die richtige Wahl, wenn Sie eine schriftliche Anforderung haben, die Drittinfrastruktur verbietet (regulatorische Datenresidenz, isoliertes Netzwerk oder formale Compliance-Anforderung). Wenn das auf Sie zutrifft, folgen Sie den Hinweisen in Self-Hosted Remote Desktop: Why, How, and What Breaks — sonst sollten Sie damit rechnen, dass das verwaltete Relay unter Berücksichtigung von Bereitschaftsdiensten und Patching günstiger ist.

Hinweis zur Sicherheit: Wenn eine Sitzung ein Relay nutzt, terminiert TLS am Relay und der Relay-Betreiber hat technisch die Möglichkeit, auf Session-Traffic zuzugreifen. Tenvo verwendet gerätespezifische Zertifikate für Verbindungen; ein direkter Peer-to-Peer-Pfad vermeidet Relay-Terminierung, aber Fallbacks auf Relays sind häufig und sollten im Threat-Model angenommen werden. Siehe Remote desktop encryption: what actually protects a session und Is Remote Desktop Secure? An Honest Threat Model für Details.

Tuning-Checkliste und Beispiel-Encoder-Befehle

Praktische Stellschrauben für den Einsatz:

  • Bevorzugen Sie für interaktive Sitzungen Hardware-Encoding (NVENC / QSV / VideoToolbox), wenn verfügbar.
  • Bei Software-Encodern wählen Sie schnellere Presets (x264 veryfast oder ultrafast) und erhöhen Sie CRF/Bitrate konservativ; Remote-Desktop ist empfindlicher gegenüber Latenz als gegenüber perfekter Kompression.
  • Verwenden Sie ein kurzes Keyframe-Intervall (1–2s), um nach Paketverlust schnell visuell wiederherstellbar zu sein; setzen Sie keine massiven GOPs wie beim VOD.
  • Aktivieren Sie 'zerolatency'-Optionen, wo verfügbar (x264 tune=zerolatency), wenn interaktive Reaktionsfähigkeit wichtig ist.
  • Profilieren Sie für den tatsächlichen Inhalt — textlastige Bildschirme komprimieren deutlich besser als Video; passen Sie die Bitrate an oder wechseln Sie den Codec, wenn die Sitzung in konstante hohe Bewegung übergeht (Spiel/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.

Wann Sie welchen Codec wählen sollten — kurzer Entscheidungsfluss

  1. Haben Sie eine leistungsfähige GPU mit Hardware-Encode? Nutzen Sie diese (NVENC/QSV/VideoToolbox).
  2. Ist Bandbreite Ihre strikteste Einschränkung und kontrollieren Sie beide Endpunkte? Ziehen Sie H.265 (x265) in Betracht, sofern Lizenz/Policy dies erlauben.
  3. Ist die Bandbreite extrem knapp und Sie können hohe CPU-Last oder einen dedizierten Encoder erlauben? Ziehen Sie AV1 (SVT-AV1) in Betracht, aber nur für Sitzungen, bei denen Latenz und CPU-Last akzeptabel sind.
  4. Verwenden Sie ausschließlich Browser-Clients oder gemischte Geräte? Bleiben Sie bei H.264 oder nutzen Sie Hardware-Encode-Fallbacks für größtmögliche Kompatibilität.

Wenn Sie tiefer lesen möchten zu Bandbreitenstrategien und messbaren Ansätzen, siehe Remote desktop bandwidth: the maths and how to cut it und Remote desktop low bandwidth: optimization guide. Wenn Remote-Gaming oder 60fps-Interaktivität eine Anforderung ist, entsprechen die Abwägungen denen in unserer Best remote desktop for gaming: Parsec vs Moonlight-Analyse.

Praktische Abschlussbemerkung: Führen Sie eine schnelle Validierung auf Ihrer am häufigsten genutzten Zielmaschine durch. Messen Sie die stationäre Bitrate mit einer 60–120 Sekunden langen Aufnahme der typischen Workload und profilieren Sie CPU sowie End-to-End-Latenz. Kleine Anpassungen am Preset oder Keyframe-Intervall bringen oft große UX-Verbesserungen.

Bereit zum Testen? Laden Sie den nativen Client von Tenvo für Windows, macOS und Linux herunter oder probieren Sie den Browser-Client (öffentliche Beta). Wenn Sie minimalen Betriebsaufwand wünschen, nutzen Sie Tenvo's Multi-Region-verwaltetes Relay; self-hosten Sie nur, wenn Vorschriften es erfordern. Holen Sie sich den Client unter Tenvo herunterladen.

Tenvo herunterladen

Bereit, es selbst auszuprobieren?

Kostenlos für 30 Geräte, keine Kreditkarte. In zwei Minuten einsatzbereit und verbunden.