HEVC H.265 - CPU Encoding - Performance, Qualität und Tipps

SD-Material wird (sofern es schon in H.264 vorliegt) überhaupt nicht rekodiert. SD-Privataufnahmen auf DV - da hatte ich jetzt 18 miniDV Kassetten - landen als H.264 mit AC3 als MP4 auf Platte/Stick, um größtmögliche Kompatibilität zu 'normalen' TV-Geräten zu gewährleisten.

Zitat von monarc99

Wegen der Artefakte in dunklen Bereichen. Hast du mal mit H265 aber 10 Bit probiert?Die AQ der Codecs sorgt dafür, dass helle und für das Auge besser sichtbare Bereiche immer deutlich mehr Bitrate bekommt. Dann reichts aber in dunklen Bereichen nicht aus.
Und man kann dann entweder den ganzen Film mit Bitrate tot schmeissen (und/oder an AQ rumdoktorn), was du mit dem niedrigeren crf Modus machst. Die bessere Option ist aber 10bit,
Im 10bit Modus reicht ihm die wenige Bitrate, um auch dunkle Bereich vernünftig darzustellen.

Das die Dateien größer werden, liegt am CRF Modus. Durch ein langsameres Preset wird Bitrate gespart und der CRF Modus investiert diese Bitrate, wenn er es für sinnvoll hält. Deshalb kann eine Datei bei verschiedenen Presets beim CRF Modus unterschiedlich groß werden.
Die Presets medium/slow/slower wirklich nur dazu verwenden, um die Geschwindigkeit des Codecs zu steuern. Und den Rate Faktor (crf) um die Qualität zu steuern.
Die Dateigröße, die am Ende beim CRF Modus rauskommt, hängt von sehr vielen Faktoren ab, die sich gegenseitig beeinflußen. Deshalb am besten ignorieren.
Bei mir variiert der CRF Wert immer etwas, kommt drauf an, wieviele feine Details ich aus dem Original übernehmen will.Je mehr feine Details ich übernehmen will, desto niedriger setze ich den CRF Wert.

Alles anzeigen

Dachte 10-Bit sei nur für HDR und 12-bit nur für DolbyVision Inhalte von Bedeutung. Werde ich mir mal genauer an schauen.

Das der CRF Faktor die Qualität steuert und die Presets die Geschwindigkeit des Kodierens sowie Einfluss auf die Dateigröße hat ist mir schon klar. Hab ich mich so verworren ausgedrückt?

Wie sieht es eigendlich mit 2-pass encoding aus? Das habe ich noch nicht ausprobiert. Hat das großen Einfluss auf die Dateigröße?

Und noch eine Frage in die Runde: Hat hier jemand schon Erfahrung mit AV1 gesammelt?

Zitat von te36

gruebel.. Quali 19/20 ist ja hoehere qualitaet also 21/22, richtig ?
Nimmst Du da eine niedrigere Qualitet fuer verrauschtes Material weil dir das in der hoeheren (19/20) qualitaet zuviel platz kosten wuerde ? Und die verfaelschungen des Rauschens durch die niedrigere Qualitaet "Ok" aussieht ?

Was nimmst Du als speed im Handbrake ? Das hat ja auch noch mal Einfluss auf die Dateigroesse (und zeit).

Was nimmst Du fuer die 720p serien an Parametern ?

Genau crf18/19 besser als crf21/22

Bei verrauschten Filme oder bei Filmen mit viel "Körnung" lohnt es meiner Meinung nach nicht in crf19 zu encodieren. Die Dateien werden zu groß und es sieht im Endeffekt nicht besser aus als in crf22 encoded. Man muss rumspielen, das ist dann eine Sache der persönlichen Erfahrung

Ich mache alles in preset medium.

Bei den 720p Serien nehme ich crf20 oder 21 mit preset medium.
Bei alten Serien in SD lohnt es nich mmn nicht, h265 zu benutzen. zB Eine Folge Magnum in h264 600MB waren bei mir in h265 ~500MB, bei gleicher Quali.

Zitat von Küstenlümmel

Genau crf18/19 besser als crf21/22
Bei verrauschten Filme oder bei Filmen mit viel "Körnung" lohnt es meiner Meinung nach nicht in crf19 zu encodieren. Die Dateien werden zu groß und es sieht im Endeffekt nicht besser aus als in crf22 encoded. Man muss rumspielen, das ist dann eine Sache der persönlichen Erfahrung

Ich mache alles in preset medium.

Bei den 720p Serien nehme ich crf20 oder 21 mit preset medium.
Bei alten Serien in SD lohnt es nich mmn nicht, h265 zu benutzen. zB Eine Folge Magnum in h264 600MB waren bei mir in h265 ~500MB, bei gleicher Quali.

Ueberlege gerade ob ich diese Logic automatisiert bekomme. Wuesste aber ohne Ansehen nicht, wie ich rauskriegen kann ob ein film viel Koernung/Rauschen hat oder nicht. Wenn ich einfach auf die Datenrate gucke die am Ende rauskommt koennte die sowohl durch viel Bewegung oder viel Koernung/Rauschen kommen... *hmm*

Zitat von Mister XY

Ja, AV1 dauert extrem lange zum encodieren. Aktuell nutzt av1 die Kerne beim encodieren überhaupt nicht effektiv. Ich glaube, es wird nur ein Kern verwendet. Muss mal schauen, ob der eine kern auch bei 100% Auslastung läuft. Zum Thema 10bit. x265 spielt seine stärken erst richtig mit 10bit aus, da er wohl dahingehend ausglegt ist. Hatte damals wirklich viele Filem mit 8 bit encodiert und sehr viele unschöne "Artefakte". Sprich, der Übergang in dunklen Stellen sah sehr unschön aus, so dass man dort öfter Blockbildung hatte. Dieses konnte man zwar mit diveresen Optionen minimieren wie "no-sao", "no-strong-intra-smoothing" und einen höheren "psy-rd" wert, aber das blähte die Datei auch sehr stark auf, so dass manche Filme am Ende bis zu 1 GB größer waren als ohne di erwähnten maßnahmen bzw. der 10 bit encode.

Ich hab AV1 mit rav1e probiert und auch bei mir hat der nur ein Thread benutzt. Obwohl per Parameter alle angewählt waren. Somit habe ich auch nie was zu Ende gerendert.

Zur Zeit teste ich grad meinen neuen TV und dabei sind mir kleine Artefakte bei Tron Legacy auf gefallen. Der stammt noch aus ersten Zeit der Archivierung. CRF20 bei Faster.

Habe gerade einen kleinen Testlauf gemacht mit einer 13 Minuten Sequenz ausdem Film. Mit zwei HD-Tonspuren und bei Preset Slow:

CRF20 - 10Bit: 1316MB
CRF18 - 8Bit: 1333MB
CRF18 - 10Bit: 1328MB
CRF16 - 8Bit: 1863MB
CRF18 - 10Bit: 1855MB

Optisch habe ich jetzt nur am PC-Monitor vergleichen aber die Artefakte sind schon bei CRF20-10Bit weg. Jetzt rendere ich gerade den ganzen Film mit CRF18 in 10 Bit. Das wird wohl mein neues HD-Setting.

Guter Tipp Mister XY!

Zitat von TempeltonPeck

Wie sieht es eigendlich mit 2-pass encoding aus? Das habe ich noch nicht ausprobiert. Hat das großen Einfluss auf die Dateigröße?

Beim 2-pass gibt man ja eine Bitrate an, weil man eine ganz genaue Dateigröße möchte ( um es auf DVD zu brennen z.B.)
2-pass ist bei x264 und x265 nur der CRF Modus, aber in 2 Durchgängen:

Zitat

CRF and 2-pass use identical bit allocation algorithms. All 2-pass does is pick the CRF value that gives the filesize you want. It's still using the CRF algorithm.

Der erste Pass berechnet nur den crf Wert, der genau zu der gewünschten Bitrate passt.

Zitat von TempeltonPeck

Und noch eine Frage in die Runde: Hat hier jemand schon Erfahrung mit AV1 gesammelt?

Ich hab schon häufiger mit AV1 probiert. Aber der ist mir einfach zu langsam, um das sinnvoll einzusetzen. Vielleicht wenn die ersten Hardware Encoder für AV1 kommen.

Zitat von noob_at_pc

Welche Tools / Software nutzt ihr, welche Einstellungen sind "wirklich Sinnvoll" für die möglichst originale / Beste Qualität? A

Ich nutze ffmpeg fürs grundsätzliche Encoden, für Animationsfilme nehme ich einen custom x265 build für animationen.
Software in dem Sinne, ffmpeg und ne batch datei, diese mit simplen loops, falls ich mehrere Dateien konvertiere.

Ich habe mir verschiedene Presets gebaut in der Batch, mit x265 parametern. Die sind irgendwo im Slow/very slow Bereich angesiedelt. (Siehe x265 presets table)
Im Detail sind dies kleine Unterschiede für Beispielsweise "körnigere" Filme, da ich das Archive File visuell unverändert möchte, wird nichts wie degrain und co gemacht, bloss sharpness und crf settings.

Bei Actionfilme etc lasse ich meistens die DTS-HD Spur intakt, bei Komödien etc wirds meistens AC3 mit 640k, was für mich völlig ausreichend ist.
Einzig Erwachsnenfilme wandle ich der Geschwindigkeitswillen mit hvec_nvenc um, hier mit preset slo und rc vbr_hq was bei der üblichen Sourcequalität absolut genügend ist.

Bisschen allgemeiner zum Thema, mir persönlich ist es egal, ob er mit 5, 20, oder 400fps konvertiert, x265 ist nicht auf Speed ausgelegt und ich lasse lieber gemütlich vor sich hinkonvertieren und bin dafür mit dem Ergebniss zufrieden. Dazu erstelle ich mir jeweils ein paar Screenshots von Source und Encode und wenn ich sie unterscheiden kann wird an den Settings geschraubt und nochmal encoded.
Was ich nicht mache sind bestehende x264 encodes konvertieren, Quellmaterial ist immer die unkomprimierte Disk. Resultat ist jeweils ein Encode durchschnittlich zwischen 4 und 6 GB.
Kurzum, vergiss Speedbenchmarks, Strom und co, wenn du "möglichst originale / beste Qualität" möchtest, konzentrier dich auf die Encoding Parameter und co. "Gut Ding will Weile haben".

Ich mag Tools wie Handbreak, Satxrip und wie sie alle heissen nicht wirklich, da du nie genau weisst wie das Tool konvertiert. Mache ich persönlich lieber via cli, dafür weiss ich genau was passiert und gemacht wird. Und falls mal ein Server mit genug potenter CPU im Haus ist werde ich das ganze mit "tdarr" automatisieren, dann brauche ich bloss das Sourcematerial in den richtigen Watchfolder schmeissen und den Rest überlasse ich dem Server.

Zitat von quorn23

Ich habe mir verschiedene Presets gebaut in der Batch, mit x265 parametern. Die sind irgendwo im Slow/very slow Bereich angesiedelt. (Siehe x265 presets table)
Im Detail sind dies kleine Unterschiede für Beispielsweise "körnigere" Filme, da ich das Archive File visuell unverändert möchte, wird nichts wie degrain und co gemacht, bloss sharpness und crf settings.

Wäre cool, wenn Du Deine Batch Presets mal zeigen/teilen könntest.

Auch gerade mal mit ffmpeg und x265 Parametern rumgebastelt, um alte DVD Sammlung auf Platte legen zu können. Gar nicht so einfach. SG 1 z.b., körnige Ansage 45 Minuten auf 1.7 GByte auf der DVD.

Da ist dann noch interlaced flag gesetzt, obwohl man sieht, das es nicht interlaced ist. Glücklicherweise war das ja mit Film Kamera gedreht, also auch keine Dummen 30fps -> 25 fps Konvertierungsprobleme, wie bei amerikanischen Serien die mit Fernsehkameras gedreht wurden. Halt bloss die 4% speedup aber da habe ich keinen Boch die rückgängig zu machen.

Also eigentlich bloss einen de-interlacer finden, weil wenn man das nicht rausnimmt, dann codiert x265 halt interlaced und das kostet dann immer unnötig platz. Hatte erst yadif probiert, aber bin dann bei mcdeint=0 gelandet, aber auch bloss weil er sich irgendwie in den Verkaufsprospekten besser angehört hat und glaube ich im vergleich ein paar % weniger bitrate am Ende brachte.

Dann x265 selbst, das ist halt gegenüber x265 vor allem deswegen nervig, weil immer ein auf anhieb gutes bild liefert, bis man dann merkt, dass es halt nur gut aussieht weil es details weglässt "matschig". Aka: keine klassischen mpeg Artefakte, sondern matsch-Artefakte.

Erstmal mit tune-grain rumgespielt, und das brauchte dann teilweise bei gleichem crf doppelt soviel bitrate wie ohne diesen tune. Interessant. Aber vor allem war das banding das Problem. Das habe ich nur mit 10bit Verarbeitung wegbekommen. Hört sich unlogisch an, wenn input und output nur 8 bit sind, aber es geht ja um die DCT matrixen-parameter und wenn die nur 8 bit sind und dann werden aus denen mit 8-bit berechnungen pixel berechnet, dann haben die pixel da halt keine vollen 8 bit pro Farbkanal mehr. Keine Ahnung, warum das Problem so nicht bei MPEG2 auftritt (Original).

Danach noch mal verglichen zwischen grain und non-grain, fand es dann aber sinnvoller, ohne grain den niedrigsten (besten) crf zu nehmen bei dem der Kompromiss zwischen bitrate und qualität mir passte.

ffmeg inputfile.mkv \
-vf mcdeint=0 \
-map 0:v -map 0:a -map 0:s \
-c:v libx265 -crf 20 -pix_fmt yuv420p10le \
-c:a:0 libfdk_aac -vbr 3 \
-c:a:1 libfdk_aac -vbr 3 \
-c:s copy \
outputfile.mkv

Aka: CRF 20, yuv420p10le ist 10 bit Verarbeitung. Die beiden Tonspuren (deutsch, englisch) sind gleich codiert also kriegen die auch denselben audio codec. kommt glaube ich auf 128 kbps fuer stereo raus, muss ich nochmal gucken. Und subtitle einfach alle kopieren.

Natürlich muss man script schreiben, der diese parameter in Abhängigkeit des Quellmaterials macht, bastele ich halt dran rum mit "mediainfo" output gucken, was da so drin steckt.

Da kommt jetzt ca. 390 MByte pro ca. 42 Minuten raus, ca. Faktor 4.7 komprimiert gegenüber dem Original. Eigentlich sagt man ja, das H264 faktor 2 gegenüber MPEG2 bringt, und H265 nochmal Faktor 2, das liegt also im Rahmen, evtl. ein wenig zu sehr auf Kante genäht. Ich sehe da schon noch Unterschiede, aber keine die mich stören. Eher so wenn man auf Standbild geht.

Mit Medium (default) Codierung Geschwindigkeit geht das auf ca 1.8 fach realtime speed auf auf Intel E3-1231, kriegt aber nicht alle Kerne voll ausgenutzt, wahrscheinlich weil das mcdeint nicht schnell genug laufen kann, also muss man dann auch noch jeweils zwei ffmpeg gleichzeitig laufen lassen, wenn man die CPU in die Sättigung treiben will (CPU hat 64 Grad C bei mir, heiss, aber noch kein throttle).

Varianz zwischen den Folgen ist wegen CRF interessant. Von 240MByte bis 460MByte. Die dunklen, rauschenden Folgen kosten eindeutig mehr bits.

Die DVD Subtitle sehen schon Käse aus, so pixelig wie die sind, habe aber bisher noch nicht versucht da eine passende toolchain für linux zu finden um das OCR zu machen. Naja, das kann man später immer noch machen, ohne wieder das video neu codieren zu müssen.

Mal gucken. Erstmal nervt es mich das meine relativ alte ffmpeg version auf den servern (oben) bei gleichen parametern kleinere dateien erzeugt als neues ffmpeg auf debian buster *sigh*. Muss ich auch erst mal vergleichen.

Und dann vaapi beschleunigung ausprobieren auf der intel GPU.

x264 scheint auch dauernd verbessert worden zu sein, kann also gut sein, dass die Unterscheidung schwer wird, siehe Absatz Tests:

https://de.wikipedia.org/wiki/High_Efficiency_Video_Coding

Zitat von te36

Da kommt jetzt ca. 390 MByte pro ca. 42 Minuten raus, ca. Faktor 4.7 komprimiert gegenüber dem Original. Eigentlich sagt man ja, das H264 faktor 2 gegenüber MPEG2 bringt, und H265 nochmal Faktor 2, das liegt also im Rahmen, evtl. ein wenig zu sehr auf Kante genäht.

Die Faktoren von 2 sind meines Erachtens etwas Markteting-lastig. Unabhängige wissenschaftliche Untersuchungen zeigen typischerweise kleinere Faktoren für die Einsparung bei gleicher Qualität, z.B. http://iphome.hhi.de/wiegand/assets…erformance.pdf: ca. 35% Einsparung H265 im Vgl. zu H264 und 70% im Vgl. zu MPEG2. Also eher Faktor 1,5 und 3 statt 2 und 4. Damit ist 4,7 wirklich "auf Kante genäht".

Ich hatte mir auch überlegt, manches umzukodieren. Bin aber dann für mich zum Schluss gekommen: lohnt nicht. Zusätzliche Komplexität kommt, wie von dir erwähnt, durch die Unterschiede in den Tonspuren. Lieber 2 neue Festplatten zusätzlich (inkl. Backup). Alternativ ersetze ich die ein oder andere archivierte Aufnahme mit aktueller Ausstrahlung auf DVB-T2.

Zitat von Mister XY

Das liegt wohl daran, dass sich im Laufe der Zeit diverse Parameter geändert haben. So wurde der aq-mode von 1 auf 2 gesetzt, was in manchen Filmen für eine größere Datei sorgt.

Hmm... seufz.. also mal den ewigen rotz der parameter vergleichen, den ffmpeg beim codierungsstart ausgibt und gucken ob man mit der neuen version dieselben parameter der alten version hinbekommt. Danke!

Irgendeine Erfahrung mit VAAPI ? Aka: hat man da irgendeine chance vergleichbare qualitaet in vergleichbarer bitrate hinzubekommen ? Bloss schneller ?! HEVC Main10 scheint meine i5-7500 ja zu unterstuetzen, aber gibts was equivalentes zu CRF ? habe ja keine Lust bei Szenen mit viel Bewegung/detail qualitaet zu verlieren oder bei anderen Szenen, bits zu verschwenden.

So wie ich das hoffe, koennte QVBR bei VAAPI aehnlich wie CRF funktionieren, aber Dr. Google bringt mir da keine guten Beispiele, und experimentieren dauert halt immer ewig (qualitaetsvergleich der resultate).

Meiner Erfahrung nach ist x265 verglichen mit x264 eine fürchterliche Ziege.

Mit x264 ist es nich relativ einfach für die meisten Filme ein beinahe identisches Reencoding hinzukriegen. Bei x265 ist es für mich ewiges Gebastel.

- x265 mag kein Grain. Sobald es im Bild gröber krisselt, wechsle ich sofort auf x264. Encodings mit Grain werden bei x265 deutlicher verwaschener... da kann man rumdrehen, wie man will... es hilft nichts.
Optisch wirkt es auf mich immer als würde x265 da drüberblurren und dann nochmal seinen eigenen Grain drübersprühen. x264 verhält sich nicht so.

- x265 mag kein Rot. Mir ist immer wieder aufgefallen, dass x265 extreme Probleme mit rötlichen Szenen hat. Hab mal Disney’s Aladdin kodiert... am Anfang fährt die Kamera über eine rötliche Wüste mit kleinen Kieseln in der Abenddämmerung.... die Kiesel fraß x265 einfach auf. Der Film bereitete dem Codec generell immense Probleme durch die viele rote Farbe: Rötliche Steinwände - matsch. Roter Turban: Artefakte... riesige Pixel.

Auch so Sachen wie The Cube sind sehr.... interessant zu codieren mit x265. Sobald die Charaktere einen roten Raum betreten hagelt’s plötzlich Artefakte.

Ich benutze Staxrip, das mit einem netten Bildvergleichs-Tool daherkommt... da fiel mir manchmal alles aus dem Gesicht.

Es brachte auch nicht viel, mit dem Chroma Parameter (crqpoffs) rumzuspielen... es wurde nur anders aber nicht wirklich besser. Erst auf 12bit Encodings mit hohem crqpoffs geht’s dann wieder mit den roten Artefakten... jedoch schlittert man dann in Kompatibilitätsprobleme rein.

Rötlich oder dunkelrötlich... ganz schlimm.

Ocean’s 13, das mit einem krassen Rotstich daherkommt, fällt mir auch noch ein... plötzlich ist die Struktur auf dem tollen roten Kleid der Dame weg... dafür gibt’s jede Menge Blöcke.

Ein weiteres Beispiel wären Amber Heards knallrote Haare in Aquaman.

Ergo benutze ich bei solchen Filmen entweder x264 oder passe über —zones die Bitrate in solchen Stellen an. Letzteres kann eeecht dauern und ist meganervig.

Zitat von hodj

Meiner Erfahrung nach ist x265 verglichen mit x264 eine fürchterliche Ziege

Sag mal, welche x265 version Du verwendest, und wenn du eine empfehlung fuer x264 parameter fuer altes DVD material haettest, die dann auch (CRF, etc. pp). Ich bin ja von einem uralt ffmpeg zum binary ffmpeg build gegangen, 4.2.2, also derzeit neueste version. Also mit neuestem x265 3.3-2. Und da waren ja wie berichtet alle Parametereffekte anders als bei der alten Version. Wenn Du nicht neueste version x264/x265 verwendest ist vergleich natuerlich schwer.

"Gutes" material habe ich noch nicht neu probiert zu codieren. Derzeit wie gesagt schaue ich mir halt SG1 an (passt gut, seit jahren nicht mehr gesehen), und denke mal, dass ich da mit den resultaten von 265 mit crf=22, 8-bit und tune=grain zufrieden bin. Ueber eine Season verteilt kommt Kompressionsfaktor 3 gegenueber der DVD heraus. Also nicht mehr Faktor 4.x womit ich angefangen hatte. Faktor 4 schaffe ich nicht mit tune=grain, da sieht man dann artefakte.

Hatte nur mal kurz mit x264 verglichen, aber das hat bei gleichem crf viel groessere Dateien gebracht. Hatte nur mal kurz eine Datei mit einer vergleichbaren groessen x264 datei vergleichen und bilde mir ein, dass ich da nicht nur uebes grain-rauschen sehe, sondern eben schon mpeg-artefakte.

Ds x256 grain normalerweise wegmacht ist fuer mich auch der Fall. Das x265 grain selbst erzeugt konnte ich bisher nicht sehen. Mal ein Beispiel, parameter , material ?

Zitat von te36

Also eigentlich bloss einen de-interlacer finden, weil wenn man das nicht rausnimmt, dann codiert x265 halt interlaced und das kostet dann immer unnötig platz. Hatte erst yadif probiert, aber bin dann bei mcdeint=0 gelandet, aber auch bloss weil er sich irgendwie in den Verkaufsprospekten besser angehört hat und glaube ich im vergleich ein paar % weniger bitrate am Ende brachte.

also wenn das Bild wirklich nicht interlaced ist, dann sollte es bei ffmpeg auch nicht nötig sein, ein interlacer filter drüber laufen zu lassen. Einfach ohne Filter laufen lassen. Da kommt dann auch progressiv raus, weil der Encoder darauf per Default eingestellt ist.

Bitrateänderungen können auch davon kommen, dass ein Deinterlace Filter über ein progressives Bild läuft und dort "optischen Schaden" anrichten und Details zerstört. Das spiegelt sich dann in niedrigerer Bitrate wieder. Ich würde einmal mit und einmal ohne deinterlace Filter laufen lassen und optisch vergleichen, ob ein Filter notwendig ist. Nicht das du dir durch den mcdeint das Bild zerstörst.