Codec Wandlung nach Hevc

Anzeige

Ich habe festgestellt, dass bei der Umstellung von DVB-T (Mpg2) auf DVB-T2 (Hevc) die Dateigrößen im Durchschnitt gleich geblieben sind, aber eine erheblich höhere Auflösung haben. (5x besser). bei gleicher Auflösung müßte die Datei danach 5x kleiner sein.

 

Nicht unbedingt. Du kannst das individuelle Bildrauschen eines Sensors mit Langzeitbelichtung im dunklen ermitteln, und dann später rechnerisch entfernen. Das gleiche geht statistisch wenn man viele Bilder macht. Der Ansatz ist, dass das Rauschen abhängig von Temperatur und Sensor immer gleich ist, auf jedem Bild, und so kann man es entfernen. Natürlich nur bei unkomprimierten Bildern.

 

Falls du damit meinst, sie hätten beim Wechsel von t auf t2 auch in SD senden, den Codec wechseln und dann viel mehr Kanäle übertragen können, ja, hätten sie machen können. Zumindest für ein paar Spartensender oder so. Stattdessen wurde halt die vorhandene Bandbreite für FullHD und diese freenet-Seuche oder was das sein soll, verwendet.

Die Bitraten bei dvb-t waren aber früher eher schlechter, als über Sat. Und eigentlich sollte in dem Fred mittlerweile rausgekommen sein, dass man das nicht so genau sagen kann, was man da an Filegrößen erwarten kann. Hevc ist jedenfalls effizienter, je höher die Auflösung. Was du auf dvb in mpeg2 bekommst, kannst du jedenfalls ohne größere Anstrenungen halbieren, durch einen Codecwechsel. Aber dritteln oder vierteln oder gar fünfteln, da kommt es schon arg auf das Quellmaterial an. Also ohne störenden Qualitätsverlust. Auf Daumenkino runterrechnen geht immer .

Jedenfalls finde ich, da ist bei den Leuten immer noch zu viel analoges Denken vorhanden. Als damals die Blu-rays so rauskamen, hatte ich eigentlich auch gedacht, super, da kann man ja alte Serien die es eh nur in SD gibt mit dem neuen Codec auf die Scheiben pressen und das Äquivalent von zig DVD auf wenige BR pressen. Nix gab's. Stures "analoges" Formatschubladendenken. SD muss mpeg2 sein. Und sogar bei den 4K Scheiben werden den Leuten auch hochskalierte Titel untergejubelt, so wie damals bei den BR auch manchmal.

 

Ich frage mich wirklich wo das herkommt. Wie kann man sowas berechnen? Also welche Zahlen verbindet man, um auf 50% zu kommen?

Mein Testfile weiter unten, mit dem Compressibility sagt mir jedenfalls 0,15 bei x265 und 0,18 bei x264 für die SD-Aufnahme.

Na das ist doch mal ein Ansatz . Ich wünsch mir schon lange eine "Informationsrate" als Gegenstück zur Datenrate. Ein Schritt in die richtige Richtung.

Ich nenne es ja gerne analoges Denken, wenn die Codec-Namen wie analoge Formate verwendet werden. Die Wahrheit ist aber, je höher die Datenrate, desto weniger Unterschiede, bis hin zu verlustloser Komprimierung. Und aus eigener Erfahrung weiß ich halt, welche gewaltigen Unterschiede sogar innerhalb ein und desselben Encoders auftreten können, je nach Optionen.

Fehlt nur noch ein Hilfsmittel, um eine mögliche Komprimierung zu empfehlen. Aber vielleicht gibt es das ja schon und ich übersehe es nur...

In StaxRip gibt es jedenfalls für x264 und x265 einen Knopf für compressibility check, wenn ich die Encoder auf 2 pass stehen habe. Nachdem das durchgelaufen ist, kann ich an der Zielfilegröße rumspielen und er sagt mir die prognostizierte "Qualität" in Prozent an. Sogar bei 100% ist die Zielfilegröße kleiner als die Quellgröße. Hmmm. Also wenn das wie gedacht funktioniert, sollte man so für einzelne Umcodierungen ein Optimum an Qualitätserhalt finden können. Oder für die eigenen Ansprüche seiner Mediensammlung ein Sparpotential mit dem man leben kann.

 

Marketingabteilung der MPEG. Vorher sonst?

 

Nur hat man bei Video keine Langzeitbelichtung sondern eine Belichtungsdauer von 1/Framerate pro Bild.
Das Rauschverhalten von Bild zu Bild ist daher nicht vorhersagbar u. lässt sich praktisch nur in statischen Bildsegmenten kompensieren.
Und nun die Grechtenfrage. Wie soll die Elektronik zwischen tatsächlicher Bewegung des Bildmotives und Bildrauschen unterscheiden? Funktioniert nur mit KI, soweit ist die Technik bei Videoaufnahmen in Echtzeit noch nicht, jedenfalls genügt diese nicht den Qualitätsansprüchen.

Rauschen des Bildsensors kann bei Fotos kompensiert werden, aber nicht bei Video. Die Vorrausetzung ist nämlich dass sich das Bildmotiv selber von Aufnahme zu Aufnahme nicht verändert. Nur erfüllt Video einen anderen Zweck; man möchte doch damit gerade sich verändernde Szenen aufnehmen.

 

Du hast den zweiten Teil meines Beitrages unterschlagen. Bei Videos geht das auch statistisch. Tatsächlich hängt das Rauschen vor allem vom Sensor und der Temperatur des Sensors ab. Ich meine sogar das Rauschen wird als eine Art Fingerabdruck für Kameras verwendet. Bei einem unkomprimierten Video muss man also "nur" nach immer gleichen Strukturen in allen Bildern suchen, schon hat man das Bildrauschen, und kann es wegrechnen.
Aber wie gesagt, das geht heute noch nicht live.
Schau dir mal diverse Stacking Software an, inbesondere für Astrofotografie. Die berechnen ein Standbild aus Bildserien oder Videos, mit auf herkömmlichen Weg unerreichter Schärfe, und frei von jedem Rauschen.

 

Mit verlustfrei ist üblicherweise bit-identisch gemeint, aber das funktioniert nicht weil das Rauschen des Bildsensors nicht bitgenau vorhersagbar ist.
Man hat also immer ein Signal welches dem eigentlichen Bildsignal überlagert ist, welches unbekannt ist.
Das meinte ich. Man kann das Bildrauschen schon zu einen gewissen Grad wegrechnen aber nicht aufs LSB (least significant bit) genau.
Deshalb ist verlustfreie Datenkompression bei Video so ineffizient u. man begnügt sich meist mit near-lossless oder visual-lossless Kompression im Profi-Videobereich.

Vielleicht ist das nun besser verständlich was ich meinte. Für das menschl. Auge kann das Rauschen sichtbar weggerechnet werden, aber es bleiben immer noch Unterschiede auf Ebene der digitalen Samplewerte der Bildpunkte übrig.

 

Hmmm. Was das genau heißt, verstehe ich nicht, aber soweit ich ein Problem der modernen Videobildaufnahme richtig verstanden habe, wird ein Bild nicht in 1/Framerate belichtet, sondern schneller.

Das Problem ist Ruckeln und die Ursache ist das Fehlen der Bewegungsunschärfe durch die kurze Belichtungszeit.

 

Sind das die freundlichen Leute, deretwegen man ein paar Pfund löhnen darf, wenn man auf seinem Raspberry mpeg2 HW-Unterstützung freischalten will?

Aber im Ernst, wenn ich mein Samsung-Demofile als "unkomprimiert" betrachte und mit den gleichen Einstellungen x265 und x264 drüber jage, ist das Resultat sogar um Faktor 8 kleiner und nicht nur Faktor 2 - falls man so die 50% berechnen würde. Der Compressibility-Check brachte bei beiden jedoch 0,13, was auch immer das heißen mag. Und crf ist anfällig für Seiteneffekte und ungewollte Optimierungen. Und mit preset ultrafast sollte man sowieso bei Vergleichen vorsichtig sein.