einen Artikel mit 15 n\u00fctzlichen Befehlen geschrieben<\/a>. Der erste Tipp zeigte mehrere Wege, wie sich der Speicherbedarf von Videos reduzieren l\u00e4sst: Durch verlustbehaftete Kompression innerhalb des gleichen Codecs (meist H264). Das vermeide ich, au\u00dfer es geht nicht anders bzw. es ist f\u00fcr die Zielgruppe irrelevant. Wesentlich besser ist die Verwendung effizienter Codecs wie H265 (Belastet durch Patente) oder AV1: Sie reduzieren die Dateigr\u00f6\u00dfe meist massiv, ohne Qualit\u00e4tseinbu\u00dfen. Noch gr\u00f6\u00dfer ist das Optimierungspotenzial, wenn unsichtbare Qualit\u00e4tsverluste hinnehmbar sind.<\/p>\nEs kommt stark darauf an, welche Einstellungen bei der Quelle gesetzt sind und wie umfangreich diese bereits Optimiert. Meiner Erfahrung nach l\u00e4sst 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\u00fcr Full-HD Material funktioniert das zufriedenstellend.<\/p>\n
…st\u00f6\u00dft an seine Grenzen<\/h2>\n Anders sieht es mit h\u00f6heren Aufl\u00f6sungen aus. F\u00fcr fertige Videos reicht Full-HD auch 2026 in vielen F\u00e4llen vollkommen aus. Doch beim Rohmaterial setze ich mittlerweile bewusst auf 4K: Hier habe ich viel mehr Spielraum f\u00fcr Zooms. 1080P Videos lassen sich nur begrenzt f\u00fcr ein gutes 1080P Ergebnis vergr\u00f6\u00dfern. In 4K Material l\u00e4sst sich hingegen reichlich Zoomen, ohne dass der Zuschauer das bei Full-HD bemerkt. Insbesondere f\u00fcr meine eigene Bibliothek zur Wiederverwendung ist das sinnvoll, im Zweifel 4K statt nur 1080P zu haben.<\/p>\n
Trotz AMD Ryzen 9 3900X macht 4K Material auf der CPU jedoch wenig Spa\u00df: 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\u00fcr gew\u00f6hnlich habe ich mehr & l\u00e4ngere Videos. Es dauert also eine Weile, bis ich damit arbeiten kann. 1080P ist deutlich flotter, selbst wenn es nur als Ausgabeaufl\u00f6sung dient. Ich habe daher mein Quellmaterial oft an dieser Stelle auf Full-HD herunter skaliert. Au\u00dfer, mir war an dieser Stelle bereits klar, dass ich 4K ben\u00f6tige.<\/p>\n
ffmpeg -i 20260320_170344.mp4 -vcodec libx265 -crf 26 -vf scale=1920x1080 20260320_170344-libx265-crf26-fhd.mp4<\/code><\/pre>\nDamit schrumpft das 486 MB gro\u00dfe 4K-Video auf kompakte 32 MB & das in nur 1:18 Minuten. Also noch deutlich kleiner & schneller.<\/p>\n
Geschwindigkeit in ffmpeg Messen<\/h2>\n An dieser Stelle ist es interessant zu wissen, welche Metriken ffmpeg selbst erhebt, um die Geschwindigkeit ablesen zu k\u00f6nnen. F\u00fcr die gesamte Verarbeitungsdauer kann man schlicht das GNU\/Werkzeug time<\/code> verwenden. Es misst die gesamte Ausf\u00fchrungsdauer eines Befehls. Ebenfalls interessant, doch ffmpeg zeigt bereits ein paar Zahlen in der Statuszeile am Ende der Ausgabe:<\/p>\nframe= 561 fps= 34 q=25.9 size= 5120KiB time=00:00:18.83 bitrate=2227.1kbits\/s speed=1.14x elapsed=0:00:16.50<\/code><\/pre>\nAm einfachsten & relevantesten ist speed<\/em>. Es gibt den Zeitfaktor von Eingangs- zu Ausgangsmaterial an. 1x w\u00fcrde bedeuten, die Umwandlung dauert exakt so lange, wie die Abspieldauer des Videos. Mit 1.14x sind wir in diesem Falle minimal schneller. Das l\u00e4sst sich mit elapsed<\/em> und time<\/em> belegen: Ersteres ist die real vergangene Zeit, ffmpeg l\u00e4uft also seit 16.5 Sekunden. Dagegen zeigt time<\/em> den Zeitstempel des Videos, der gerade verarbeitet wird. Alternativ kann man auch auf fps<\/em> schauen: Je mehr Bilder pro Sekunde, um so schneller sind wir fertig.<\/p>\nDie 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, \u00e4hnlich wie die \u00dcbertragungsrate 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.<\/p>\n
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.51<\/code><\/pre>\nVerlagern auf die GPU<\/h2>\n Grunds\u00e4tzlich wird es komplizierter, weil die Hardwarebeschleunigung n\u00e4her an der Hardware ist. Und die Implementierungen sich je nach GPU unterscheiden, da sie propriet\u00e4r sind. Wer die Rechenleistung der Grafikkarte genutzt hat (etwa f\u00fcr KI<\/em>), hat diese Erfahrung sicherlich bereits gemacht: CUDA ist Nvidias GPGPU-Plattform. Die l\u00e4sst sich auf Karten von AMD oder neuerdings Intel nicht einsetzen. Bestenfalls existiert eine Abstraktionsschicht, welche deren Plattformen unterst\u00fctzt. Ansonsten funktioniert das ganze nur mit Karten von Nvidia.<\/p>\nDiesen Low-Level Aufwand erspart uns ffmpeg, da es Implementierungen f\u00fcr die g\u00e4ngigsten drei GPU-Hersteller Nvidia, AMD & Intel enth\u00e4lt. 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:<\/p>\n
\nNvidia: hevc_nvenc <\/li>\n AMD: hevc_vaapi<\/li>\n Intel (QuickSync): hevc_qsv<\/li>\n<\/ul>\nOb ffmpeg mit diesen kompiliert wurde, l\u00e4sst sich wie folgt herausfinden:<\/p>\n
$ ffmpeg -hide_banner -encoders | grep hevc_\n V....D hevc_amf AMD AMF HEVC encoder (codec hevc)\n V....D hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)\n V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)\n V..... hevc_v4l2m2m V4L2 mem2mem HEVC encoder wrapper (codec hevc)\n V....D hevc_vaapi H.265\/HEVC (VAAPI) (codec hevc)\n V....D hevc_vulkan H.265\/HEVC (Vulkan) (codec hevc)<\/code><\/pre>\nWeitere Encoder werden auf der GPU unterst\u00fctzt. Aber nicht alle auf jeder GPU. Wer beispielsweise den freien Codec AV1 nutzen m\u00f6chte, kann dies nur auf Nvidia (av1_nvenc) und Intel (av1_qsv) tun – AMD bleibt au\u00dfen vor. Das ist ein wesentlicher Unterschied zu den CPU-Encodern. Hier existiert beispielsweise libsvtav1, der auf allen X86-Prozessoren zur Verf\u00fcgung steht. Ob von AMD oder Intel, spielt keine Rolle. Je nach Szenario & Hardware ist man auf der GPU also ggf. eingeschr\u00e4nkt oder kann die gew\u00fcnschte Konstellation nicht nutzen.<\/p>\n
Beim mittlerweile relativ verbreiteten H265 ist dies unproblematisch. F\u00fcr meine Nvidia-Karte ben\u00f6tige ich hevc_nvenc. Welche Parameter dieser unterst\u00fctzt, kann ffmpeg ausgeben:<\/p>\n
ffmpeg -hide_banner -h encoder=hevc_nvenc<\/code><\/pre>\nWas sich \u00e4ndert<\/h2>\n Diese relativ umfangreiche Liste hilft allerdings nur weiter, wenn ein grundlegendes Verst\u00e4ndnis vorhanden ist, was man davon ben\u00f6tigt. Das sind mindestens zwei Parameter:<\/p>\n
\n-preset<\/code> gibt das Verh\u00e4ltnis von Verarbeitungsgeschwindigkeit zum Ergebnis an, also schneller oder effizienter<\/li>\n-cq<\/code> ist ein Faktor f\u00fcr die Bildqualit\u00e4t<\/li>\n<\/ul>\nEs stehen insgesamt 19 Presets f\u00fcr 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<\/em> oder slow<\/em> existieren. Auf der GPU l\u00e4uft H265 derart schnell, dass selbst das langsamste p7 noch immer deutlich schneller ist, als libx265 per CPU.<\/p>\n-cq <\/code>steht f\u00fcr Constant Quality<\/em>. Wer libx265 oder libx264 kennt, wird sich an CRF<\/em> (Constant Rate Factor) erinnern: Er soll eine einfache M\u00f6glichkeit bieten, um die Qualit\u00e4t f\u00fcr das gesamte Video m\u00f6glichst gleichm\u00e4\u00dfig zu beeinflussen. Ohne h\u00e4ndisch an verschiedenen Stellschrauben wie z.B. der Bitrate zu drehen. CQ<\/em> aus der GPU-Implementierung geht in eine \u00e4hnliche Richtung: Ein Ziel f\u00fcr die visuelle Qualit\u00e4t. Allerdings ist es kein strikter Qualit\u00e4tsmodus. Diese kann schwanken, etwa bei schnellen Bewegungen. Die Skala bewegt sich zwischen 0 und 51. Kleinere Zahlen stehen f\u00fcr h\u00f6here Qualit\u00e4t bei steigender Dateigr\u00f6\u00dfe.<\/p>\nffmpeg auf der GPU nutzen<\/h2>\n Die Standard-CRF von 28 bei libx265 entspricht ungef\u00e4hr CQ 33 – 36. Mit h\u00f6herwertiger CRF 22 sind es CQ 27-30. Das kann jedoch nur als ungef\u00e4hre Orientierung verwendet werden. F\u00fcr ruhigere Aufnahmen k\u00f6nnen h\u00f6here Werte reichen, um von der geringeren Dateigr\u00f6\u00dfe zu profitieren. Schnelle Szenenwechsel hingegen erscheinen minderwertiger.<\/p>\n
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.<\/p>\n
ffmpeg -i 20260320_170344.mp4 -c:v hevc_nvenc -preset p7 -cq 33 20260320_170344-hevc_nvenc-p7-cq33.mp4<\/code><\/pre>\nIn meinen Tests ist der Einfluss von Presets gering: Bei gleicher CQ ist P1 nur 41 MB gr\u00f6\u00dfer, als P7. Der gr\u00f6\u00dfere Hebel ist CQ, wie man es von den CPU-Codecs her kennt. Bereits mit CQ30 steigt die Gr\u00f6\u00dfe deutlich auf 143 MB. Mit CQ35 kommen wir auf 66 MB. Allerdings bei entsprechend reduzierter Qualit\u00e4t, \u00fcber die man eine gro\u00dfe Diskussion starten kann. Wer auf Nummer Sicher geht, w\u00e4hlt CR ~ 27-28. Hierbei steigt die Gr\u00f6\u00dfe deutlich auf 220 MB.<\/p>\n
Weitere Videos: Kann NVENC mit anderem Material \u00fcberzeugen?<\/h2>\n Da Eigenheiten einzelner Videos die Dateigr\u00f6\u00dfe & somit das Ergebnis beeinflussen k\u00f6nnen, habe ich mein Skript zur Umwandlung in H265 angepasst. Es wandelte jedes Video zun\u00e4chst per NVENC auf der GPU um. Anschlie\u00dfend dasselbe Eingangsmaterial erneut mit libx265 \u00fcber den Prozessor. Dies ist im Alltag nat\u00fcrlich wenig sinnvoll & sollte nur kurzzeitig dem Vergleich dienen, ob die Ergebnisse mit unterschiedlichen Videos m\u00f6glicherweise st\u00e4rker variieren. Zur Vollst\u00e4ndigkeit enth\u00e4lt die erste Zeile das zuvor genannte Beispielvideo.<\/p>\n\n\n\n\nOriginales Rohmaterial<\/th>\n libx265 CRF24<\/th>\n NVENC P7 CQ28<\/th>\n libx265 -> NVENC<\/th>\n<\/tr>\n<\/thead>\n \n\n486 MB<\/td>\n 129 MB<\/td>\n 196 MB<\/td>\n +51,9 %<\/td>\n<\/tr>\n \n264 MB<\/td>\n 44 MB<\/td>\n 83 MB<\/td>\n +88,6 %<\/td>\n<\/tr>\n \n386 MB<\/td>\n 72 MB<\/td>\n 126 MB<\/td>\n +75 %<\/td>\n<\/tr>\n \n700 MB<\/td>\n 112 MB<\/td>\n 210 MB<\/td>\n +87,5 %<\/td>\n<\/tr>\n \n464 MB<\/td>\n 123 MB<\/td>\n 188 MB<\/td>\n +52,9 %<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\nEs handelt sich hierbei um keine k\u00fcnstlich erzeugten Testvideos. Sondern Aufnahmen, die ich entweder f\u00fcr U-Labs Videos, oder privat mit dem Galaxy S23+ angefertigt habe. Durch das Skript ist garantiert, dass die Parameter identisch sind. Grunds\u00e4tzlich erzeugt NVENC in jedem Falle deutlich gr\u00f6\u00dfere Dateien, als libx265. Wie vermutet ist dieser Unterschied allerdings nicht immer gleich gro\u00df, sondern kann variieren. Selbst dann, wenn die Videos nur leicht variieren – wie etwas n\u00e4her heran, ansonsten mit der gleichen Kulisse.<\/p>\n
Videos der Sony Alpha 6400<\/h2>\n Nur einen Teil der Videos zeichne ich mit dem Galaxy S23 auf. F\u00fcr einige weitere nutze ich mit der Sony Alpha 6400 eine vollwertige, spiegel lose Systemkamera. Daher wurden einige Messungen mit Rohmaterial von der Sony durchgef\u00fchrt. \u00dcberraschend ist der Unterschied von der libx265 (CPU) Umwandlung im Vergleich zu NVENC auf der Grafikkarte: Er f\u00e4llt deutlich geringer aus. Wir haben au\u00dferdem eine viel kleinere Streubreite, obwohl es sich ebenfalls um f\u00fcnf unterschiedliche Aufnahmen handelt.<\/p>\n\n\n\n\nOriginales Rohmaterial<\/th>\n libx265 CRF24<\/th>\n NVENC P7 CQ28<\/th>\n libx265 -> NVENC<\/th>\n<\/tr>\n<\/thead>\n \n\n273 MB<\/td>\n 80 MB<\/td>\n 89 MB<\/td>\n +11,3 %<\/td>\n<\/tr>\n \n513 MB<\/td>\n 129 MB<\/td>\n 156 MB<\/td>\n +20,9 %<\/td>\n<\/tr>\n \n2,3 GB<\/td>\n 580 MB<\/td>\n 695 MB<\/td>\n + 19,8 %<\/td>\n<\/tr>\n \n181 MB<\/td>\n 48 MB<\/td>\n 55 MB<\/td>\n + 14,6 %<\/td>\n<\/tr>\n \n609 MB<\/td>\n 177 MB<\/td>\n 193 MB<\/td>\n + 9 %<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\nInternetvideos<\/h2>\n Wie sieht es mit \u00f6ffentlich zug\u00e4nglichen 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<\/strong> bei NVENC deutlich h\u00f6her. Auf der CPU erreicht libx265 nur 1.6x<\/strong>.<\/p>\n\n\n\n\nOriginales Rohmaterial<\/th>\n libx265 CRF24<\/th>\n NVENC P7 CQ28<\/th>\n libx265 -> NVENC<\/th>\n<\/tr>\n<\/thead>\n \n\n2,4 GB (ZDF)<\/td>\n 1,1 GB<\/td>\n 2,1 GB<\/td>\n +90,9 %<\/td>\n<\/tr>\n \n1,8 GB (ZDF)<\/td>\n 656 MB<\/td>\n 1,4 GB<\/td>\n +113,4 %<\/td>\n<\/tr>\n \n2,3 GB (ZDF)<\/td>\n 1,0 GB<\/td>\n 2,0 GB<\/td>\n +100 %<\/td>\n<\/tr>\n \n2,9 GB (ZDF)<\/td>\n 1,3 GB<\/td>\n 2,5 GB<\/td>\n +92,3 %<\/td>\n<\/tr>\n \n2,9 GB (ARD)<\/td>\n 1,3 GB<\/td>\n 2,2 GB<\/td>\n +69,2 %<\/td>\n<\/tr>\n \n363 MB (ARD)<\/td>\n 175 MB<\/td>\n 292 MB<\/td>\n +66,9 %<\/td>\n<\/tr>\n \n4,8 GB (Film)<\/td>\n 1,7 GB<\/td>\n 2,0 GB<\/td>\n +17,7 %<\/td>\n<\/tr>\n \n11 GB (Film)<\/td>\n 2,4 GB<\/td>\n 3,0 GB<\/td>\n +25 %<\/td>\n<\/tr>\n \n391 MB (yt-dlp)<\/td>\n 503 MB<\/td>\n 650 MB<\/td>\n +29,2 %<\/td>\n<\/tr>\n \n269 MB (yt-dlp)<\/td>\n 190 MB<\/td>\n 286 MB<\/td>\n +50,5 %<\/td>\n<\/tr>\n \n43 MB (JDownloader\/NTV)<\/td>\n 18 MB<\/td>\n 20 MB<\/td>\n +11,1 %<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\nBei den heruntergeladenen YouTube-Videos ist die GPU mit 5,9x noch weitaus schneller. Allerdings erzielen beide Umwandlungen in H265 gr\u00f6\u00dfere Dateien. Dies ist darauf zur\u00fcckzuf\u00fchren, dass yt-dlp bereits umfangreich optimiert. Folgende Parameter wurden f\u00fcr den Download gesetzt:<\/p>\n
yt-dlp -S "height:1080,ext:mp4:m4a" --recode-video mp4 "$1"<\/code><\/pre>\nDer 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\u00f6herer Speicherbedarf bei deutlich schnellerer Verarbeitung.<\/p>\n
Wie verhalten sich CRF und CR?<\/h2>\n F\u00fcr libx265 (CPU) nutzt ffmpeg standardm\u00e4\u00dfig CRF 28. Das ist ein Kompromiss, bei dem die Details ein St\u00fcck weit verloren gehen. CRF 18 ist visuell verlustfrei, ab ungef\u00e4hr CRF22 werden leichte Qualit\u00e4tsverluste beim genaueren hinsehen sichtbar. Da die meisten wahrscheinlich zuerst libx265 auf der CPU nutzen, ist dies eine ungef\u00e4hre Grundlage. <\/p>\n
Die Betonung liegt auf ungef\u00e4hr, weil es bereits hier auf die Anspr\u00fcche & Umst\u00e4nde 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\u00e4t noch deutlich weiter reduziert werden – ohne sichtbare Einbu\u00dfen auf dem kleinen Bildschirm. M\u00f6glicherweise gibt es zudem weitere Rahmenbedingungen, wie Gr\u00f6\u00dfenlimits. Chatdienste wie WhatsApp verschicken zudem keine Originalaufnahmen, sondern komprimieren diese zus\u00e4tzlich. Daher ist es unm\u00f6glich, pauschal f\u00fcr alle zu sagen: CRF22 ist notwendig, oder CRF28+ reicht.<\/p>\n
Bei hevc_nvenc wird es noch komplizierter, weil CQ ja eben keine in jeder Situation garantierte Qualit\u00e4t bietet. Schon deswegen l\u00e4sst sich CRF nicht direkt in CQ umrechnen.<\/p>\n
Kann es CUDA besser?<\/h2>\n 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\u00f6\u00dfe sieht es \u00e4hnlich 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.<\/p>\n
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.mp4<\/code><\/pre>\nRohdaten der Haupt-Testaufnahme<\/h2>\n 20260320_170344.mp4<\/code> ist das zu Beginn erw\u00e4hnte Beispielvideo, mit dem ich die Tests der Parameter sowie das Dokumentieren in diesem Beitrag durchgef\u00fchrt habe. Es kann nicht als repr\u00e4sentativ angesehen werden. Teils sind weitere Messungen enthalten, welche oben mangels Relevanz keine Erw\u00e4hnung fanden. Die Messungen mit der gr\u00f6\u00dferen Anzahl an unterschiedlicher Videos ist in der Tabellen hinterlegt.<\/p>\n199M 20260320_170344-cuda-hevc_nvenc-p7-cq28.mp4\n198M 20260320_170344-hevc_cuvid-forced-p7-cq28.mp4\n237M 20260320_170344-hevc_nvenc-p1-cq28.mp4\n196M 20260320_170344-hevc_nvenc-p5-cq28.mp4\n220M 20260320_170344-hevc_nvenc-p7-cq27.mp4\n196M 20260320_170344-hevc_nvenc-p7-cq28-b0-maxrate0.mp4\n196M 20260320_170344-hevc_nvenc-p7-cq28.mp4\n143M 20260320_170344-hevc_nvenc-p7-cq30.mp4\n103M 20260320_170344-hevc_nvenc-p7-cq32.mp4\n 88M 20260320_170344-hevc_nvenc-p7-cq33.mp4\n 66M 20260320_170344-hevc_nvenc-p7-cq35.mp4\n184M 20260320_170344-libx265-crf22.mp4\n129M 20260320_170344-libx265-crf24.mp4\n108M 20260320_170344-libx265-crf25.mp4\n 32M 20260320_170344-libx265-crf26-fhd.mp4\n 91M 20260320_170344-libx265-crf26.mp4\n486M 20260320_170344.mp4<\/code><\/pre>\nFazit: Lohnt sich das?<\/h2>\n Das Auslagern auf die GPU ist bei 4K in allen Testf\u00e4llen 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 \u00dcberraschungen geben – die im schlimmsten Falle erst bemerkt werden, wenn das Rohmaterial weg ist. Wer das nicht riskieren m\u00f6chte, erkauft sich die h\u00f6here Geschwindigkeit mit gr\u00f6\u00dferen 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.<\/p>\n
Da gr\u00f6\u00dfere Dateien bei mir einiges ausmachen & ich Teile sp\u00e4ter weiter verwende, bleibe ich prim\u00e4r bei libx265. Es ist langsamer, daf\u00fcr die stabilere Technik: Per CRF kann ich Qualit\u00e4t recht sicher sowie einheitlich festlegen. Dies habe ich ausf\u00fchrlich getestet und bei sehr vielen Videos angewendet, es funktioniert zuverl\u00e4ssig. Wenn Geschwindigkeit an erster Stelle steht, dann ist die Auslagerung auf die GPU eine schnellere Alternative, die sich f\u00fcr 4K lohnen kann. <\/p>\n
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\u00f6heren Speicherverbrauch lohnenswert sein. Auch bei der Sony Alpha ist der Mehrverbrauch durch NVENC vergleichsweise gering.<\/p>\n","protected":false},"excerpt":{"rendered":"
Videos per CPU in H265 umzuwandeln, ist besonders langsam. Mit der Grafikkarte muss das besser werden, oder? Das wurde es tats\u00e4chlich. Allerdings mit einem unerwarteten Seiteneffekt & weiteren Umst\u00e4nden, die zu durchwachsenen Ergebnissen f\u00fchren. Ich habe auf der Nvidia GeForce RTX 3070 Ti eine ganze Reihe an Videos aus unterschiedlichen Quellen umgewandelt: Von Handys, vollwertigen …<\/p>\n","protected":false},"author":5,"featured_media":16996,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[835],"tags":[778],"class_list":["post-16924","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-digitale-bild-und-videobearbeitung","tag-ffmpeg"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16924","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=16924"}],"version-history":[{"count":44,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16924\/revisions"}],"predecessor-version":[{"id":16992,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16924\/revisions\/16992"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/16996"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=16924"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=16924"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=16924"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}