Codec Wandlung nach Hevc

Anzeige

Mir war das halt irgendwann zu dämlich und belasse seitdem meine Sammlung in .ts und schneide nur noch. Durch das Umcodierung kann ich nur Qualität verlieren. Vor ein paar Jahren gab es auch noch nicht so viel Auswahl an hochoptimierten Codecs. Audio kommt ja auch noch hinzu und wenn die Tonspur größer als die Videospur ist, läuft was schief. Außerdem war meine CPU nicht besonders fit und eine sogenannte Hardwarebeschleunigung für Archievzwecke halte ich für ungeeignet.

Und da waren halt auch noch lauter so Details, wo ich was hätte falsch machen können, wo ich mich dann im Nachhinein geärgert hätte. Den Seiteneffekt mit 50p bei ÖR hab ich ja erklärt, glaube ich. Dann sind da noch Untertitel. Und in meinen ersten Tests meinte ich, die Größe ändern zu müssen bzw. schwarze Balken abzuscheiden - bringt gar nichts.

Wirklich geärgert hätte ich mich auch, wenn das Versprechen von hevc wahr gewesen wäre, bei gleicher Qualität halb so groß wie avc. Damals gab es noch kaum Unterstützung für hevc. Aber für meine hauptsächlich SD-Konvertierungen stimmt das halt nicht. Bei meinen Kurztests oben spricht einiges für 10% "besser". Vielleicht wären es 25% für FullHD, wie man anderswo nachlesen kann. Aber ist halt immer die Frage, wieviel mehr Rechenleistung das kostet. Und mit dem Intelchip als Alternative ... naja. Siehst ja selber, bzw. solltest mal nachlesen, wie genau die Schnelligkeit erreicht wird. 1:1 wie bei Standardeinstellungen eines Softwarecoders ist das jedenfalls nicht und die Bandbreite die man an einem Softwarecoder einstellen kann ist halt gewaltig. Da ist Faktor 100 und mehr bei der Geschwindigkeit drin und was an Qualität rauskommt ist meist subjektiv. Filegröße ist zwar auch ein Indiz aber nur ein schwaches.

Also was du realistisch erreichen solltest, ist bei SD in mpeg2 eine Halbierung bis Drittelung der Größe. Bei Zeichentrick nochmal die Hälfte. Bei h264 kommt es drauf an. Das was über dvb der ÖR kommt, da geht auch fast die Hälfte, weil die auch auf alte Receiver Rücksicht nehmen und gerne Füllbits drin haben. Also grob geschätzt 60% der Originalgröße mit x264 und 50% mit x265. Bei Onlinequellen sieht es anders aus. Keine Füllbits, kaum Rücksicht auf Endgeräte und keine älteren Produktionsstrecken, die in Echtzeit das Zeug senden müssen, sondern Offlinekonvertierung. Da kann es sein, dass du nur verlierst, durch eine ReCodierung, also sichtbarer Qualitätsverlust bei größerem File.

Und die Schätzungen waren ohne Rücksicht auf die Geschwindigkeit. Beschleunigereinheit hin oder her, Rechenleistung gibt es nicht umsonst. Bei deiner 15Watt CPU oder was das ist, bringt es aber vermutlich mehr, als bei nem 100 Watt Chip, wenn auf beiden die gleiche Einheit aufgedampft wird.

 

danke,

ich habe jetzt nur 1 Datei vom Kabelempfänger getestet. x264. Diese ist aber nicht häufig vorhanden, so dass ich jetzt eine SD Datei testen müßte, die am häufigsten gesendet wurde. Das sind Diskussionen vom SWR mit einem Satelltenempfänger. Diese sind je 6 GB groß. je 3x2GB. Diese Dateien sind auch in der Mediathek vorhanden und haben dort 384 MB. Die Auflösung ist in der Mediathek zwar verringert, aber ich sehe kaum einen Unterschied zu meinen SD Aufnahmen. Um diese Dateigröße zu erreichen, müßte ich wohl eine konstante Bitrate einstellen. Ich habe da ca. 300-400 Sendungen.

Der große Tonplatzbedarf kommt vom DTS Ton. Ich hatte den DTS Ton mal umgwandelt in einen Normalton, weil das Programm keinen DTS Ton wiedergeben konnte und VLC das Bild nicht richtig wiedergeben konnte.

Onlinequellen habe ich nur wenig. Ein kleines Problem wird noch sein, dass ich meine Dateien nicht nach Quelle sortiert habe, sondern nach Inhalt. Handbrake merkt nicht, wenn das Ergebnis schlechter ist als das Originat. Zumindest ein Größenvergleich fehlt noch. Besser als das Original kann es ja nicht werden.

3D und Reisesendungen werde ich erstmal im Original behalten, weil es da auf Qualität ankommt.

Die Wiedergabe auf Endgeräten müßte ich auch noch testen, sehe das aber nicht als vorrangig an, weil es da bei jedem Gerät Mängel gibt. Evtl. kann ich da durch die Umcodierung eine bessere Einheitlichkeit bei der Wiedergabe erreichen.

 

Das Versprechen bezieht sich natürlich auf das Kodieren von unkomprimiertem Video als Ausgangsmaterial, nichts aufs Umkodieren von Video welches bereits als Ausgangsmaterial komprimiert ist.

 

Auf keinen Fall! Dafür gibt es 2-pass und Zielgröße. Konstante Bitrate bei offline Umwandlungen bringt zwar das richtige Größenergebnis, verschenkt aber ohne Grund Qualität.

Aber mit superfast und vermutlich Hardware brauchst da wohl eher nicht rangehen und auf gute Qualitiät hoffen, aber läßt sich ja leicht testen. Ich würde mich jedenfalls einlesen, welcher tune Parameter für was gut ist und mit medium bei Geschwindigkeit anfangen.

Das ist dann aber schon recht klinisch. Welche digitale Kamera zeichnet bitte unkomprimiert auf? Das was am heimischen PC mit x265 gemacht wird, ist normal immer Offlinerekodierung von bereits komprimiertem Material - vielleicht abgesehen von Live-Streaming. Wenn die Kamera das mit hevc statt avc aufzeichnet und dadurch länger aufzeichnen kann, sehr gut. Aber selbst das was sie da aufzeichnet ist nicht am Limit komprimiert.

Die Standardeinstellungen bei x264/5 sind über die crf von 20 und 28 jedenfalls schonmal so gewählt, dass eine Augenwischerei bezüglich der Zielgröße entsteht. x265 crf 28 sieht nunmal nicht genauso gut aus, wie crf 20 x264. Jedenfalls nicht bei SD. Und der Unterschied ist nicht irgendwie gefühlt, sondern man erkennt an bestimmten Stellen deutlich Artefakte. Mir besonders bei Kopfbewegungen aufgefallen.

Wählt man bei beiden den gleichen crf, ist x265 zwar immer noch "besser", also das File ist kleiner, aber halt eher so 10% kleiner. Und das ist alles noch mit Standardeinstellungen und ohne Berücksichtigung der reingesteckten Rechenleistung. Natürlich ist x265 besser, aber das erkauft man auch mit mehr Rechenleistung beim Encodieren und beim Decodieren.

 

In TV-Studios wird das Live-Videosignal von der Kamera in unkomprimierter Form weiterverarbeitet. Erst bei der Aufbereitung zur Ausstrahlung wird es kodiert.

Darauf bezieht sich die Angabe von der Halbierung der Datenrate allerdings nicht.

 

Es gibt Kameras die können verlustlos komprimieren, also quasi eine Art ZIP Archiv erstellen. Das ist praktisch unkonmprimiert.

Was die Echtzeit-HEVC Aufzeichnung angeht, so ist das vor allem eine Frage der Prozessorleistung, und somit der Akku Lebensdauer. Auch hochwertige Kameras, liegen heute meist weit hinter modernen Smartphones, was die Prozessorleistung angeht. Manche bieten eine HEVC Aufzeichnung, dabei wird aber oft nur schwach komprimiert, weil der Prozessor nicht mehr hergibt. Was Rechenleistung angeht können es manche Smartphone Modelle heute ja locker mit einem PC aufnehmen, das darf man aber nicht als Standard betrachten. Die potentiell hohe Komprimierung von HEVC bekommt man nur mit ordentlich Prozessorleistung, und dazu schnellen Speicher, denn die Kompression entsteht vor allem aus dem Vergleich von hintereinander liegenden Bildern.

 

Vielleicht war ja das bei mir der Flaschenhals, warum x265 die Rechenleistung nicht auf den Prozessor bekommen hat. Mein Proz ist "schneller" als mein Speicher.

--

Aber ich denke, so schnell werde ich kein hevc oder avc mehr codieren. Vielleicht kommen ja die Tools für av1 dieses Jahr in Fahrt. Auch wenn der Codec theoretisch auf Augenhöhe mit hevc ist, die Encoder werden noch einiges an Optimierung brauchen. Und dann darf ich wieder Guides dazu durchlesen, aber was soll's, ist Teil des Hobbys .

Wird dann die nächsten Jahre interresannt, ob und wie sich hevc und avc halten werden. Die leiden halt an der Patentseuche.

 

Verlustfreie Videocodecs funktionieren ein wenig anders als ZIP, das Resultat ist aber dasselbe. Es gibt keinen Qualitätsverlust,
und dann gibt es noch die häufig genutzten near-lossless, also nahezu verlustfreien Modi, weil es einfach sinnfrei ist das Rauschen des Bildsensors der Kamera verlustfrei aufzuzeichnen. Das verschwendet eine Menge an Daten. Rauschen ist nunmal nahezu unkomprimierbar.

Nicht unbedingt weil Videokompression und -dekompression heute mittels VPU erfolgt in modernen Geräten. Das sind spezialisierte Recheneinheiten, unabhängig von der CPU.
Bei SoC in Smartphones sind diese meist zusammen mit den Recheneinheiten für die Grafik zusammengeschaltet.
Videokompression erledigen die wenigsten Geräte über die CPU. Für H.265 werden fast immer spezialisierte VPU verwendet weil CPU-Recheneinheiten für diese Aufgabe nicht optimal sind, brauchen zuviel Energie für diese Aufgabe. Spezialisierte Recheneinheiten sind deutlich effizienter für Video, besonders für Echtzeitkodierung.
4k-Video in H.265 u. Echtzeit kodieren schaffen derzeit nur darauf spezialisierte Recheneinheiten.

 

Ich finde, da ist ein bisschen analoges Denken noch vorhanden. Will sagen h265 ist nicht gleich h265. Meine CPU ist nicht wirklich langsam und schafft mit x265 bei meinem 4K Testfile (60p) nur etwa 20 fps bei halber CPU Last. Und das mit "ultrafast". Für qualitativ interresante Umwandlungen wird es also noch schlechter aussehen für Echtzeitumrechnungen. Sicherlich, durch die hohe Auflösung kann man viel kaschieren, aber wozu überhaupt die hohe Auflösung: wenn man beliebig schlampig encodiert, erreicht man irgendwann den Punkt, an dem gut encodiertes und anschließend hochskaliertes Material besser aussehen wird.

Das Testfile ist von 750MB auf 73MB geschrumpft . crf 28 ultrafast x265.

Aber keine Sorge, ich schaffe auch mit x264 crf 28 ultrafast kein Echtzeit. 50 fps bei 60 % CPU. Ergab mit crf 28 ultrafast x264 von 750MB auf 552 MB.

Ohhha. Ist h265 jetzt doch sogar 7x besser als h264 und nicht nur 50% bzw 2x besser? Aber Moment, das Quellfile war ja bereits in h265?!

Hmm. Vielleicht heißt das einfach nur, man sollte Codecs nicht auf ihren Extremeinstellungen vergleichen und bei 4k 60p ist dermaßen viel Spielraum, dass man bereits im gleichen Codec mal eben auf einen Faktor 10 kommen kann, ohne dass man sofort einen Unterschied sieht (ich sowieso nicht, weil ich kein 4k Display habe). Da eigentlich nur eine bessere Kompressionsrate bei gleicher Qualität von 25% bis 50% gegenüber h264 versprochen wird, gehe ich mal davon aus, dass der extreme Größenunterschied durch Qualität bezahlt wurde. Wäre h265 bei 4k wirklich sooo viel besser als h264, würde das doch an die große Glocke gehängt werden. Oder was heißt 50% bessere Kompression überhaupt? Rechne ich die ganze Zeit falsch? Wenn h264 ein 100 MB File erzeugt, würde h265 dann ein 50 MB oder ein 66 MB File erzeugen bei "50% besserer" Kompression? Darf man so überhaupt rechnen? Oder muss ich so vorgehen: aus 1000 MB werden 100 MB mit Coder 1, das entspricht einer Kompression von 90%. Eine um "50%" bessere Kompression mit Coder 2 würde ... mir brummt der Schädel. Wie vergleicht man prozentuale Kompressionsraten prozentual?

 

Diese Thematik ist alles andere als trivial.
Und dass die Behauptung halbe Datenrate bei gleicher Bildqualität tatsächlich stimmt konnt bislang niemand für alle Bildinhalte belegen.

Was den Vergleich der Video-Bildqualität betrifft so wird sehr oft VMAF dafür verwendet. Diese fasst mehrere Einzeltests zusammen.