H.264/AVC Videostreams noch 20% komprimierbar?

[Robert Schlabbach]

Ich habe mir gerade ein Tool gebastelt, um "Fülldaten" aus MPEG-2 und H.264/AVC Videostreams zu entfernen. Um den Erfolg zu testen, versuchte ich, aus "Das Erste HD" bzw. "Das Erste" aufgenommene, von Fülldaten (zero byte stuffing bei beiden Formaten und zusätzlich NAL Filler Data Units bei H.264/AVC) bereinigte "nackte" Videostreams von etwa 200MB Größe mit RAR und ZIP zu packen, mit für mich überraschenden Ergebnissen:

Format    | Originalgröße |  ZIP-Datei  |  RAR-Datei
----------+---------------+-------------+-------------
MPEG-2    |  206.141.547  | 202.041.531 | 201.365.821 = -2,3%
H.264/AVC |  205.325.211  | 166.249.104 | 162.838.318 = -20,7%

Während sich der MPEG-2 Videostream also nur um 2% packen ließ, waren es beim H.264/AVC Videostream 20%. Ich habe die Datei im Hexeditor angeschaut, es sind keine offensichtlichen "Komprimierbarkeiten" erkennbar, es sind keine NAL Filler Data Units enthalten, es gibt auch nicht mehr als 3 Nullbytes und 5 0xFF-Bytes in Folge. Sieht also alles korrekt "bereinigt" aus, trotzdem ist der Stream noch so deutlich kompressibel. Bei mehreren Versuchen ergab sich das gleiche Bild - MPEG-2 nahezu inkompressibel, H.264/AVC um ca. 20% kompressibel.

Hat jemand eine Erklärung dafür? Ist H.264/AVC so ineffizient, sind die Encoder bei der ARD so schlecht, braucht man das, um genug IDR Frames zu senden, oder hat man soviel Bandbreite übrig, dass man ein wenig damit aast und viel Redundanz einkomprimiert?

Wenn die ARD bei ihren 4 HD-Programmen pro Transponder diese 20% einsparen könnten, hätten sie ja glatt Platz für ein fünftes, bei gleichbleibender Bildqualität...

[Martin_K]

Ohne den Code deines selbst gebastelten Tools oder deine Samples nach dem Bereinigen zu kennen, kann ich dazu natürlich nicht viel sagen.
Aber es liegt nahe, dass du bei H.264 irgendetwas übersehen hast. Ich bekomme bei einem bereinigten H.264 Sample gegenüber einer ZIP-Kompression desselben auf eine Ersparnis von ca. 3,4%.
Entfernst du die Filler auf ES-Ebene (also dem demuxten H.264 Stream) oder auf TS-Paketebene?

[hopper]

AVC ist als Echtzeitencoder ungeeignet. War es schon immer, sowas wird halt von Leuten entschieden, die keine Ahnung haben und eine andere Motivation verfolgen.

Dennoch, 20% könnte daran liegen, dass die Frames temporal nicht enkoppelt sind. Mit anderen Worten, es sind statt 50 Vollbildern nur 25 Vollbilder, oder irgendwas dazwischen wegen der Umrechnung/Umsetzung. Denkbar wäre desweiteren, dass 2 Encoder in Kette eingesetzt werden und jeder encoded jedes 2 Frame, dabei entstehen Redundanzen, weil die Encoder einander nicht kennen. Genauso möglich sind schwarze Ränder. Und dann gibt's noch die Möglichkeit, dass die Filler-Daten nicht 00h sind, sie können ja jeden Wert annehmen. Desweiteren ist es möglich, dass als Filler-Daten bestimmte Slice-Sequenzen einfach wiederholt werden, das macht die P7S1 Gruppe gerne.

Oder Du hast einen Fehler in Deinem Programm.

[Robert Schlabbach]

Zitat von hopper

Dennoch, 20% könnte daran liegen, dass die Frames temporal nicht enkoppelt sind. Mit anderen Worten, es sind statt 50 Vollbildern nur 25 Vollbilder,
[...]
Genauso möglich sind schwarze Ränder.

Bei meinen Tests gestern lief gerade ein Film im Pillarbox-Format (4:3 mit schwarzen Rändern links und rechts), und der wird wohl auch nur 25 Vollbilder gehabt haben (hat das nicht das meiste Quellmaterial?).

Also ist es normal, dass H.264/AVC Encoder unter solchen Bedingungen Streams produzieren, die noch sehr kompressibel sind...?

Ich habe mein Sample mal hier raufgeladen, falls jemand über entsprechende Analysetools verfügt, würde ich mich über ein Feedback freuen, woher die Komprimierbarkeit kommt:
http://user.cs.tu-berlin.de/~normanb..._HD_Sample.rar

Abspielen lässt sich die Datei z.B. mit ffplay (während VLC sie nicht mag).

[hopper]

Danach wollte ich fragen, mal den R&S ausleihen....

[hopper]

Die Kollegen benutzen eine 4-B Kette, sehr effizient. Lobenswert. Dynamische GOP Länge, ca. 1-1.5 Sekunden lang.

Haben die bekannten 3 PPS - benutzen aber nur #0. Wobei diese 3 verschiedene Matrixen verwendet. Wahrscheinlich je nach Zuführung. Der Stream ist nebenbei 100% AVC konform. Absolut konform. Fürs HIGH Profile. Da sitzen Profis bei der Sendeabwicklung. Hut ab!

Nebenbei, das Video ist 25 fps - jedes Frame wird 2x gesendet. Daher wohl die 20%

[hopper]

Das wird aber als 50 fps auf den AVC Encoder zugefüttert. Ich seh ein marginales Rauschen auf den zusammengehörigen Bildern. APSNR von ca. 70, das ist nur programmatisch zu erkennen - nicht visuell.

[hopper]

Schau Dir das mal in Supervergrößerung an, ist .png also lossless. Differenz mit Verstärker zwischen 2 Bildern auf dem Y-Kanal.

[Robert Schlabbach]

Zitat von hopper

Nebenbei, das Video ist 25 fps - jedes Frame wird 2x gesendet. Daher wohl die 20%

Hmm, ich habe gerade ein Stück von "Die Villa" auf zdf_neo HD aufgezeichnet, als Kinofilm müsste das doch auch nur 25 fps haben - es ist aber völlig inkompressibel!?

Zitat von hopper

Schau Dir das mal in Supervergrößerung an, ist .png also lossless. Differenz mit Verstärker zwischen 2 Bildern auf dem Y-Kanal.

Zwischen 2 theoretisch gleichen Bildern wegen der fps-Verdopplung? Woher kommen die Unterschiede? Sind die erst im Encoder quasi als "Artefakte" entstanden, oder wurden die vorher erzeugt?

Warum macht man eigentlich nicht so etwas wie manche TVs, also richtige Zwischenbilder berechnen um aus 25fps Quellmaterial 50fps zu gewinnen?

[hopper]

So viele Fragen.

* Kino ist 24 fps, und je nachdem ob es direkt (24 fps) oder indirekt (30 fps, NTSC) kommt, ändern sich die "doppelten" Bilder.

* Der Encoder weiß nichts davon, dass Bilder doppelt sind. Und je nach Bitratenverfügbarkeit, die sich ja bei jedem Bild ändert, encodet er anders. Daraus entstehen verschiedene Koeffizienten in den DCT Matrizen und das erzeugt diese Artefakte. http://upload.wikimedia.org/wikipedi...23/Dctjpeg.png

Einige dieser Muster siehst Du auf dem blauben Bild oben, teilweise mehrere übereinander.

Außerdem, Encoder benutzen auch Zufallsgeneratoren. Ähnlich wie Schachprogramme, irgendwann müssen sie sich entscheiden, weil den optimalen Weg finden Encoder nicht. Deswegen ist AVC auch schlechter geeignet, als VC-2 (Dirac). Zu viele Entscheidungswege.

* Könnte die ARD machen, Felder zur Duplizierung (repeat_frame) gibt es. Aber wir kennen ja dann das Ergebnis, der Baumarkt-Schrott steigt dann aus und die ARD ist wieder Schuld.

[h.265]

Welchen Algorythmus hats Du bei Zip verwendet? Moderne Kompressionstechniken wie PPM, LZMA oder PAQ können auch ähnliche Daten sehr gut komprimieren. Auch Deflate kann solche Dinge gut komprimieren wenn Du die Wortgröße nur hoch genug setzt. RAR benutzt einen PPM Kompressor.

[Robert Schlabbach]

Zitat von hopper

So viele Fragen.

Sorry, aber wenn meine Neugier erst einmal geweckt ist und ich einen kompetenten Ansprechpartner finde...

Also hat der Analyzer keine Fülldaten in dem Sample gefunden? Dann hätte zumindest mein Tool ja richtig funktioniert...

Zitat von hopper

* Könnte die ARD machen, Felder zur Duplizierung (repeat_frame) gibt es. Aber wir kennen ja dann das Ergebnis, der Baumarkt-Schrott steigt dann aus und die ARD ist wieder Schuld.

Könntest Du zum Vergleich vielleicht noch dieses Sample von zdf_neo HD durch den Analyzer schicken? Das müsste auch 25 fps haben, aber es ist völlig inkompressibel. Mich würde mal interessieren, wie das ZDF das hinbekommt:
http://user.cs.tu-berlin.de/~normanb..._HD_Sample.rar

[hopper]

Solange ein Smilie am Ende der Zeile steht, ist keine Entschuldigung oder Rechtfertigung notwendig.

Keine Fülldaten, nein. Denkbar wären noch welche auf Slice-Ebene. Das kann ich aber nicht so einfach testen - selbst wenn, da müßtest Du einzelne Bits aus dem Stream löschen und die nachfolgenden Bits nachrücken lassen. Bits - nicht Bytes!

TU Berlin? Wirklich, da hab ich immer Zeit

[Martin_K]

Danke für das Sample.
Mit meinem Tool konnte ich aber auch nicht mehr entfernen, liegt also nicht an einem Fehler im Programm (am Dateiende hast du noch drei Nullbytes, das ist wahrscheinlich der Startcode von der nächsten NAL Unit, die wurden bei mir noch entfernt ).

Interessant ist nur, dass das wohl ausgerechnet bei diesem Sample so zu sein scheint, wenn ich eigene teste, lassen die sich mit ZIP nicht viel besser packen (habe auch deins selbst nochmal gezippt, auch da komme ich auf ~20%).
Ich nehme mal an, dass es evtl. wirklich am 4:3 Pillarboxed Bild liegt. Ich muss mal Samples in Pillarboxed selbst testen, wenn mal wieder ne 4:3 Sendung kommt
An 25 fps liegts jedenfalls nicht, denn da habe ich schon einige Kinofilme getestet

Wenn du mal andere H.264 Samples testest, kommst du dann auf die selben Ergebnisse? Bei zdf_neo ja offensichtlich nicht, am besten testest du mal andere Aufnahmen der ARD...

[hopper]

ZDF benutzt kürzere Ketten, die haben zudem einen unbekannten SEI drin pro Bild von ca. 20 Byte. Den kannst Du entfernen.

2x PPS, wobei die gleich zur ARD sind. Auch der AVC Stream ist 100% konform. Hat ja die DF nicht hinbekommen, sowas rauszufinden.

Der Stream "pulst", kommt also sehr wahrscheinlich via NTSC. Da ist das übliche 2:3 Pulldown / Telecine drin (24 fps -> NTSC), welches dann zu PAL 50 gewandelt wurde. dadurch sind die Differenzen zwischen 2 benachbarten Bildern größer.