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

[Tenferenzu]

Also wirklich nur den Container ändern sonst nichts?

OT: Video und Audio -> Copy und dann den richtigen Container auswählen.

 

[nr-Thunder]

Wie stell ich ein , dass das die GPU macht? Meine 3080Ti sollte das können? Besser als der 13900KF?

Deine 3080 Ti kann nur decoden, heißt dass wenn Youtube irgendwann auf AV1 umstellt, du es zum ansehen verwenden kannst.

Encoden geht erst ab Lovelace, z.B. jetzt schon zum aufnehmen über OBS.

 

[Bigeagle]

Ich frag mich noch wofür ich das brauche. Früher mal, wo die Player noch nicht alles abspielen konnten.

Also manche Leute brauchen sowas um Videos zu encoden. ^^
Wofür du das brauchst ist schwer zu sagen.
Im Ernst, ob man nun Rohmaterial verkleinern will, transcoding für bestimmte Geräte oder uploads, oder DVDs archivieren bevor die an Kratzern, Oxidation oder Rissbildung kaputtgehen oder man einfach nur zu faul ist überall ein DVD Laufwerk und einen Stapel DVDs zum Serien gucken mitzuschleppen, da hilft ein passendes Tool. Hardwareencoder sind vor allem nice wenn es schnell gehen soll. AV1 encoded eher arg zäh auf CPU, vor allem wenn die nicht mehr ganz frisch ist.

Der prozessor wurde auf manchen Kernen recht heiß bis 92° mit aber nur wenigen % Auslastung. Unter CBR23 wird das auf den Kernen ähnlich heiß aber mit 100% Auslastung. Woran liegt das?

Das liegt daran dass Videoencoding 'echte arbeit' ist
Die hitze zeigt nur dass die CPU was zu tun hat. Die Auslastung entweder dass SMT (aka Hyperthreading) nicht viel bringt, oder die Arbeit nicht ausreichend parallelisierbar ist. Je nach Encoder und Material kann man da auf Kompression oder paralleles Encoding optimieren.

Wäre für einfache Aufgaben ein Test mit FFMPEG zielführender? Ich habe auch drn Eindruck, dass es da schneller geht mit Hardwareunterstützung.

Handbrake hat einen GUI, was bei Benchmarks die Arbeit nicht leichter macht.

einfache Aufgaben, oder Benchmarks? Aufgrund er GUI ist Handbrake meist einfacher für einfache (schnelle) Sachen. Außer man ist ohnehin fit mit ffmpeg. Benchmarks eher nicht so wenn man das automatisieren will.
Ein Vorteil ist auch dass Handbrake nur eine passende dll ins Verzeichnis geschoben bekommen muss um DVDs zu archivieren, das ist mit ffmpeg allein afaik nicht so einfach.

 

[Yosup]

Das mag sein, aber in puncto Effizienz/Geschwindigkeit ist es einfach komplett irre, die Filmsammlung über die CPU zu jagen.

Kann man so sehen, muss man aber nicht. Ich transkodiere das EINMAL, das erstellte File hebe ich DAUERHAFT auf. Was interessieren mich die 1h (auf einer CPU mit vielen Cores oft noch schneller, Handbrake skaliert hervorragend) im Hintergrund beim Surfen?

 

[Haldi]

Ist ja Wahnsinn wie gut das läuft.
Ich weiss noch die ersten AV1 encoder liefen auf CPU mit 1-5 FPS.
Nun hab ich avg 35 FPS.
Richtig Geile sache!

Grössenmässig auch ein vorteil gegenüber h264 oder h265.... nur die Frage mit der Qualität muss noch mal genauer untersucht werden.
Aber scheinbar nur bei hohen Qualitätsansprüchen.... wenn man von Q17 auf Q21 hoch geht sind die optimierten X264 settings noch im vorteil....

 

[0x8100]

nur die Frage mit der Qualität muss noch mal genauer untersucht werden.

hier ist ffmetrics zu empfehlen. psnr und ssim kannst du dir sparen, vmaf reicht. werte um 93-95 sind vollkommen ausreichend. noch höhere werte sind verschwendeter speicherplatz, das sieht man nicht mehr.

 

[aelo]

Meine paar Anmerkungen zum Thema. Habe letztens direkt mit svt-av1 herumgespielt da die installierte Handbrake-version noch kein AV1 unterstützte.
Als Beispiel ein aktueller UHD Film mit 10bit (HDR) und einer Länge von ca. 130min.

Das Enkodieren hat in Software mit Qualitätsparameter Q28 oder Q30 und dem eingeschaltetenen Grainfilter (Doku dazu hier: https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Ffmpeg.md) irgendwas zwischen 10 und 15 Stunden auf meinem Ryzen 7 3700x gebraucht.

Bei 1080p, 8bit (LDR) ging das ganze erheblich flotter, da war das ganze auch in Software gut einsetzbar um die eigenen Filme zu Archivieren.

Das Endergebnis ohne Tonspuren und Untertitel lag dann bei < 3GB ohne sichtbaren Qualitätsverlust. Wobei ich persönlich keinen Vergleich zu HEVC bieten kann, habe die letzten Jahre immer eher größere Files produziert da mir nicht bewusst war wie groß True-HD Tonspuren sind.... Inzwischen komprimiere ich diese auch mit Opus oder Vorbis.

Bzgl. des Einwandes einiger warum nur Hardwarebeschleunigung auf einer einzelnen API unterstützt wird:
Ich habe in der Vergangenheit sowohl GpGpu programmiert (OpenCL und Cuda) als auch mit Apis zur hardware-beschleunigten Hardware Enkodierung gearbeitet (vaapi, nvenc, v4l-Varianten, usw...). Diese hatten alle etwas gemein: Nur in den seltensten Fällen waren diese Apis Hersteller oder Betriebssystemübergreifend verfügbar. Stabil waren sie sowieso nur wenn man exakt die richtige Konfiguration wählte und dann auch noch sicherstellte dass jeweils die richtige (nicht umbedingt neueste) Treiberversion installiert war. Bei Videokompression ist zum Glück der Shadercompiler nicht relevant, von daher kann eine große Fehlerquelle ausgeschlossen werden. Ich verstehe also voll und ganz warum nicht alle Kombinationen von Hardware, Betriebssystem und Api unterstützt werden.

(P.s.: auch finde ich es etwas genugtuend wenn Nvenc nicht unterstützt wird. Bei den frechen Preisen die Nvidia kassiert müssen nicht umbedingt auch noch Open Source Entwickler kostenlos Features für Ihre Hardware zur Verfügung stellen.)

 

[Tenferenzu]

Der prozessor wurde auf manchen Kernen recht heiß bis 92° mit aber nur wenigen % Auslastung.

Verwendet Handbrake alle Kerne mit AV1? Bei FFMPEG musste ich das damals immer als Parameter mitgeben wie viele Kerne/Kacheln verwendet werden sollen.

Ist ja Wahnsinn wie gut das läuft.

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.

ffmpeg.exe -i 2Min_Testfile.mkv -c:v libaom-av1 -crf 50 -row-mt 1 -tiles 2x4 -b:v 2000k -cpu-used 8 2Min_Testfile-AV1-Software-CRF50-cpu-used-5.webm

 

[Fusionator]

Ist ja Wahnsinn wie gut das läuft.

Kannst du mal was in UHD probieren? Preset Fast und Slow? Am besten "richtiges" Filmmaterial
Ich meine mich zu erinnern, dass da die Frameraten ein Witz waren.
Leider habe ich keine "brauchbare" CPU hier um sowas vernünftig zu testen.

Ich habe in der Vergangenheit sowohl GpGpu programmiert (OpenCL und Cuda)

Ich wollte hier schon die leichte Offtopic Frage stellen, warum x.264/x.264 nicht auf CUDA implementiert wurde.
Sollte damit sowas nicht um längen schneller laufen?

 

[Bigeagle]

@Haldi omfg ich bin so neidisch. Ich habe dieses Jahr einiges archiviert und das nach etwas hin und her in h.265 'slower' mit crf 22.5 über die CPU geschickt. Mein i5 3570K hat da eher um die 3 fps gemacht bei DVD auflösung. AV1 hab ich probiert, aber bei nicht mal 0,5 fps schon im eher anspruchslosen Intro war das keine option.
Ein Ryzen 2600 war auch 'nur' knapp doppelt so schnell.
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.
Wobei 17 vermutlich niedrig genug ist für nahezu alles. Ich muss da etwas mehr geizen.

 

[Katzenjoghurt]

AV1 (intel) ist am besten in allem. beste qualität, beste qualität pro größe. h264 ist am schlechtesten. h265 ist son mittelding, aber h264 und h265 sind näher zusammen als h265 und av1. h265 ist keine wirkliche alternative, da lizenzpflichtig - hw support ist nicht wirklich flächendeckend gegeben. AV1 ist hier richtiges "next gen" und ein gamechanger.

habe neulich in davinci resolve das erste mal über meine A770 in AV1 exportiert und in h264 und h265 brauchst da einfach nicht mehr exportieren - schnee von gestern.

Hm. Mein Urteil würde anders aussehen.
Für mich kam es immer sehr aufs Quellmaterial an, ob ich nun h264 oder h265 (bzw. x264 oder x265) nehme.
Grain und Rottöne verwandelte x265 einfach zu Matsche - außer man pumpt unverhältnismäßig mehr Bitrate als bei x264 rein bzw. encodet mit 4:4:4 Chroma Subsampling - was dann wieder viele Player nicht mögen.
Kompromiss: Wenn’s nur wenige Szenen mit rotem Licht oder roter Umgebung sind, hab ich da selektiv die Bitraten hochgedreht bei h265.

Zumindest bei FullHD ist es oft schwer zu entscheiden, was nun besser ist.
Bei glasklarem 4K kann x265 aber x264 oft vernichten.

AV1 hab ich in Software aus naheliegenden Gründen noch nicht encodet - was ich gelesen habe, hat man dort aber im Prinzip wohl dasselbe ”Problem” wie schon mit h265.
Auf niedrigen Bitraten triumphieren h265/AV1… aber wenn man wirklich hohe Qualität will, fallen die Unterschiede in der gesparten Bitrate weniger dolle aus, als man es sich erhoffte.

Hardware-Encoding ist eh raus, wenn man Qualität will.

Ich bin da gar nicht so gehypet, was AV1 angeht.
Für Streaming-Anbieter ist das toll - selbst bei niedrigen Bitraten kriegt man noch ein anständiges Bild.
Und all zu großzügig in der Bitrate waren Netflix und Co. in der Vergangenheit eh nicht, was ihre h264 Streams angeht, so dass auch für Zuschauer mit AV1 ein Qualitätsgewinn drin sein dürfte.

Dass man bei einem nahe-perfekten FullHD Blu-Ray Rip mit AV1 tatsächlich mehrheitlich mit einer Platzersparnis gegenüber dem Duo x264 und x265 rechnen kann, bezweifel ich aber.

 

[aelo]

Ich wollte hier schon die leichte Offtopic Frage stellen, warum x.264/x.264 nicht auf CUDA implementiert wurde.
Sollte damit sowas nicht um längen schneller laufen?

GpGpu eigenet sich sehr gut für Probleme die sich hochgradig paralellisieren lassen. Da rede ich jetzt auch nicht von sowas wie 16-32 Threads, sondern je nach Problemstellung mind. von Tausenden. Die ganzen Compute-Units der GPU müssen mit Instruktionen gefüttert werden. Der Vorteil dieser liegt nämlich darin dass sie in Vergleich zu einer generellen CPU extrem einfach sind, aber dafür gibts eben viele. Das merkt man beispielsweise wenn die eigenen Shader Branches (Sprünge) enthalten, da bricht bspw. die Performance sofort stark ein. D.h. Algorithmen wie Sortieren sind als ein Beispiel eher schlechter auf einer GPU umzusetzen.

Bei Videokompression ist es so dass gewisse Teile durchaus von einer GPU profitieren könnten, andere wiederum nicht. Um den Bitstream zu dekodieren/enkodieren braucht es einen ASIC da das größtenteils seriell ablaufen muss (oder eben Software auf der CPU). Transformationen DCT/FFT/Wavelets usw... könnten schon eher mit Shadern prozessiert werden. Motion-Vector-Estimation wäre etwas das ich persönlich zumindest beim Encoder entwickeln ausprobieren würde, aber garantieren dass es viel schneller wäre könnte ich nicht.

Zusammenfassend brauchts um eine gute Beschleunigung durch Hardware zu erreichen meiner Meinung nach spezifische ASICs, da sich Cuda & Co für viele Teilaspekte der Videokomprimierung nicht eigenen.

Falls Machine Learning in Zukunft mehr verwendet wird für bspw. Motion Vector Estimation oder Rate Control Ansätze könnte für diesen Teilaspekt dann natürlich die Tensor-Units oder Cuda/OpenCL verwendet werden.

 

[HITCHER_I]

Nunja, wenn man nur mit Preset 6 und 1-pass konvertiert, wird die Qualität und Effizienz nicht optimal sein, aber ziemlich flott, vielleicht sogar Kodierzeit = 2x Spielzeit.

Mein 3900x hat aber nur 16,3 FPS geschafft.
Mit Film Grain Parameter von: https://www.computerbase.de/forum/t...auf-cpus-und-intel-gpus.2122184/post-27699804

Das Ausgangsmaterial war 30 MBit h264 1920x1200 x 60FPS, jetzt hat es 7.

 

[PiraniaXL]

Ich werde bis auf weiteres noch bei h264 bleiben.
Zum Einen können es viele Standalone-Geräte abspielen, zum Anderen spielt Speicherplatz heut zu Tage kaum eine Rolle.

Weiterentwicklung schön und gut, aber es muss denn auch "Abnehmer" dafür geben.

Hab damals mal mit der Grafikkarte encodet, da kam nur Grütze raus(vermutlich falsche Einstellungen).
Ich bleibe auch beim CPU-Encoden, denke mal die Meisten haben heut zu Tage ein 6-Kerner oder Größer zu Hause.

 

[SJAFNWEIF]

auch finde ich es etwas genugtuend wenn Nvenc nicht unterstützt wird

Ich gehe mal davon aus, das wird früher oder später noch kommen. Die Hardware von Intel ist halt auch schon einige Monate länger auf dem Markt.

Verwendet Handbrake alle Kerne mit AV1?

Kommt drauf an, wie viele Kerne du hast, unbegrenzt skaliert nämlich kein Encoder. Und dann hängt das auch noch von der Auflösung des Quellmaterials und den Einstellungen (bspw. Preset) ab.

Kachelanzahl

Die hat auch einen Einfluss auf die Effizienz, deshalb ist es wohl eher wenig empfehlenswert, da das Maximum auszureizen. Wenn es um Skalierung geht, kommt man früher oder später nicht um ein Programm wie Av1an herum, das das Quellmaterial in viele "Portionen" aufteilt, die dann parallel kodiert werden können.

Edit:

Auf niedrigen Bitraten triumphieren h265/AV1… aber wenn man wirklich hohe Qualität will, fallen die Unterschiede in der gesparten Bitrate weniger dolle aus, als man es sich erhoffte.

Das liegt teilweise auch daran, das die Encoder nicht unbedingt darauf optimiert werden. rav1e scheint in dieser Hinsicht wohl vielversprechender zu sein als SVT-AV1 und Libaom. Generell hat Film-Grain-Synthese durchaus einiges an Potential, um entsprechendes Quellmaterial bei gleicher Qualität weitaus platzsparender zu kodieren, als es aktuell mit x264/x265 möglich ist. Dazu muss das aber natürlich gut implementiert werden.

 

[Tenferenzu]

Ich werde bis auf weiteres noch bei h264 bleiben.

Nur kein Stress. Das wird sowieso noch einige Jahre dauern bis es sich wirklich durchgesetzt hat.

Wir haben jetzt gerade mal die meisten (neuen) Abspielgeräte abgedeckt damit.
Jetzt gerade wird an der Erstellung neuen Materials gearbeitet (Encoder). Bis die wirklich überall drinnen sind und entsprechend funktionieren dauert es sicher nochmal 2 Jahre.

Danach wird es aber interessant. x264 wird uns garantiert noch einige Zeit erhalten bleiben weil das halt jeder Toaster abspielen kann aber ich kann mir gut vorstellen, dass x265 ziemlich schnell verschwinden wird (außer bei BluRays).

 

[DFFVB]

will ich sehen.

Freut mich, ich will auch viel… ich freue mich erstmal, dass es überhaupt einen Anbieter gibt n0tenoughav1 war mir zu instabil….

 

[GM206]

Da ich eh nur 1080p Material habe bleib ich bei 264, nebenbei macht da selbst ein Celeron via IGP einen i5 via CPU nass.

 

[Angel Of Death]

Grain und Rottöne verwandelte x265 einfach zu Matsche [...]

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.

 

[Boerkel]

Danke für die Tipps auf Seite 1 und 2. ;⁠-⁠)

Wie sieht das eigentlich mit der Dateigröße beim AV1-Encoding auf der GPU im Vergleich zur CPU aus?
Je größer die Bibliothek desto wichtiger wird das ja....