News HandBrake 1.6.0: Unterstützung von AV1-Encoding auf CPUs und Intel-GPUs

[Haldi]

Braucht es einen Parameter um alle Kerne zu verwenden oder macht das Handbrake automatisch? Vor knapp 1,5 Jahren musste man nämlich noch die Kachelanzahl spezifizieren welche der Thread/Kernzahl entsprechen konnte um die Kerne alle auszulasten.

Ist Standard.
Ich glaub mit x265 habe sie multithreading soweit verbesser das es problemlos auf 12-16 kernen läuft.
Hatte damals einen i7-3930k einer der ersten 6 Kerner. War schon cool zum encoden
Hatte sogar ne weile nen HP Proliant Gen6 mit 2x 6kernen aber gerade bei MultiSockel war das noch viel viel schlimmer damals. ging alles nur über Paralellisieren, mehrere Streams gleichzeitig.

Kannst du mal was in UHD probieren? Preset Fast und Slow? Am besten "richtiges" Filmmaterial

Nö.... na gut.... okay mal kurz anwerfen und sehen was passiert...
Avg 28FPS im Fast 4k AV1 Preset. und ca 9gb RAM verbrauch.

@Haldi omfg ich bin so neidisch.
Allerdings stolpere ich ein bisschen über deinen Screenshot. Die quality settings waren bei 264 zu 265 eher nicht 1:1 übertragbar, das dürfte bei AV1 genauso sein. CRF ist afaik immer relativ zum Codec und auch nicht stabil bei unterschiedlichen Einstellungen. Ich ermittle meinen Zielwert immer in einem schnellen Preset und manueller Prüfung von ein, zwei Testszenen und hoffe entweder dass die quali beim finalen preset etwas besser ist, oder ziehe noch 0,5-1 ab für den Fall dass meine Testszene schwach war.

Hab mir damals den 3900X nur gekauft weil ich neben dem zocken früher auch noch ordentlich viel Videos konvertiert habe. Darum auch beim welchsel auf nächste Gen den 5900X geholt und nicht den 5800.
Das mit der Qualität hast du durchaus recht.
Aber das waren auch nur einige kurze Tests... gibt da noch mehr, ältere.

Spoiler: Screenshots

Da ich damals als uploader für ne Streaming Platform tätig war, war das Ziel natürlich möglichst kleine Dateigrösse zu erreichen bei guter Bildqualität.
So Schund wie Youtube oder Vimeo hatten Hardware encoder oder Software mit absolut hässlichen Presets.
Also alles was man hochgeladen hat dass dann nochmal konvertiert wurde hat immer zutiefst hässlich ausgesehen.
Glücklicherweise gabs 2-3 Platformen wie wenn man korrekte mp4 hochgeladen hat kein weiteres konvertieren mehr gemach haben. Somit war das Ziel immer möglichs nahe an der Source (BD kein Cruchyroll müll) zu sein bei möglichst kleiner Dateigrösse. Natürlich in 1080p.
Solange das auf den ersten blick nicht visuel ersichtlich war, war die qualität gut genug. Dann gings natürlich nur noch darum so schnell wie möglich vorwärts zu kommen.

Dauert schliesslich eine weile bis man mit allem dem durch ist....

Natürlich nur das gute Zeugs




Haja... good old times...

 

[HITCHER_I]

@Haldi
Was für eine CPU Temperatur hattest denn bei dem Test erreicht?

 

[Haldi]

bei 34°C Wasser Temperatur ca 65-70°C
Aber wie du vielleicht siehts hab ich nen EDC Limit von 170A was rund 190W TDP ausmacht.
Rund 4.5-4.6ghz allcore turbo.

 

[Tenferenzu]

Aber das waren auch nur einige kurze Tests... gibt da noch mehr, ältere.

Ein paar ältere Tests könnte ich hier auch noch beisteuern. Alles encodiert auf einem 3500u mit 4 Kernen / 8 Threads und 35W außer es steht M1 davor..

 

[HITCHER_I]

Das ist ja hervorragend, bei der Auslastung und 190W nur 70°C.
Wenn man eine normale LuftKühlung hat, kommt man damit sicher schon auf 90°C.

Edit:
Im Screenshot vom HW steht 75°C.

Mein 3900x hatte mit Standard TDP (142W max) und Boxed Kühler (100% HI) an der 80°C Marke gekratzt, war aber nicht drüber, bei stellenweise auch 100% Auslastung.

Edit:
Das muss ich nochmal kontrollieren, ich glaube, ich habe im BIOS 80°C max.Temp eingestellt, sicherheitshalber.
Edit:
War aktuell nicht aktiv, Begrenzung war Standard bei 95°C, aber hatte es zuvor mal aktiv, wegen dem Boxed Kühler Wraith Prism.

 

[crackett]

Schöne Entwicklung, sind aber noch ein paar Jahre, bis das in der Fläche ankommt...

Das mag sein, aber in puncto Effizienz/Geschwindigkeit ist es einfach komplett irre, die Filmsammlung über die CPU zu jagen.
Auch wenn die erzielbare Qualität bei gleicher Dateigröße etwas besser ist, ist es das imho nicht wert

Nein, die Dateigrößen machen bei gleicher Qualität einen gewaltigen Unterschied. Um die 25%, wenn ich mich recht erinnere. Erst recht, wenn man an die unteren Grenzen des machbaren geht, also so um Konstante Qualität 22 rum.
Viele übertreiben es auch schlicht und einfach mit den Qualitätseinstellungen und pumpen den Kram zu völlig sinnfreien Dateigrößen auf, um sich das dann auf einem TV für "250€" anzusehen.... 😁

 

[Calid]

Das geilste AV1 bringt leider im web NIX weil es APPLE auf ihren verf***** devices nicht unterstützt. H264 ist da leider noch immer das kompatibelste. (H265 ist noch schlechter als AV1).

echt ultra sch****, dass Apple das verhindert.

 

[0x8100]

Erst recht, wenn man an die unteren Grenzen des machbaren geht, also so um Konstante Qualität 22 rum.

crf 22 bei svtav1 ist vollkommen ausreichend. während x265 werte von 0-51 kennt, gibt es hier 1-63.

 

[_anonymous0815_]

Ich gebe als Plexer auch mal meinen Senf dazu:

Für meine Endgeräte spielt AV1 leider noch lange keine Rolle. Für mich ist h.265 der Sweetspot zwischen Quality und Size. 18RF FHD/ Slow, 20RF 10 Bit UHD/ Slow.

Ein Geheimtipp für Grainentfernung ist Staxrip als Encoding-Tool mit dem Denoiser Temporal-Degrain 2 (läuft nicht auf jedem System und nutzt nur einen CPU-Kern, extrem langsam aber ein perfektes Ergebnis)

Eine andere Alternative wäre Topaz Video AI, liefert z.B. mit Artemis sehr gute Denoising-Ergebnisse. Ich mache es dann immer so, dass ich einen Film mit dem Apple High-Res-Encoder in eine .mov umwandle (faktisch kein Qualitätsverlust) und komprimiere dann mit h.265 in Handbrake. Mittlerweile kann man per CLI auf Topaz und ffmpeg zurückgreifen, aber das habe ich noch nicht ausprobiert.

 

[Epistolarius]

AMD kann's noch nicht

Wie auch im Artikel beschrieben unterstützt RDNA3 AV1 encoding, also keine Ahnung was du damit meinst.

 

[crackett]

Für meine Endgeräte spielt AV1 leider noch lange keine Rolle.

Das wird wohl auf die meisten zutreffen.

für mich ist h.265 der Sweetspot zwischen Quality und Size.

Dem ist nichts hinzuzufügen....

18RF FHD/ Slow, 20RF 10 Bit UHD/ Slow

So hoch greife ich gar nicht und die Sache mit Slow solltest Du noch mal austesten. Bringt qualitativ wenig bis nichts und bläht die Datei glaube sogar noch auf. Medium ist wohl die allgemeine Empfehlung und das hat sich bei meiner Testerei auch als zutreffend herausgestellt. Gibt da einen sehr aussagekräftigen Test im Netz - finde ihn aber gerade nicht.
Letzten Endes muß aber jeder für sich den Sweetspot aus Quali, Dateigröße und Speed finden.

 

[0x8100]

Ein Geheimtipp für Grainentfernung ist Staxrip als Encoding-Tool mit dem Denoiser Temporal-Degrain 2 (läuft nicht auf jedem System und nutzt nur einen CPU-Kern, extrem langsam aber ein perfektes Ergebnis)

svtav1 hat einen denoiser bereits eingebaut, mit film-grain=16:film-grain-denoise=1 lässt er sich aktivieren. sehr effektiv, lässt sich aber leider nicht feinjustieren.

 

[Chaosbreed]

Cooles Tool und schön, dass jetzt AV1 (einfacher) unterstützt wird. Leider meckert da mein Fire TV Stick noch zu sehr. Aber h.265 reicht erst mal. Ein paar Prozent mehr Qualität oder eben weniger Speicherplatz machen sich dann in der Summe schon bemerkbar.

Wo wir schon beim Thema sind: Hatte letztens ne DVD bekommen, die aus einer alten VHS-Kassette (schnöde Urlaubsvideos) überspielt wurden. Die VOBs wollte ich schön komprimieren, aber am Ende waren die Dateien größer als das Original. Jemand ne Idee, was schief gelaufen ist?

Brauchst glaube mindensten den 4k max oder den cube. Ich werde das aber auch gleich mal probieren. Jetzt wird die CPU auch wenigsten mal komplett ausgelastet. Bei Staxrip waren es meisten nur zwei Threads jetzt sind alle 12 gut ausgelastet.

 

[Luxamman]

Bin gespannt ob sich das mit den verschiedenen Hardware-Renderen mit Vulkan Video (V1.0 vom 19.12) irgendwann erledigt, damit einfach alle wichtigen Codecs auf Hardware laufen, ohne dass immer alles dreimal angepasst werden muss an die Hersteller... vor allem wenns die nicht interessiert.
Encoding wird gerade aktiv bearbeitet und ist für viele Szenarios sicherlich mehr als ausreichend

 

[sloven]

Frage mich, was es wieder für geldtechnische Gründe hat, dass hier nur Intel wieder bevorzugt wird und NV und AMD außenvor gelassen werden.

Vermutlich hat Intel die Schnittstellen schon deutlich vorher an die Produzenten von Handbrake weitergereicht hat und vermutlich auch einen Teil der Implementierung durch eigene Mitarbeiter übernommen hat.
Sowas machen AMD und Intel eher bei ausgewählten Spieleproduzenten, aber scheinbar nicht beim Hersteller von Handbrake.

 

[aelo]

Bin gespannt ob sich das mit den verschiedenen Hardware-Renderen mit Vulkan Video (V1.0 vom 19.12) irgendwann erledigt, damit einfach alle wichtigen Codecs auf Hardware laufen, ohne dass immer alles dreimal angepasst werden muss an die Hersteller... vor allem wenns die nicht interessiert.
Encoding wird gerade aktiv bearbeitet und ist für viele Szenarios sicherlich mehr als ausreichend

Bin da sehr pesimistisch. vaapi, vdpau, nvenc, libmfx, stateless v4l und dxva2 haben das auch versucht. Zugegebenerweise waren diese Apis meistens nicht OS unabhängig aber sehr wohl oft Hersteller-übergreifend. Dxva2 ist meines Wissensstands nur für Dekodierung unter Windows, Vdpau ist quasi tot(?) und v4l ist bei ARM-Chips verbreitet mit qualitativ unterschiedlichen Ergebnissen. Auf dem Desktop-Linux ist Vaapi halbwegs gut nutzbar wenn man Nvidia ignoriert.

Ergänzung (29. Dezember 2022)

Vermutlich hat Intel die Schnittstellen schon deutlich vorher an die Produzenten von Handbrake weitergereicht hat und vermutlich auch einen Teil der Implementierung durch eigene Mitarbeiter übernommen hat.
Sowas machen AMD und Intel eher bei ausgewählten Spieleproduzenten, aber scheinbar nicht beim Hersteller von Handbrake.

Nein da geht es einfach nur darum dass Intel frühzeitig Patches für ffmpeg bereitstellt welche die Funktionalität basierend auf ihren eigenem libmfx integrierten.

Handbrake verwendet ffmpeg und ist auf deren Features angewiesen.

 

[Katzenjoghurt]

Das stimmt doch nicht. Bei Preset "slow" und mit deaktiviertem SAO ist man damit ungefährt auf dem selben Level wie mit x264, auch mit 8bit. Kannst halt kaum was an Größe einsparen, hast allerdings den Geschwindigkeitsnachteil. Daher bleiben viele bei x264.

Rottöne, besonders rotes Licht oder auch sowas wie Nightvision sind bei x264 ebenfalls ein Problem. Diese Szenen sehen selbst bei einem CRF17-Encode nicht transparent aus. Da kann man aber gut mit Zones arbeiten und diesem Framebereich nochmal gut 3-4 Werte beim CRF niedriger setzen.

Meine Erfahrungen sind so.
Grain entfernt x265 eh erst mal komplett, wenn ich das richtig von doom9 erinnere, und erzeugt dann ein neues Rauschen, das vermeintlich ähnlich aussieht. Deckt sich auch mit meinen Beobachtungen im direkten Vergleich - der Grain ist komplett anders und praktisch immer matschiger als vorher.
Mit x264 und genug Bitrate kann man i.d.R. näher am Original-Grain bleiben als bei gleicher Bitrate mit x265.
Bei rauschigen Videos nehm ich daher in 95% der Fälle x264 und bleib bei niedrigerer Bitrate näher am Original.
SAO hab ich eh aus.

Dass das Problem mit Rottönen bei x264 nicht weg ist, stimmt… dunkle Szenen mit roten Lichtern machen auch da bei niedriger Bitrate schon mal Probleme und man fängt sich riesige Kompressionsartefakte ein. x265 ist in der Hinsicht nur nochmal viel empfindlicher. Rote Haare oder ein Details in einem roten Kleid kann ich da nur retten, indem ich da in Zones dann weit über h264/AVC Niveau gehe.

Generell erleb ich mit x264 deutlich weniger unschöne Überraschungen nach dem Encoden.
Bei x265 finde ich beim Drüberskippen im Anschluss sehr viel öfter irgendwelche einzelnen Szenen, mit denen ich unzufrieden bin, weil unerwarteter Detailschwund oder Artefakte.

 

[mkl1]

Nein da geht es einfach nur darum dass Intel frühzeitig Patches für ffmpeg bereitstellt welche die Funktionalität basierend auf ihren eigenem libmfx integrierten.

Handbrake verwendet ffmpeg und ist auf deren Features angewiesen.

Der Unterschied ist, dass Intel die Patches für Handbrake bereitstellt und testet. Einfach ffmpeg nehmen und fertig geht auch nicht, sonst wäre der Nvidia support ein leichtes, ffmpeg unterstützt Nvidia AV1 seit geraumer Zeit. Theoretisch könnte das Nvidia auch machen, wenn sie sich bei Handbrake einbringen. Oder jemand anderes, aber das dauert eben.

 

[GM206]

Ja der Unterschied ist das selbst ein Celeron Hardwired x265 kann, ohne merkliche Qualitätseinbußen.
Daneben brauchen die CPU Render Freaks eben einen 3950 um eine 15w HD 610 zu schlagen.

Celeron G5900 mit IGP:
mkv to h265 = 31,35 min

Ryzen 3700 mit CPU:
mkv to h265 43,25 min


Qualitätsunterschied 0, keiner kann was auf 1080p erkennen.

 

[eastcoast_pete]

Da wird Intel doch noch einen Teil der Arc-GPUs loswerden.

Die Kombination große NVIDIA oder AMD dGPU (zum eigentlichen Spielen) mit Intel ARC 310 im selben System ist ja schon vorgeschlagen worden, um damit Spiele live in AV1 streamen zu können. Die 310 ist als GPU wirklich nicht überzeugend, hat aber den ASIC für AV1 Enkodiererung mit bei, und kann das wohl recht gut und auch schnell genug. Und damit kann Intel uU tatsächlich ARCs loswerden, wenn auch nur den Billigheimer unter ihren dGPUs.

Ergänzung (30. Dezember 2022)

Das fänd ich auch super interessant. Handbrake Codec Vergleich: Welches Preset/welche Settings ist am Schönsten pro MB?

Wo/was bei mir AV1 abspielen könnte wüßte ich spontan auch nicht.

AV1 ist/wird v.a. für Live Streamen und Streaming allgemein interessant. HEVC ist eben so mit IP Problemen behaftet, daß Google & Co. damit nichts zu tun haben wollen.