Hardware-Videoencoder im Vergleich: NVENC vs AMF vs QuickSync vs Apple VideoToolbox.

Vier Hersteller. Vier Blöcke Festfunktions-Silizium. Eine Aufgabe — ein Bild aus Pixeln in unter fünf Millisekunden in ein paar Kilobyte H.265 oder AV1 verwandeln, sechzigmal pro Sekunde, ohne eines zu verlieren. So schneiden NVIDIA, AMD, Intel und Apple beim Low-Latency-Streaming tatsächlich ab, und so wählt Remio zur Laufzeit den richtigen aus.

Warum Hardware-Encoder für Remote Desktop wichtig sind

Kodieren Sie ein einzelnes 1080p-Bild mit libx264 auf einem schnellen CPU-Kern. Auf einem modernen Apple M-Chip oder einem Ryzen 7000 schaffen Sie für das Preset ultrafast grob 8 bis 12 Millisekunden, bei allem, was Qualität zu erhalten versucht, länger. Das klingt erträglich, bis man sich das Budget vor Augen führt: 16,6 Millisekunden pro Bild bei 60 FPS. Rechnen Sie nun Aufnahme, Paketierung, Pacer-Warteschlange, Netzwerkausgang, Dekodierung und Darstellung dazu. CPU-Kodierung bremst Sie nicht nur — sie frisst das gesamte Latenzbudget, und bei allem jenseits von 1080p60 verliert sie Bilder.

Hardware-Encoder lösen das, indem sie Festfunktions-Silizium für dieselbe Aufgabe bereitstellen. NVIDIA nennt seinen Block NVENC. AMD nennt seinen AMF (genauer: die VCN-Engine, die AMF ansteuert). Intel nennt seinen QuickSync (die Media Engine in der iGPU). Apple nennt seinen VideoToolbox (die API; das Silizium ist die Media Engine in den Chips der M- und A-Serie). Alle vier existieren aus einem Grund: Software-Kodierung kann die Latenz- und Bildratenziele nicht erreichen, die moderne Bildschirme, moderne GPUs und moderne Nutzer heute erwarten.

Für Remio gilt konkret: Jede Millisekunde, die am Encoder gespart wird, bekommt der Nutzer am Pacer, im Netzwerk und bei der Darstellung zurück. Unser veröffentlichtes Latenzbudget zielt im LAN auf rund 8 ms Verarbeitung (der Rest ist die 60-Hz-Bildwiederholung Ihres Displays) — die Kodierzeit ist die größte einzelne Variable. Die Wahl des Encoders und seine Konfiguration bestimmen alles Nachgelagerte.

Die vier Hersteller im Überblick

Bevor wir jeden im Detail betrachten, hilft es zu verstehen, was wir eigentlich vergleichen. Das sind keine austauschbaren Bibliotheken — es sind physische Blöcke auf einem Die, jeder mit eigener ISA, eigenem Treiber-Stack, eigenen Eigenheiten und eigener mehrjähriger Roadmap. Sie unterscheiden sich darin, welche Codecs sie unterstützen, welche Qualität sie liefern, welche Latenz sie erreichen, wie viel Strom sie ziehen und auf welchen Plattformen es sie überhaupt gibt.

• NVENC steckt seit 2012 (Kepler) in jeder NVIDIA GeForce, Quadro und RTX. Die Generationen sind an Architekturfamilien gebunden: 1. Generation bei Kepler, 8. Generation bei Ada Lovelace. Hopper-Rechenzentrumsteile haben einen anderen Takt.
• AMF stellt AMDs VCN-Engine (Video Core Next) bereit, die das ältere VCE ablöste. Verfügbar auf jeder Vega-, RDNA-, RDNA2- und RDNA3-GPU sowie auf neueren APUs.
• QuickSync steckt seit Sandy Bridge 2011 in Intel-iGPUs — und ist damit der am weitesten verbreitete Hardware-Encoder der Welt. Arc-Grafikkarten nutzen dieselbe Architektur, hochskaliert.
• VideoToolbox ist die Apple-API; das Silizium darunter ist die Media Engine, fest eingebaut in jeden Apple-Silicon-Mac, jedes iPhone seit dem A6 und jedes iPad. M-Chips haben je nach Ausführung eine oder zwei Engines.

NVENC — NVIDIAs acht Generationen der Verfeinerung

NVENC ist der Encoder, an dem die meiste Streaming-Software gemessen wird, teils weil NVIDIA das Marketingbudget hat, teils weil das Silizium ein Jahrzehnt lang tatsächlich hervorragend war. Der Block hat acht Generationen durchlaufen:

• 1.–3. Generation (Kepler bis Maxwell, 2012–2014) — nur H.264, fürs Streaming brauchbar, aber die Qualität lag klar hinter libx264.
• 4. Generation (Pascal, GTX-10-Serie) — fügte H.265-Kodierung hinzu. In dieser Generation holte die NVENC-Qualität die fast-Presets von libx264 bei gleicher Bitrate ein und übertraf sie wohl.
• 6. Generation (Turing, RTX-20-Serie, GTX-16-Serie) — der oft zitierte „Turing-NVENC“-Sprung. Die Qualität bei niedrigen Bitraten verbesserte sich so weit, dass Streamer nicht mehr so taten, als sei CPU-Kodierung für Live-Anwendungen spürbar besser.
• 7. Generation (Ampere, RTX-30-Serie) — Verfeinerungen, pro Watt im Wesentlichen gleichwertige Qualität wie Turing.
• 8. Generation (Ada Lovelace, RTX-40-Serie) — erste NVIDIA-Generation mit Hardware-AV1-Kodierung, plus doppelte Encoder-Engines in höheren Ausführungen. Ada-NVENC schafft AV1 in einer Qualität, die mit den Medium-Presets von libaom-av1 mithält, bei einem winzigen Bruchteil der CPU-Kosten.

Für den Low-Latency-Einsatz bietet NVENC drei relevante Ratenkontroll-Modi. CBR mit low-latency-Tuning und dem Preset p1 (am schnellsten) ist die kanonische Konfiguration: deterministische Ausgaberate, Lookahead von einem Bild, keine B-Frames. Genau das nutzt Remio unter Windows mit hevc_nvenc. Die Kodierzeit auf Ada Lovelace bei 1080p60 H.265 liegt durchgängig bei 1 bis 3 ms.

Ein historischer Stolperstein: Consumer-NVENC war jahrelang per NVIDIA-Treiber auf drei gleichzeitige Kodiersitzungen begrenzt. Diese Grenze wurde 2023 auf acht angehoben und dann faktisch aufgehoben. Wenn Sie einen veralteten Forenbeitrag lesen, der davor warnt: Die Warnung gilt nicht mehr.

AMF — AMDs Außenseiter, der endlich aufgeholt hat

AMDs AMF (Advanced Media Framework) ist die API; die darunterliegende Engine hat zwei unterschiedliche Architekturen durchlaufen. Das ältere VCE (Video Coding Engine) steckte seit 2012 in Karten der GCN-Ära und war die ewige Schwachstelle in Encoder-Direktvergleichen — bei gleicher Bitrate sichtbar schlechtere Qualität als NVENC, besonders bei bewegungsreichen Inhalten. AMD wusste das, die Streaming-Community wusste das, und Benchmarks bestätigten es.

Das änderte sich mit VCN (Video Core Next), eingeführt mit Vega und über jede folgende Generation verfeinert:

• VCN 1.0–2.0 (Vega, RDNA1) — H.264 und H.265 mit einer Qualität, die endlich haarscharf an NVENC Pascal/Turing herankam.
• VCN 3.0 (RDNA2, RX-6000-Serie) — deutliche Qualitätsverbesserungen, besonders bei niedrigen Bitraten. Die erste AMD-Generation, die ich bedenkenlos für Game-Streaming empfehle.
• VCN 4.0 (RDNA3, RX-7000-Serie) — fügt AV1-Kodierung parallel zu NVIDIA Ada hinzu. Zwei Encoder in höheren Ausführungen für parallele Sitzungen. Die AV1-Qualität hält in Benchmarks Dritter mit NVIDIAs AV1 mit.

Für Low-Latency-Streaming bietet AMF ein Nutzungs-Preset ultralowlatency, ein Qualitäts-Preset speed und einen Ratenkontroll-Modus cbr. Remio nutzt hevc_amf mit allen dreien — demselben Preset-Trio, das in unseren Notizen zur Streaming-Architektur dokumentiert ist. Die Kodierzeit auf RDNA3 bei 1080p60 H.265 liegt typischerweise bei 2 bis 4 ms. RDNA2 liegt bei etwa 3 bis 5 ms. Ältere Karten der VCN-1.x-Ära laufen eher mit 5 bis 7 ms — noch innerhalb des Budgets, aber mit weniger Spielraum für Keyframe-Spitzen.

Fünf Jahre lang war AMDs Encoder eine Pointe. RDNA2 hat es repariert. RDNA3 hat ihn bei AV1 konkurrenzfähig gemacht. Das Streaming-Encoder-Duopol ist jetzt ein Triopol, und das ist gut für alle.

QuickSync — der stille Champion der Verbreitung

QuickSync ist der Encoder, den Sie mit ziemlicher Sicherheit schon besitzen. Er steckt seit Sandy Bridge 2011 in jeder Intel-CPU mit integrierter Grafik — das sind über ein Jahrzehnt Laptops, NUCs und Büro-Desktops mit ungenutzter Hardware-Videokodierung, weil Nutzer annahmen, sie bräuchten eine dedizierte GPU. Brauchten sie nicht.

Die Architektur hat sich im Gleichschritt mit Intels iGPU-Linie entwickelt:

• Sandy Bridge bis Skylake (2011–2015) — nur H.264, mittelmäßige Qualität, aber führend bei Latenz und Energiebedarf für einen Laptop.
• Kaby Lake bis Coffee Lake (2016–2018) — fügten H.265, 10 Bit und 4K-Kodierung hinzu.
• Ab Ice Lake (2019+) — die Xe-iGPU der Gen11/Gen12 verbesserte die Qualität drastisch. In vielen Benchmarks liegt Gen12-QuickSync nur wenige Prozent hinter NVENC Turing.
• Arc dediziert (2022+) — Intels erste Reihe dedizierter GPUs. Dieselbe Xe-HPG-Architektur, hochskaliert, mit AV1-Kodierung. Arc war die erste Consumer-GPU mit Hardware-AV1 — noch vor NVIDIA Ada und AMD RDNA3 am Markt — und die Qualität ist überraschend ausgezeichnet. Eine Intel Arc A380 bleibt ein absurdes Schnäppchen für reinen AV1-Durchsatz pro Dollar.

Das thermische Profil ist QuickSyncs leise Superkraft. Weil er in einer iGPU lebt, die ohnehin auf dem SoC sitzt, sind die Grenzkosten seiner Nutzung nur der Encode-Block selbst — keine dedizierte GPU, die aufgeweckt werden müsste, keine GDDR6-Speichercontroller, die anlaufen. Auf einem ThinkPad oder NUC liefert QuickSync eine mit NVENC vergleichbare Qualität bei etwa einem Viertel der Leistungsaufnahme auf Systemebene. Auf Remios Windows-Host ist QuickSync die dritte Wahl nach NVENC und AMF — nicht, weil er schlechter wäre, sondern weil Nutzer mit dedizierter GPU ihre iGPU meist für andere Aufgaben frei haben wollen.

VideoToolbox — die einheitliche Media Engine von Apple Silicon

Apple vermarktet seinen Hardware-Encoder nicht unter einem Markennamen wie NVIDIA. Die API heißt VideoToolbox; das Silizium ist die Media Engine, ein von Apple entworfener Block, der in jedem Mac der M-Serie und jedem iPhone-/iPad-SoC seit dem A6 sitzt.

Die Media Engine gibt es je nach Ausführung in unterschiedlicher Anzahl:

• M1, M2, M3 — eine Media Engine.
• M1 Pro/Max, M2 Pro/Max, M3 Pro/Max — zwei Media Engines.
• M1 Ultra, M2 Ultra — vier Media Engines (zwei pro verschmolzenem Die).
• M3 Max (16-Kern-CPU) — zwei Media Engines.
• M4-Familie — überarbeitete Media Engine mit verbessertem H.265-Durchsatz.

Jede Media Engine beherrscht H.264-, H.265- und ProRes-Kodierung und -Dekodierung in Hardware. Die ProRes-Kodierung ist das Hauptmerkmal für Videoeditoren — kein anderer Consumer-Chip bietet sie —, aber für das Streaming sind die relevanten Fähigkeiten effiziente H.265-Main10-Kodierung und erstaunlich niedrige Kodierlatenz.

Die eine bemerkenswerte Lücke: keine AV1-Kodierung in irgendeinem ausgelieferten Apple Silicon. Chips der M-Serie dekodieren AV1 seit dem M3, können es aber nicht kodieren. Beim Streamen von einem Mac ist H.265 auf absehbare Zeit der praktische Standard.

Wo Apple wirklich gewinnt, ist die Energieeffizienz. Bei einem M2 Pro, der 4K60-H.265 mit 30 Mbit/s kodiert, zieht die gesamte Media Engine grob 3 bis 5 Watt. Dieselbe NVENC-Last auf einer RTX 4070 zieht eher 35 Watt auf Systemebene — der größte Teil davon ist der Leerlaufsockel der dedizierten GPU, nicht der Encoder-Block. Bei einem Mac-mini-Host, der rund um die Uhr eingeschaltet auf einen Client wartet, ist das der Unterschied zwischen „auf der Stromrechnung kaum zu merken“ und „deutlich zu merken“.

Vergleich Seite an Seite

Hier sind die vier Engines auf denselben Achsen. Die Latenzwerte gelten für 1080p60 H.265 mit Ultra-Low-Latency-Presets, ohne B-Frames, mit VBV von einem Bild — der Remio-Konfiguration. Die Qualität ist eine grobe Wahrnehmungsrangfolge bei 8 Mbit/s CBR; die absoluten Unterschiede sind klein.

Die ehrliche Zusammenfassung: Bei den Einstellungen, die Remote-Desktop-Streaming tatsächlich nutzt (CBR, niedrige Latenz, keine B-Frames), sind alle vier mit komfortablem Abstand gut genug. Die Unterscheidungsmerkmale sind die AV1-Unterstützung (NVIDIA / AMD / Intel — nicht Apple), die Energieeffizienz (Apple, dann Intel-iGPU, dann alle anderen) und die Plattformverfügbarkeit (auf einem Windows-Host können Sie nicht VideoToolbox wählen, auf einem Mac nicht NVENC).

Was Remio zur Laufzeit wählt

Remio prüft beim Start die Fähigkeiten des Hosts und wählt den Encoder nach einer deterministischen Rangfolge. Der Windows-Host und der Mac-Host folgen derselben Auswahllogik.

Auf Windows-Hosts:

1. NVENC (hevc_nvenc / h264_nvenc) — als Erstes gewählt, wenn eine NVIDIA-GPU vorhanden ist und der Treiber antwortet. Bevorzugt, weil er über die breiteste Spanne von Hardwaregenerationen der durchgängig latenzärmste Encoder ist.
2. AMF (hevc_amf / h264_amf) — als Zweites gewählt, wenn eine dedizierte AMD-GPU oder APU mit VCN vorhanden ist. Konfiguriert mit usage=ultralowlatency, quality=speed, rc=cbr.
3. QuickSync (hevc_qsv / h264_qsv) — als Drittes gewählt, wenn eine Intel-iGPU vorhanden ist. In unserer Pipeline funktional gleichwertig; wir lassen die iGPU lieber frei, wenn eine dedizierte GPU verfügbar ist.
4. libx264-CPU-Fallback — nur gewählt, wenn kein Hardware-Encoder antwortet. Begrenzt auf 720p60 oder 1080p30, um im Latenzbudget zu bleiben.

Auf Apple-Hosts: VideoToolbox ist die einzige Option — und die einzige, die wir wollen. Die Media Engine in jedem unterstützten Mac (macOS 15+) beherrscht H.265 Main10 von Haus aus. Ein Fallback-Pfad ist nicht nötig.

Die Codec-Präferenz ist Hardware-H.265 zuerst, H.264 als universeller Fallback — durchgängig, auf jeder Plattform. Remio nutzt heute kein AV1 (Host-Kodierung, Client-Dekodierung und Codec-Aushandlung dafür sind nicht Teil der Pipeline); es bleibt selbst auf Hardware, die technisch AV1 könnte, bei H.265, weil im LAN die Kodierlatenz der Engpass ist, nicht die Bitrate.

Kompromisse zwischen Qualität und Latenz

Jeder Hardware-Encoder bietet dieselbe Handvoll Stellschrauben, und jede Stellschraube tauscht Qualität gegen Latenz in dieselbe Richtung. Die Remio-Konfiguration liegt am aggressivsten Ende des Latenzreglers, weil Remote Desktop per Definition eine Echtzeitanwendung ist, bei der ein Bild, das älter als 20 ms ist, schlimmer ist als ein Bild, das etwas unschärfer als ideal ist.

• CBR gegen VBR. Variable Bitrate liefert bei gleicher Durchschnittsrate bessere Qualität, weil sie Bits dort ausgibt, wo sie helfen. Aber VBR erzeugt auch unvorhersehbare Größen pro Bild, was unvorhersehbare Pacer-Warteschlangen bedeutet, was unvorhersehbare Latenz bedeutet. Remio nutzt überall CBR. Der Qualitätspreis ist klein; die Konstanz der Latenz ist enorm.
• B-Frames. B-Frames referenzieren vergangene und künftige Bilder, sodass der Decoder auf das künftige Bild warten muss, bevor er das B-Frame dekodiert. Für Video-on-Demand ist das in Ordnung, für Echtzeit fatal. Remio deaktiviert B-Frames bei jedem Codec auf jeder Plattform.
• GOP / Keyframe-Intervall. Längere GOPs (mehr Bilder zwischen Keyframes) komprimieren besser. Kürzere GOPs erholen sich schneller von Paketverlust. Remio fährt praktisch unendliche GOPs und fordert beim Host einen frischen Keyframe an, wenn der Decoder Verluste meldet. Ein verlorenes Paket wird sofort erneut gesendet, wenn es noch rechtzeitig ankommen kann; wenn nicht, überspringt Remio es und fordert ein frisches Bild an, statt zu warten. Das entspricht unserer Streaming-Philosophie, nur das neueste Bild darzustellen.
• Lookahead. NVENC, AMF und QuickSync unterstützen alle Mehrbild-Lookahead für adaptive Quantisierung. Jedes Lookahead-Bild fügt ein ganzes Bild Verzögerung hinzu. Remio nutzt null oder ein Bild Lookahead — die niedrigste Einstellung jedes Encoders.
• VBV-Puffer. Das Fenster des Video Buffering Verifier legt fest, wie viele Bits der Encoder „vorab ausleihen“ darf, bevor er zur Zielrate zurückfindet. Größerer VBV liefert gleichmäßigere Qualität. Kleinerer VBV liefert engere Ratenkontrolle und niedrigere Latenz. Remio nutzt 1 Bild VBV — die Bitrate geteilt durch die Bildrate —, den kleinsten zulässigen Wert.

Das Muster ist bei allen vier Herstellern gleich. Echtzeit mit niedriger Latenz ist eine beschränkte Optimierung: Sie geben die wenigen Prozent Qualität auf, die Lookahead und B-Frames bei der Offline-Kodierung bringen, im Tausch gegen die vorhersehbare Latenz, die Echtzeit-Interaktion verlangt. Jedes ausgelieferte Streaming-Produkt — Remio, Parsec, NVIDIA GeForce NOW, Xbox Cloud Gaming — geht denselben Tausch in dieselbe Richtung ein.

Worauf Sie (als Nutzer) wirklich achten müssen

Falls Sie bis zum Ende vorgeblättert haben: Der Hardware-Encoder jeder modernen GPU ist für Remote Desktop gut genug.

Die Unterschiede bei Echtzeit-Konfigurationen sind kleiner als das Grundrauschen jedes vernünftigen Benchmarks. Ein Nutzer mit Pascal GTX 1060 bekommt dasselbe Remio-Erlebnis wie einer mit RTX 4090 — beide schöpfen die 120-FPS-Pipeline mit rund 8 ms Verarbeitungslatenz aus (der Rest ist die 60-Hz-Bildwiederholung Ihres Displays), beide liefern bei LAN-Bitraten nicht unterscheidbare Ausgabe.

Die Ausnahmen, nach Häufigkeit ihrer Relevanz geordnet:

• AV1-fähige Hardware hilft im Allgemeinen in langsamen Netzwerken. Bei Hotel-WLAN oder mobilem Hotspot bringt ein Ada-/RDNA3-/Arc-Host mit M3+- oder RTX-40-Client bei Werkzeugen, die es nutzen, rund 25 Prozent mehr Spielraum bei gleicher Qualität. Im LAN nichts. Remio nutzt AV1 noch nicht — H.265 durchgängig ist die gesamte Pipeline —, daher ist das heute ein Vorteil des Herstellers, nicht von Remio.
• Apple-Silicon-Macs sind bemerkenswert gute Hosts. Die niedrige Latenz der Media Engine, das hervorragende H.265 und der Verbrauch von 3–5 W machen einen Mac mini oder Studio zu einer der besten dauerhaft laufenden Streaming-Quellen, die Sie kaufen können. Keine AV1-Kodierung ist die einzige Lücke, im LAN irrelevant.
• Eine Intel Arc A380 ist ein unvernünftiges Schnäppchen für AV1. Für ~120 $ bekommen Sie einen Encoder-Block, der alles andere unter 400 $ schlägt.
• Der libx264-CPU-Fallback ist real. Kein Hardware-Encoder — alter Laptop, Server ohne iGPU — Remio funktioniert trotzdem. Nur nicht in 4K mit 60, und nicht, ohne einen CPU-Kern zu verbrennen.

Jenseits dieser Randfälle ist die richtige Antwort die einfachste: Nutzen Sie die GPU, die Sie ohnehin kaufen würden. Jeder moderne Hersteller ist bei denselben Fähigkeiten, denselben Low-Latency-Presets und derselben Qualitätshülle angekommen. Remio wählt zur Laufzeit den richtigen aus, damit Sie nicht darüber nachdenken müssen. Machen Sie weiter mit dem, wofür Sie die Remote-Desktop-Sitzung geöffnet haben — programmieren, ein Video schneiden, einen Server reparieren, aus dem Café einen Fix einspielen.

Das ist der ganze Sinn von Festfunktions-Silizium. Es funktioniert einfach, und man hört auf, es zu bemerken.