News AV1-Nachfolger: Der AV2-Codec soll noch bis Ende 2025 fertiggestellt werden

Haldi schrieb:
Das hatten wir bereits...
Av1 entfernt das rauschen und setzt ein software rauschfilter über das neue video der dem alten so gut wie möglich gleicht.
Was aber auch nur bestätigt, dass die Softwareentwickler keinen Weg sehen, das Signal mit dem Rauschen effizienter zu enkodieren, wenn man sich den Aufwand macht, es vor dem kodieren zu entfernen, und nach dem kodieren wieder künstlich zu erzeugen. Das Feature ist ja in erster Linie für Filmkorn gedacht.

Das Problem ist, dass es bisher keine perfekte Rauschfilterung gibt, jeder Rauschfilter hat Nebeneffekte. Rauschiges Low-Light-Material von der Gopro ist dann aber besser während des Videoschnitts entrauscht, und nicht erst beim Enkodieren. Das Rauschen will ich ja schlussendlich auch nicht in der Aufnahme sehen.
 
  • Gefällt mir
Reaktionen: Penman und 12nebur27
HageBen schrieb:
Die Kamera Bewegung ist allerdings auch mindestens 10x langsamer.

In deinem Video ist im oberen Teil des Bildes in der Entfernung relativ zur Kamera auch kaum Bewegung. Und trotzdem nur Matsch.
 
ruthi91 schrieb:
Letztens ein Notebook frischgemacht mit Broadwell i7-5600U und das hat bei 1080p youtube deutlich gestottert. Pfiff aus dem letzten Loch. Erst auf 720p liefs flüssig und mit mittelmäßiger Auslastung.
Aber okay, keine Hardwareunterstützung, keine größere Iris iGPU und 2C4T.
Gibt ein Plugin mit dem Du h264 erzwingen kannst.

https://github.com/erkserkserks/h264ify
 
  • Gefällt mir
Reaktionen: Persi82 und ruthi91
Weiterentwicklung macht Sinn. Aber die Änderung und Inkompatibilität muss sich rechtfertigen.

Wenn wir erst 2030 breite Hardwareverfügbarkeit haben und etwa 2035 Hardwaredurchdringung - so dass sich der Einsatz lohnt. Ist das ein langer zeitlicher Horizont.

Mein ThinkPad X220 aus 2011 kann H264. Das ist Stand der Technik? Das kann man relativ sicher verwenden. Und positiver Weise läuft damit alles. So soll das auch sein. Ich will keinen Hardwareinkompatibilität.

PS: Wäre sinnvoll wenn APIs sowohl Software- und Hardwarefähigkeit getrennt signalisieren. Hat doch keinen Sinn AV1 an ein System zu liefern, dass keine ~ RDNA2 (erst ab 2022). Batterie bedankt sich nicht.
 
  • Gefällt mir
Reaktionen: gruuli
flaphoschi schrieb:
Weiterentwicklung macht Sinn. Aber die Änderung und Inkompatibilität muss sich rechtfertigen.
Es gibt immer Software Decode und nein, das ist auch kein Energie Monster. Es wird aber dennoch ewig brauchen bis es eingesetzt wird. Nur weil der Standard auf dem Papier fertig ist heißt es nicht, dass alles fertig ist. Das ist dann der Zeitpunkt wo es bei den Software (und später Hardware) Encodern erst wirklich los geht. Es wird also sowieso ein paar Jahre brauchen bevor eine ordentliche Nutzung auf der Encoding Seite fertig ist. Decoding ist da das deutlich geringere Problem.
 
  • Gefällt mir
Reaktionen: maxrl
Das ist sehr interessant und dann wieder nicht, weil es erst in Jahren flächendeckend eingesetzt wird (?).
 
KlaasKersting schrieb:
Allgemein im Web hat man oft VP9 oder noch immer H.264.
Man schließt halt auch eine breite Hardware Basis aus, wenn man auf AV1 only gehen würde.
 
  • Gefällt mir
Reaktionen: onetwoxx
DeusoftheWired schrieb:
Etwas einmal Enkodiertes noch mal neu zu enkodieren, bringt immer Qualitätsverlust, egal welcher Codec. Wenn du das Original noch auf Blu-ray hast, solltest du neu davon in AV1 bzw. später in AV2 enkodieren.
Ich gehe davon aus, Dir ist schon klar, dass jede digitale Information codiert ist und die BluRay bereits (mindestens) einmal komprimiert ist, oder?

Natürlich ist der Rat, besser von BluRay ausgehend neu zu komprimieren, als das abgeleitete h264 zu verwenden, völlig richtig, aber es liest sich, als wäre die BR nicht komprimiert bzw. sogar nicht encodiert.

@Krik
Wenn dir die Qualität des h264 reicht, dann kann ein recodieren die Dateigröße entsprechend verkleinern. Es kann aber nicht zwischen Kompressionsartefakten von h264 und Originalbild unterschieden werden, daher kann das Bild nicht besser werden (OK, außer man arbeitet mit komplexen Interpolationen o.ä., aber da ist es wirklich sinnvoller, von der bestmöglichen Quelle zu starten. )

Der Grundsatz stimmt: Verlorene Bildinformationen kommen durch umcodieren nicht zurück und es werden weitere Informationen weggelassen und es kommen weitere Kompressionartefakte hinzu.
 
Askat86 schrieb:
Ich habe letztes Jahr alles auf meinem jellyfin Server mit Tdarr automatisch zu AV1 kodieren lassen. Der Qualitätsverlust ist in 9 von 10 Fällen auch im Standbild nicht sichtbar.
Vor der Umwandlung waren meine Platten fast voll (ca 80%) und danach bei ca 30% Belegung. Man spart schon enorm viel Platz und ich wette, dass die meisten die Unterschiede nicht sehen können.
Welches Plugin hast du dafür verwendet?
 
Looniversity schrieb:
matschiger als ein Schweinestall ohne Schlitzböden und hat überhaupt gar nichts mit "FHD"
Link mit Timestamp
Jo 360° Video mit viel Bewegung auf 1,9 Mbit/s runter codiert ist einfach krass. Die H264 Version hat 2,7 Mbits. Ich habe mal unten auch was ähnlich Anspruchsvolles dran gehangen. Da macht auch Av1 komplett die Grätsche. So ab 15-20 Mbit/s siehts dann langsam gut aus.

Mimir schrieb:
Schau dir gerne mal dieses Video in 1080p an. Sieht 10x besser aus als dein Video.
Das Video ist auch mit deutlich höherer Bitrate codiert. Wir haben hier 13 Mbit/s in 1440p60 in AV-1 und 7 Mbit/s in 1080p. Unter Berücksichtigung der Framerate haben wir 2x so viel bits pro Pixel. Dazu ist das Video deutlich anspruchsloser und besser aufgenommen. Wenn die Kamera 4K mit 100 Mbit/s auf nimmt und die vom oberen Video 2 4K Streams in 50Mbit/s runter komprimiert, dann sieht von Vorne rein schlimm aus. Ist ja ne 360° Kamera, die eigentlich 2 4K Videos nebeneinander auf nimmt.

Ich bleibe bei mein H264. Ich kann das überall abspielen und sieht trotzdem recht gut aus. Manche, lange Videos codiere ich doch mal auf AV1 runter, aber die wichtigen Videos, wie Urlaubsvideos definitiv in H264.

Der beste Codec nützt Nichts, wenn man das Video nicht abspielen kann.
 

Anhänge

  • Herbsttour 2000k av1.mp4
    3,1 MB
  • Herbsttour 2500k h264.mp4
    4 MB
Zuletzt bearbeitet: (2)
  • Gefällt mir
Reaktionen: Looniversity
Looniversity schrieb:
Eigentlich müsste man das mal testen, indem man dasselbe raw-Material einmal mit den alten Codecs (was war das damals? Müsste sowas wie DV/H.263/"MPEG-alt"/DivX gewesen sein? Edit: Link zu Wiki) und einmal mit dem neuen AV2 kodiert. Da stellt sich schon die Frage, ob das überhaupt noch geht oder die alten Codecs angesichts von 4k-Auflösung und modernen Sensoroutputs schlicht kapitulieren.
Das ist in der Tat gar nicht so trivial, da z.B. H.262 (MPEG-2) nur bis Full HD spezifiziert ist, während moderne Codecs erst bei hohen Auflösungen alle Vorzüge ausspielen können. Blöcke von 128x128 Pixel ergeben bei SD-Auflösung z.B. keinen großen Sinn, außer das Halbe Bild besteht aus blauem Himmel.

Zudem ist die Frage, wie man "Stand der Technik von 1998" definiert. Encoder werden auch innerhalb desselben Codecs über die Jahre besser und signifikant mehr Rechenleistung erlaubt es erweiterte Modi sinnvoll zu nutzen.

Vergleiche einen frühen H264-Encoder (z.B. Nero um 2005) mit einem aktuellen x264-Build und der Sprung wird wsl. ähnlich groß sein wie von AV1 zu AV2, obwohl beides nach H264-Standard codiert ist. Jeder Codec reift über die Jahre, wenn er aktiv weiterentwickelt wird.

Und mit einem 1,x GHz Athlon 64 or Pentium 4 (beide Single Core) wird man zudem auch "etwas" sparsamer mit den H264-Profilen umgegangen sein als mit einem Ryzen 9 9950X ;) Rechenleistung bzw. der Zeitfaktor kann einen größeren Unterschied machen als zwei Codec-Generationen. Ich werde mit AV1 problemlos mehr Bitrate brauchen, wenn ich es in Echtzeit codieren will, als wenn ich bei x264 den Placebo-Modus aktiviere und einstellige FPS akzeptabel sind.
 
im Standbild sieht zwar AV1 besser aus,aber wenn man dann die feinen Blätter und so dann anschaut,sieht h264 wiederum besser aus.
Ich selbst habe auch BLuray mit 1080p 25 FPS da.Und dann wiederum welche videos mit 576I also da kann man nicht viel heraus holen.
Sind 3,4 MBit bei Mpeg 2 TS. Umgewandelt sind es dann am Ende 1,6 MBit.Dafür ohne Artefakte.Besser wird es auch da dann neuere Codecs aus dem TV Aufnahmen auch nicht mehr holen.
Und wirklich kleiner sehen dann auch die Videos nicht mehr so gut aus.Auch schneller Umgewandelt wird es dann auch nicht mehr.Hier Limitiert dann ab einen gewissen Punkt das Kompromieren.Wenn es nicht mehr genug Infos verkleinern kann,war es das halt.
Andere Codec wie AV1 und AV2 wird nicht schneller als H264 umwandeln können und Optisch wird man da auch nix mehr raus holen können.Und ab einer gewissen Bitrate sinkt auch der Platz also der Verbrauch nach unten kaum noch.Bildqulität kann man auch nix mehr raus holen.
 
Und für AV2 brauchts dann wieder neue Encodingchips in den Grakas ergo wieder neue Grakas, right ?
 
latiose88 schrieb:
Sind 3,4 MBit bei Mpeg 2 TS. Umgewandelt sind es dann am Ende 1,6 MBit.Dafür ohne Artefakte.Besser wird es auch da dann neuere Codecs aus dem TV Aufnahmen auch nicht mehr holen.
Je geringer die Auflösung, desto weniger Sinn ergeben moderne Codecs. Bei DVD-Material ist schon der Sprung von AVC zu HEVC/VP9 überschaubar, AV1 braucht dann eigentlich nur noch deutlich mehr Zeit.

Was bei DVD-Material viel wichtiger ist, ist das Filtern vorm Encoding. Ein anderes Deinterlace-Verfahren und Detelecine können das Bild ruhiger und damit "Encoder-freundlicher" machen, was nach meiner Erfahrung mehr als 1/3 Bitrate sparen kann. Dazu Deblocking-Filter, da MPEG-2 selbst auf Kauf-DVDs noch viel Artefakte hatte.

Auch das sehr hässliche "Digitalrauschen" früher HDTV-Kameras, wie sie bis ~2015 selbst bei großen Kino- und TV-Produktionen um Einsatz kamen, zu entfernen lohnt sich. Mdegrain2 + HEVC braucht auch viel Rechenleistung, das Ergebnis ist aber viel schöner und spart auch massiv Bitrate.
 
  • Gefällt mir
Reaktionen: Metalyzed und Deinorius
Haldi schrieb:
Jetzt wo die CPU Encoder so endlich mal schön optimiert sind...
Anfangs mit 3-5FPS, dann mit 35-70fps und nun mit 160-200fps.
Echt? Als ich vor ein paar Jahren mal av1 probiert hab (damals zwar noch auf nem i5-4590), waren es Bruchstücke eines fps, wenn man gute Qualli wollte.

Boerkel schrieb:
Schade dass sich AV1 nur so langsam durchsetzt. Der Unterschied zu h265 ist zwar nicht riesig, aber trotzdem summiert sich das, wann man mehr encodiert. Ein Film mag egal sein, mehrere Staffeln einer Serie hauen mehr rein.
Wenn das wirklich so viel schneller geworden ist, wie Haldi meint, probier ich’s vielleicht nochmal. Aktuell habe ich meinen Encoding-Prozess auf h265 ausgelegt. Hauptsächlich noch DVDs, aber seit kurzem stoßen auch BluRays zu meiner Sammlung dank einem neuen externen Laufwerk.

crustenscharbap schrieb:
Ich kann dir das nicht genau beantworten aber Softwarecodecs encodieren (also speichern) das Video immer in besserer Qualität. Ich codiere nach wie vor in H264 mit 2 Durchgängen auf der CPU.
crustenscharbap schrieb:
Aber letztendlich codiere ich meistens in H264 2 Pass SW Encoder. Ist halt ca 40% größer aber läuft überall.
Früher™ habe ich mit einer Tabelle gearbeitet, vorne die Videos und ihre Audiospuren sowie die Dauer und Auflösung rein gekippt, und hinten hat es mir die exakte Bitrate für jedes Video ausgespuckt, damit sie alle die gleiche Qualität bekommen und dann genau auf eine DVD-R passen. Lang ist’s her, inzwischen ist mir die exakte Dateigröße egal, weil eh alles auf dem NAS landet, sodass 2-pass irrelevant geworden ist.

12nebur27 schrieb:
Bin mir nicht sicher, wie es dir geht, aber wenn ich 1000 Filme bereits transkodiert habe aber bei denen alle flac gewählt habe, dann hätte ich kein bock die nochmal alle zu transkodieren.
Die könnte man mit einem kleinen Skript sicher schnell umgewandelt bekommen, das nur die Audiospuren neu codiert und alles andere durchschleift.

DonGeilo33 schrieb:
Jetzt stelle ich mal die frage, wie würdet ihr den Blu-rays transcodieren?
Habe mal ein paar Filme mit ffmpeg nach h265 codiert. https://trac.ffmpeg.org/wiki/Encode/H.265
CRF 18, medium... Teils schon enorme Ersparnis.
12nebur27 schrieb:
Ich erinnere mich nicht mehr genau, aber generell ist CRF 18 (glaub ich nutze 17?) schonmal nen guter Start.
Ich nutze tatsächlich eher crf von 20 bis 23 und sehe trotzdem kaum einen Unterschied. Dann noch 5.1-Ton mit Opus 384 kbps und so wird aus einem BluRay-Film von 35 GB einer von 2 bis 5, je nach Material. Ich war total baff, dass tatsächlich einige so klein wurden. Ich nehme eigentlich immer slow (normal verwischt tatsächlich Details sichtbar mehr) und weil ich nerdy bin, schalte ich auf Singlethreading, um nochmal 0,5 % mehr Qualität rauszuholen. :D Dafür encode ich dann mehrere Dateien parallel. Mein 8700G schafft dann leicht gedrosselt etwa 1/3 FPS bei FHD, bzw. etwas mehr als Echtzeit bei DVD.

Was mir aktuell noch fehlt sind gute Einstellungen für rauschiges, aber kleines Bildmaterial. Ich hab mir z.B. mal im Saturn-Abverkauf Knight Rider auf DVD geleistet und das Material ist extrem rauschig. Aktuell stelle ich dazu nur sao ab das lässt tatsächlich mehr Details da bei marginal mehr Bitrate. Aber wie alle hier suche ich das Optimum. 😅
 
  • Gefällt mir
Reaktionen: Persi82
Donnerkind schrieb:
Die könnte man mit einem kleinen Skript sicher schnell umgewandelt bekommen, das nur die Audiospuren neu codiert und alles andere durchschleift.
Ja oder man machts einfach direkt richtig mit Opus und spart sich die Nervigkeit.

Donnerkind schrieb:
Ich nutze tatsächlich eher crf von 20 bis 23 und sehe trotzdem kaum einen Unterschied.
Ich habe bei tests da schon ein paar Unterschiede gesehen, daher für das meiste crf 17. Für einige Live Action gehe ich dann eher auf crf 20 auch um Bitrate ein bissel im Griff zu halten, hängt immer vom Film dann am Ende ab.
Donnerkind schrieb:
Dann noch 5.1-Ton mit Opus 384 kbps
Das mache ich auch. Bzw. ich automatisiere die Channel konfiguration und bitrate je nachdem welches Codec und wie viele Kanäle. Stereo 192kbps, 2.1, 3.1 und 4.1 (kommt seltener vor) 256kpbs, 5.1 384 und 7.1 dann 512. 7.1 hatte ich aber tatsächlich noch nicht, ist also eher theoretisch.
Und ja, angepasstes slow ist ein muss. Ich war mir jetzt aber nicht bewusst, dass Single threadding einen qualitativen Unterschied haben soll? Wieso denn das? Kann ich ja mal testen, ich würde aber mal davon ausgehen, dass die SSIM und PSNR metriken da komplett gleich sein werden.

Was deinen letzten Punkt betrifft, kannste aufgeben. Ohne das zu denoisen wirste da nichts finden. DVDs sind ja auch sowieso nicht soooooo groß. Was sind schon 5gb? Ich habe auch ein paar Blu Rays wo ich das Filmgrain massiv reduzieren müsste für signifikante Speichervorteile. Liegt ja halt einfach in der Natur von Filmgrain. Da lasse ich das ganze dann am Ende manchmal auch einfach untranskodiert. Ist dann halt so.
 
Zuletzt bearbeitet:
Donnerkind schrieb:
Echt? Als ich vor ein paar Jahren mal av1 probiert hab (damals zwar noch auf nem i5-4590), waren es Bruchstücke eines fps, wenn man gute Qualli wollte.
Die von der Qualität her interessanten Presets bei SVT-AV1 sind immer noch langsam, Preset 4 enkodiert auf meinem 9800X3D in 4K mit 3-5 FPS. Richtig schnell sind nur die höchsten Presets, die kann man von der Bildqualität dann aber auch vergessen. Da kann man gleich die Hardware-Encoder auf den Grafikkarten nehmen.

Mit der Bitratenverteilung stimmt auch immer noch was nicht, ich habe vorhin testweise relativ sauberes 4K60-Videomaterial vom iPhone 17 Pro Max mit crf 20 und Preset 6 enkodiert, in den Szenen mit Bewegung knallt der Encoder da schon bis zu 400 MBit rein, aber wenn ich dann auf mein Gesicht gehe und einfach nur in die Kamera rede, meint er, er müsse komplett in den Bitratensparmodus gehen und nur noch mit 10 MBit enkodieren, dabei wischt er mir leider auch die Falten aus der Stirn. x265 kriegt mit crf 15 da eine bessere Qualität bei weniger Durchschnittsbitrate hin, weil x265 bei VLOG-Gesichtsshots einfach sich nicht zu Tode spart.

x264 und x265 haben ein relativ gutes Preset-System (das von x264 ist sogar exzellent) mit guten Standardeinstellungen, SVT-AV1 musst du halt wirklich mit zig Parametern verbiegen, bis da was gescheites bei raus kommt. Ist halt in erster Linie ein Production-Encoder, an dem Netflix ja auch mitentwickelt, für den privaten Hausgebrauch ist der nicht primär ausgelegt.
 
Zurück
Oben