Videos per CPU in H265 umzuwandeln, ist besonders langsam. Mit der Grafikkarte muss das besser werden, oder? Das wurde es tatsächlich. Allerdings mit einem unerwarteten Seiteneffekt & weiteren Umständen, die zu durchwachsenen Ergebnissen führen. Ich habe auf der Nvidia GeForce RTX 3070 Ti eine ganze Reihe an Videos aus unterschiedlichen Quellen umgewandelt: Von Handys, vollwertigen Systemkameras bis hin zu Internetvideos aus Mediatheken & co.
Der folgende Artikel zeigt, warum selbst leistungsstarke Prozessoren bei hochauflösenden Videos an ihre Grenzen stoßen. Und wie sich die Umwandlung auf der GPU von der CPU unterscheidet. Anhand der Messungen werden Stärken & Schwächen der unterschiedlichen Technologie klar. Während der Fokus auf Nvidia liegt, lässt sich vieles mit wenig Anpassungen auch auf andere Hersteller von Grafikkarten (AMD/Intel) übertragen. Die gängigsten Codecs unterstützt ffmpeg auf allen drei großen Plattformen.
Warum Videos umwandeln?
Ich wandle oft und viele Videos um. Hauptsächlich geht es dabei um drei Szenarien:
- Nutzung von unterstützen Formaten im Rohschnitt, primär für DaVinci Resolve unter GNU/Linux
- Umwandlung in Legacy-Formate für kommerzielle Soziale Netzwerke (alle großen akzeptieren bis heute kein H265 oder AV1)
- Archivieren mit möglichst geringem Speicherbedarf bei hoher Qualität
Speicher war zwar billig. Mit großen Mengen an Videomaterial summiert sich der Platzbedarf dennoch in beachtliche Dimensionen. Insbesondere, wenn das Gesamtbild betrachtet wird – jedes GB soll schließlich nicht nur abgelegt, sondern auch gesichert werden. Dazu kommen Details, die sich mit mehr Hardware nicht lösen lassen: Unterwegs mit langsamer und/oder im Quota begrenzter Internetanbindung macht es einen gewaltigen Unterschied, ob ich 40 MB oder 400 MB herunterlade. Letztere Dimensionen sind mit hochauflösenden 4K Videos schnell erreicht: Mein Galaxy S23+ erzeugt für ein 1:34 Video stolze 464 MB.
Dank des „KI“ Hypes ist mittlerweile nicht mal mehr der Speicher billig. Auf absehbare Zeit wird das weiterhin so bleiben – sofern nicht die Blase vorher platzt. Somit ein Grund mehr, das Thema zu vertiefen.
Was bisher funktioniert hat…
Vor längerem habe ich mich intensiver mit ffmpeg beschäftigt und als Ergebnis einen Artikel mit 15 nützlichen Befehlen geschrieben. Der erste Tipp zeigte mehrere Wege, wie sich der Speicherbedarf von Videos reduzieren lässt: Durch verlustbehaftete Kompression innerhalb des gleichen Codecs (meist H264). Das vermeide ich, außer es geht nicht anders bzw. es ist für die Zielgruppe irrelevant. Wesentlich besser ist die Verwendung effizienter Codecs wie H265 (Belastet durch Patente) oder AV1: Sie reduzieren die Dateigröße meist massiv, ohne Qualitätseinbußen. Noch größer ist das Optimierungspotenzial, wenn unsichtbare Qualitätsverluste hinnehmbar sind.
Es kommt stark darauf an, welche Einstellungen bei der Quelle gesetzt sind und wie umfangreich diese bereits Optimiert. Meiner Erfahrung nach lässt sich selbst bei professionellen Quellen (etwa Downloads aus Mediatheken) einiges heraus holen. Am meisten Ersparnis liefern selbst aufgenommene Videos: Smartphones & Kameras sind oft sehr konservativ und erlauben wenige relevante Einstellung, wohl zur Vereinfachung. Ich habe daher ein Skript im Einsatz, welches die Videos in einem Ordner umwandelt. Für Full-HD Material funktioniert das zufriedenstellend.
…stößt an seine Grenzen
Anders sieht es mit höheren Auflösungen aus. Für fertige Videos reicht Full-HD auch 2026 in vielen Fällen vollkommen aus. Doch beim Rohmaterial setze ich mittlerweile bewusst auf 4K: Hier habe ich viel mehr Spielraum für Zooms. 1080P Videos lassen sich nur begrenzt für ein gutes 1080P Ergebnis vergrößern. In 4K Material lässt sich hingegen reichlich Zoomen, ohne dass der Zuschauer das bei Full-HD bemerkt. Insbesondere für meine eigene Bibliothek zur Wiederverwendung ist das sinnvoll, im Zweifel 4K statt nur 1080P zu haben.
Trotz AMD Ryzen 9 3900X macht 4K Material auf der CPU jedoch wenig Spaß: Mein 1:34 Minuten langes 4K Testvideo verkleinert sich zwar erheblich von 486 MB (Original vom Galaxy S23+) auf 91 MB – mal eben mehr als Faktor 5 gespart. Doch das dauert geschlagene 3:07 Min. Für gewöhnlich habe ich mehr & längere Videos. Es dauert also eine Weile, bis ich damit arbeiten kann. 1080P ist deutlich flotter, selbst wenn es nur als Ausgabeauflösung dient. Ich habe daher mein Quellmaterial oft an dieser Stelle auf Full-HD herunter skaliert. Außer, mir war an dieser Stelle bereits klar, dass ich 4K benötige.
ffmpeg -i 20260320_170344.mp4 -vcodec libx265 -crf 26 -vf scale=1920x1080 20260320_170344-libx265-crf26-fhd.mp4Damit schrumpft das 486 MB große 4K-Video auf kompakte 32 MB & das in nur 1:18 Minuten. Also noch deutlich kleiner & schneller.
Geschwindigkeit in ffmpeg Messen
An dieser Stelle ist es interessant zu wissen, welche Metriken ffmpeg selbst erhebt, um die Geschwindigkeit ablesen zu können. Für die gesamte Verarbeitungsdauer kann man schlicht das GNU/Werkzeug time verwenden. Es misst die gesamte Ausführungsdauer eines Befehls. Ebenfalls interessant, doch ffmpeg zeigt bereits ein paar Zahlen in der Statuszeile am Ende der Ausgabe:
frame= 561 fps= 34 q=25.9 size= 5120KiB time=00:00:18.83 bitrate=2227.1kbits/s speed=1.14x elapsed=0:00:16.50Am einfachsten & relevantesten ist speed. Es gibt den Zeitfaktor von Eingangs- zu Ausgangsmaterial an. 1x würde bedeuten, die Umwandlung dauert exakt so lange, wie die Abspieldauer des Videos. Mit 1.14x sind wir in diesem Falle minimal schneller. Das lässt sich mit elapsed und time belegen: Ersteres ist die real vergangene Zeit, ffmpeg läuft also seit 16.5 Sekunden. Dagegen zeigt time den Zeitstempel des Videos, der gerade verarbeitet wird. Alternativ kann man auch auf fps schauen: Je mehr Bilder pro Sekunde, um so schneller sind wir fertig.
Die obige Ausgabe zeigt 4K H265 Eingangsmaterial zu 1080P H265. Ohne herunter skalieren (d.H. 4K H265 als Ausgabe) bricht die Geschwindigkeit deutlich ein. Wichtig hierbei: Die Anzeige ist eine Momentaufnahme. Im Verlauf des Prozesses wird sie schwanken, ähnlich wie die Übertragungsrate beim Kopieren von Dateien. Signifikante & damit relevante Unterschiede lassen sich dennoch erkennen. In diesem Szenario ist 4K zu 1080P offensichtlich deutlich schneller, als 4K zu 4K.
frame= 379 fps= 15 q=33.5 size= 9216KiB time=00:00:12.76 bitrate=5913.7kbits/s speed= 0.5x elapsed=0:00:25.51Verlagern auf die GPU
Grundsätzlich wird es komplizierter, weil die Hardwarebeschleunigung näher an der Hardware ist. Und die Implementierungen sich je nach GPU unterscheiden, da sie proprietär sind. Wer die Rechenleistung der Grafikkarte genutzt hat (etwa für KI), hat diese Erfahrung sicherlich bereits gemacht: CUDA ist Nvidias GPGPU-Plattform. Die lässt sich auf Karten von AMD oder neuerdings Intel nicht einsetzen. Bestenfalls existiert eine Abstraktionsschicht, welche deren Plattformen unterstützt. Ansonsten funktioniert das ganze nur mit Karten von Nvidia.
Diesen Low-Level Aufwand erspart uns ffmpeg, da es Implementierungen für die gängigsten drei GPU-Hersteller Nvidia, AMD & Intel enthält. Allerdings sind sie kein 1:1 Ersatz. Sondern bringen eigene Parameter mit, die sich sowohl von den CPU-Encodern, als auch den Implementierungen anderer GPUs unterscheiden. In ffmpeg sind diese als Encoder umsetzt, im Falle von H265/HEVC lauten sie:
- Nvidia: hevc_nvenc
- AMD: hevc_vaapi
- Intel (QuickSync): hevc_qsv
Ob ffmpeg mit diesen kompiliert wurde, lässt sich wie folgt herausfinden:
$ ffmpeg -hide_banner -encoders | grep hevc_
V....D hevc_amf AMD AMF HEVC encoder (codec hevc)
V....D hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)
V..... hevc_v4l2m2m V4L2 mem2mem HEVC encoder wrapper (codec hevc)
V....D hevc_vaapi H.265/HEVC (VAAPI) (codec hevc)
V....D hevc_vulkan H.265/HEVC (Vulkan) (codec hevc)Weitere Encoder werden auf der GPU unterstützt. Aber nicht alle auf jeder GPU. Wer beispielsweise den freien Codec AV1 nutzen möchte, kann dies nur auf Nvidia (av1_nvenc) und Intel (av1_qsv) tun – AMD bleibt außen vor. Das ist ein wesentlicher Unterschied zu den CPU-Encodern. Hier existiert beispielsweise libsvtav1, der auf allen X86-Prozessoren zur Verfügung steht. Ob von AMD oder Intel, spielt keine Rolle. Je nach Szenario & Hardware ist man auf der GPU also ggf. eingeschränkt oder kann die gewünschte Konstellation nicht nutzen.
Beim mittlerweile relativ verbreiteten H265 ist dies unproblematisch. Für meine Nvidia-Karte benötige ich hevc_nvenc. Welche Parameter dieser unterstützt, kann ffmpeg ausgeben:
ffmpeg -hide_banner -h encoder=hevc_nvencWas sich ändert
Diese relativ umfangreiche Liste hilft allerdings nur weiter, wenn ein grundlegendes Verständnis vorhanden ist, was man davon benötigt. Das sind mindestens zwei Parameter:
-presetgibt das Verhältnis von Verarbeitungsgeschwindigkeit zum Ergebnis an, also schneller oder effizienter-cqist ein Faktor für die Bildqualität
Es stehen insgesamt 19 Presets für hevc_nvenc bereit. Der Standard ist p3 (Mittel). Am langsamsten beim besten Ergebnis ist p7. Nicht alle sind mit pX durchnummert, weitere Benennungen wie hq oder slow existieren. Auf der GPU läuft H265 derart schnell, dass selbst das langsamste p7 noch immer deutlich schneller ist, als libx265 per CPU.
-cq steht für Constant Quality. Wer libx265 oder libx264 kennt, wird sich an CRF (Constant Rate Factor) erinnern: Er soll eine einfache Möglichkeit bieten, um die Qualität für das gesamte Video möglichst gleichmäßig zu beeinflussen. Ohne händisch an verschiedenen Stellschrauben wie z.B. der Bitrate zu drehen. CQ aus der GPU-Implementierung geht in eine ähnliche Richtung: Ein Ziel für die visuelle Qualität. Allerdings ist es kein strikter Qualitätsmodus. Diese kann schwanken, etwa bei schnellen Bewegungen. Die Skala bewegt sich zwischen 0 und 51. Kleinere Zahlen stehen für höhere Qualität bei steigender Dateigröße.
ffmpeg auf der GPU nutzen
Die Standard-CRF von 28 bei libx265 entspricht ungefähr CQ 33 – 36. Mit höherwertiger CRF 22 sind es CQ 27-30. Das kann jedoch nur als ungefähre Orientierung verwendet werden. Für ruhigere Aufnahmen können höhere Werte reichen, um von der geringeren Dateigröße zu profitieren. Schnelle Szenenwechsel hingegen erscheinen minderwertiger.
Mit p7 auf CQ33 erreicht die Nvidia GeForce RTX 3070 Ti einen Geschwindigkeitsfaktor von 1,3 und ist damit etwas schneller, als 4K zu FHD auf der CPU. Ein deutlicher Fortschritt im Vergleich zu den 0,5x innerhalb von 4K Material. Das Ergebnis ist mit 88 MB sogar etwas kleiner wie die 4K Edition von libx265.
ffmpeg -i 20260320_170344.mp4 -c:v hevc_nvenc -preset p7 -cq 33 20260320_170344-hevc_nvenc-p7-cq33.mp4In meinen Tests ist der Einfluss von Presets gering: Bei gleicher CQ ist P1 nur 41 MB größer, als P7. Der größere Hebel ist CQ, wie man es von den CPU-Codecs her kennt. Bereits mit CQ30 steigt die Größe deutlich auf 143 MB. Mit CQ35 kommen wir auf 66 MB. Allerdings bei entsprechend reduzierter Qualität, über die man eine große Diskussion starten kann. Wer auf Nummer Sicher geht, wählt CR ~ 27-28. Hierbei steigt die Größe deutlich auf 220 MB.
Weitere Videos: Kann NVENC mit anderem Material überzeugen?
Da Eigenheiten einzelner Videos die Dateigröße & somit das Ergebnis beeinflussen können, habe ich mein Skript zur Umwandlung in H265 angepasst. Es wandelte jedes Video zunächst per NVENC auf der GPU um. Anschließend dasselbe Eingangsmaterial erneut mit libx265 über den Prozessor. Dies ist im Alltag natürlich wenig sinnvoll & sollte nur kurzzeitig dem Vergleich dienen, ob die Ergebnisse mit unterschiedlichen Videos möglicherweise stärker variieren. Zur Vollständigkeit enthält die erste Zeile das zuvor genannte Beispielvideo.
| Originales Rohmaterial | libx265 CRF24 | NVENC P7 CQ28 | libx265 -> NVENC |
|---|---|---|---|
| 486 MB | 129 MB | 196 MB | +51,9 % |
| 264 MB | 44 MB | 83 MB | +88,6 % |
| 386 MB | 72 MB | 126 MB | +75 % |
| 700 MB | 112 MB | 210 MB | +87,5 % |
| 464 MB | 123 MB | 188 MB | +52,9 % |
Es handelt sich hierbei um keine künstlich erzeugten Testvideos. Sondern Aufnahmen, die ich entweder für U-Labs Videos, oder privat mit dem Galaxy S23+ angefertigt habe. Durch das Skript ist garantiert, dass die Parameter identisch sind. Grundsätzlich erzeugt NVENC in jedem Falle deutlich größere Dateien, als libx265. Wie vermutet ist dieser Unterschied allerdings nicht immer gleich groß, sondern kann variieren. Selbst dann, wenn die Videos nur leicht variieren – wie etwas näher heran, ansonsten mit der gleichen Kulisse.
Videos der Sony Alpha 6400
Nur einen Teil der Videos zeichne ich mit dem Galaxy S23 auf. Für einige weitere nutze ich mit der Sony Alpha 6400 eine vollwertige, spiegel lose Systemkamera. Daher wurden einige Messungen mit Rohmaterial von der Sony durchgeführt. Überraschend ist der Unterschied von der libx265 (CPU) Umwandlung im Vergleich zu NVENC auf der Grafikkarte: Er fällt deutlich geringer aus. Wir haben außerdem eine viel kleinere Streubreite, obwohl es sich ebenfalls um fünf unterschiedliche Aufnahmen handelt.
| Originales Rohmaterial | libx265 CRF24 | NVENC P7 CQ28 | libx265 -> NVENC |
|---|---|---|---|
| 273 MB | 80 MB | 89 MB | +11,3 % |
| 513 MB | 129 MB | 156 MB | +20,9 % |
| 2,3 GB | 580 MB | 695 MB | + 19,8 % |
| 181 MB | 48 MB | 55 MB | + 14,6 % |
| 609 MB | 177 MB | 193 MB | + 9 % |
Internetvideos
Wie sieht es mit öffentlich zugänglichen Quellen aus dem Internet aus, etwa Markus Lanz? Da diese in der Mediathek zum Streamen & Herunterladen angeboten werden, sollten diese zumindest grundlegend optimiert sein. Das ZDF liefert noch immer H264 aus, in 1080P mit 50 Bildern/Sekunde. Der Geschwindigkeitsfaktor liegt mit 2.95x bei NVENC deutlich höher. Auf der CPU erreicht libx265 nur 1.6x.
| Originales Rohmaterial | libx265 CRF24 | NVENC P7 CQ28 | libx265 -> NVENC |
|---|---|---|---|
| 2,4 GB (ZDF) | 1,1 GB | 2,1 GB | +90,9 % |
| 1,8 GB (ZDF) | 656 MB | 1,4 GB | +113,4 % |
| 2,3 GB (ZDF) | 1,0 GB | 2,0 GB | +100 % |
| 2,9 GB (ZDF) | 1,3 GB | 2,5 GB | +92,3 % |
| 2,9 GB (ARD) | 1,3 GB | 2,2 GB | +69,2 % |
| 363 MB (ARD) | 175 MB | 292 MB | +66,9 % |
| 4,8 GB (Film) | 1,7 GB | 2,0 GB | +17,7 % |
| 11 GB (Film) | 2,4 GB | 3,0 GB | +25 % |
| 391 MB (yt-dlp) | 503 MB | 650 MB | +29,2 % |
| 269 MB (yt-dlp) | 190 MB | 286 MB | +50,5 % |
| 43 MB (JDownloader/NTV) | 18 MB | 20 MB | +11,1 % |
Bei den heruntergeladenen YouTube-Videos ist die GPU mit 5,9x noch weitaus schneller. Allerdings erzielen beide Umwandlungen in H265 größere Dateien. Dies ist darauf zurückzuführen, dass yt-dlp bereits umfangreich optimiert. Folgende Parameter wurden für den Download gesetzt:
yt-dlp -S "height:1080,ext:mp4:m4a" --recode-video mp4 "$1"Der Film erzielt per GPU 7.03x – bei einer Spieldauer von insgesamt 1:55h erfrischend. In nur 16:20 min ist der gesamte Film umwandelt, mit dem Prozessor dauert es 49:06 Minuten. Hier liefert NVENC das beste Ergebnis: Nur rund 18% höherer Speicherbedarf bei deutlich schnellerer Verarbeitung.
Wie verhalten sich CRF und CR?
Für libx265 (CPU) nutzt ffmpeg standardmäßig CRF 28. Das ist ein Kompromiss, bei dem die Details ein Stück weit verloren gehen. CRF 18 ist visuell verlustfrei, ab ungefähr CRF22 werden leichte Qualitätsverluste beim genaueren hinsehen sichtbar. Da die meisten wahrscheinlich zuerst libx265 auf der CPU nutzen, ist dies eine ungefähre Grundlage.
Die Betonung liegt auf ungefähr, weil es bereits hier auf die Ansprüche & Umstände ankommt. Auf einem hochwertigen 4K Beamer sieht ein Video anders aus, als auf dem Full-HD Bildschirm. Wird das Video lediglich auf einem Smartphone konsumiert, kann die Qualität noch deutlich weiter reduziert werden – ohne sichtbare Einbußen auf dem kleinen Bildschirm. Möglicherweise gibt es zudem weitere Rahmenbedingungen, wie Größenlimits. Chatdienste wie WhatsApp verschicken zudem keine Originalaufnahmen, sondern komprimieren diese zusätzlich. Daher ist es unmöglich, pauschal für alle zu sagen: CRF22 ist notwendig, oder CRF28+ reicht.
Bei hevc_nvenc wird es noch komplizierter, weil CQ ja eben keine in jeder Situation garantierte Qualität bietet. Schon deswegen lässt sich CRF nicht direkt in CQ umrechnen.
Kann es CUDA besser?
Eine Alternative besteht darin, auf der GPU mit NVDEC via CUDA zu dekodieren. Folgendes Beispiel entspricht dabei dem obigen, welches ohne CUDA nur auf NVDEC setzt. Die Geschwindigkeit ist vergleichbar, bei der Dateigröße sieht es ähnlich aus: Mit CUDA 199 MB, ohne kommen wir – bei ansonsten identischen Parametern – auf 196 MB. Somit ist das Ergebnis etwas schlechter. 3 MB sind zwar kein nennenswerter Unterschied. Allerdings eben auch nicht besser.
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i 20260320_170344.mp4 -c:v hevc_nvenc -preset p7 -cq 28 20260320_170344-cuda-hevc_nvenc-p7-cq28.mp4Rohdaten der Haupt-Testaufnahme
20260320_170344.mp4 ist das zu Beginn erwähnte Beispielvideo, mit dem ich die Tests der Parameter sowie das Dokumentieren in diesem Beitrag durchgeführt habe. Es kann nicht als repräsentativ angesehen werden. Teils sind weitere Messungen enthalten, welche oben mangels Relevanz keine Erwähnung fanden. Die Messungen mit der größeren Anzahl an unterschiedlicher Videos ist in der Tabellen hinterlegt.
199M 20260320_170344-cuda-hevc_nvenc-p7-cq28.mp4
198M 20260320_170344-hevc_cuvid-forced-p7-cq28.mp4
237M 20260320_170344-hevc_nvenc-p1-cq28.mp4
196M 20260320_170344-hevc_nvenc-p5-cq28.mp4
220M 20260320_170344-hevc_nvenc-p7-cq27.mp4
196M 20260320_170344-hevc_nvenc-p7-cq28-b0-maxrate0.mp4
196M 20260320_170344-hevc_nvenc-p7-cq28.mp4
143M 20260320_170344-hevc_nvenc-p7-cq30.mp4
103M 20260320_170344-hevc_nvenc-p7-cq32.mp4
88M 20260320_170344-hevc_nvenc-p7-cq33.mp4
66M 20260320_170344-hevc_nvenc-p7-cq35.mp4
184M 20260320_170344-libx265-crf22.mp4
129M 20260320_170344-libx265-crf24.mp4
108M 20260320_170344-libx265-crf25.mp4
32M 20260320_170344-libx265-crf26-fhd.mp4
91M 20260320_170344-libx265-crf26.mp4
486M 20260320_170344.mp4Fazit: Lohnt sich das?
Das Auslagern auf die GPU ist bei 4K in allen Testfällen deutlich schneller. Allerdings unterscheiden sich GPU- Implementierung bei H265: Sie ist weniger effizient, als die libx265 CPU-Variante. CQ schwankt mehr als CRF, daher sollte man im Zweifel lieber eine geringere CQ nutzen. Ansonsten kann es bei schnellen Szenen negative Überraschungen geben – die im schlimmsten Falle erst bemerkt werden, wenn das Rohmaterial weg ist. Wer das nicht riskieren möchte, erkauft sich die höhere Geschwindigkeit mit größeren Dateien. Oder im Vergleich zum Originalmaterial weniger kleinen. Der Unterschied variiert stark je nach Quellaufnahmen. Am geringsten fielen sie mit der Sony Alpha Systemkamera aus.
Da größere Dateien bei mir einiges ausmachen & ich Teile später weiter verwende, bleibe ich primär bei libx265. Es ist langsamer, dafür die stabilere Technik: Per CRF kann ich Qualität recht sicher sowie einheitlich festlegen. Dies habe ich ausführlich getestet und bei sehr vielen Videos angewendet, es funktioniert zuverlässig. Wenn Geschwindigkeit an erster Stelle steht, dann ist die Auslagerung auf die GPU eine schnellere Alternative, die sich für 4K lohnen kann.
Es entscheiden die konkreten Anforderungen, was im Einzelfall sinnvoller ist. Insbesondere bei sehr langen Aufnahmen/Filmen macht sich der Geschwindigkeitsvorteil der GPU erheblich bemerkbar & kann in Relation zum höheren Speicherverbrauch lohnenswert sein. Auch bei der Sony Alpha ist der Mehrverbrauch durch NVENC vergleichsweise gering.