DCT, GOP und der Rest der Welt

	Matrix, GOP und der Rest der Welt
	von Kika

Vor dem Encoden eines Videos in MPEG1 oder MPEG2 stellen sich immer wieder die gleichen Fragen: Was nehme ich denn nun? Eine lange GOP? Oder doch besser eine kurze? Und welches ist die beste Matrix? Ist die auch für alle Filmarten benutzbar? Und warum mache ich das überhaupt? Fragen über Fragen, zum Glück gibt's Antworten, auch wenn diese vielleicht doch nicht unbedingt die Antworten sind, die viele erwartet haben.

Also, mein Beitrag hier im EDV-TIPP gliedert sich in vier Abschnitte:

DCT & Matrix, was ist das?
Motion prediction und Estimation
GOP-Größen und was dabei passiert
Praxis: Wie setzt man das Wissen aus den drei ersten Teilen in echte Ergebnisse um

Fangen wir nun direkt mal mit dem ersten Beitrag an:

Blocks, DCT und Matrix oder "von Steinen und Wellen im See"

OK, um zu verstehen, wie das mit der Matrix und den GOP-Längen so ist, muss man erst mal die Grundlagen kennen. Den Anfang machen wir mit den Blocks, der DCT und der Matrix.

Zunächst muss man wissen, dass die kleinste in MPEG vorhandene Bildeinheit nicht ein Pixel, sondern ein Block von 8x8 Pixels ist. Ich verwende zur Erklärung jetzt mal ein stark vereinfachtes Modell, das an die Adresse der Profis, die angesichts mancher nun folgender etwas "unscharfer" Erklärung vielleicht die Nase rümpfen.

Am Block wird die sogenannte DCT (Discrete Cosinus Transformation) durchgeführt. Ein Verfahren, bei dem der Block in seine Frequenzbestandteile zerlegt wird.

Was dabei entsteht und an Stelle der ursprünglichen Pixel gespeichert wird, ist eine Matrix aus Frequenzinterferenzen, wobei jede einzelne Zelle das Frequenzspektrum des gesamten ursprünglichen 8x8-Block repräsentiert (der Einfachheit halber gehe ich mal von einem S/W-Bild und nicht von einem Farbbild aus).

Allerdings gilt das nur sehr begrenzt, denn die erste Zelle (genauer gesagt: das erste Element) allein kann quasi nur eine simple graue Fläche wiedergeben und steht somit für die durchschnittliche Helligkeit des gesamten Blocks. Nach rechts aufsteigend werden dann vertikale "Balken" hinzugefügt, so dass die achte Zelle ein Muster aus Gitterstäben enthält.

Analog dazu verhält es sich mit den Zeilen. Von oben nach unten kommen immer mehr horizontale Balken hinzu, am Ende entsteht dadurch ein Streifenmuster. Diagonal hat das die Auswirkung, dass ein immer komplexeres Gittermuster entsteht. Die 64ste Zelle schließlich ist von der Frequenzauflösung her in der Lage, das Bild ohne jeden Qualitätsverlust wiederzugeben.

Wie das ganze aussieht, kann man dem Bild entnehmen.

Wer jetzt glaubt, nur den Inhalt der letzten Zelle speichern zu müssen, der irrt, auch wenn das jetzt scheinbar dem widerspricht, was ich bisher schrieb. Ist aber leicht zu verstehen, wenn man sich ins Gedächtnis zurückruft, dass nur Interferenzmuster gespeichert werden, erst mehrere davon ergeben etwas, was sich wirklich Bild nennen könnte.

Das jetzt näher zu erklären, würde sehr umfangreiche Mathematikkenntnisse voraussetzen, die ich selbst auch nicht habe, belassen wir's also dabei: Ein guter Mathematiker könnte theoretisch aus den Welleninterferenzen (Element der Blockmatrix nach der DCT) auf einem See (dem Block) berechnen, wie viele Steine (Pixel) wo ins Wasser geworfen wurden (Postion des Pixels) und wie schwer die waren (die Helligkeit), und auf die gleiche Weise wird später auch wieder das Bild erzeugt. Die Steinanalogie ist deshalb wichtig, weil wir sie später noch brauchen.

Wichtig ist dabei aber noch eines: Die Zellen mit höheren Zellennummern nehmen komplexere Spektren auf. Lässt man nun Spalten, Zeilen oder auch Zellen weg, um Speicherplatz zu sparen, dann nimmt man dem ursprünglichen Bild Schritt für Schritt an Komplexität. Das geht bis zu einem gewissen Punkt ganz gut, weil das menschliche Auge eh nicht so gut sehen kann.

So, wir haben das Bild in Blocks zu 8x8 Pixel zerlegt und die haben wir zu Frequenzen verarbeitet. Schön kompliziert, bringt aber noch nicht ein einziges Byte Platzersparnis. Die kommt erst im nächsten Schritt, der Quantisierung, wofür die allseits beliebte Matrix benutzt wird (welche auch immer).

Die DCT selbst ist vom Grundprinzip völlig verlustfrei, dadurch, dass in den Zellen aber nur Integerwerte gespeichert werden, gehen natürlich Nachkommastellen verloren, und durch das Setzen des Wertebereichs auf 8, 9 oder 10 Bit entstehen ebenfalls Fehler, oftmals Quantisierungsfehler genannt, was falsch ist (richtig wäre eher DCT-Fehler, aber Rundungsfehler trifft's perfekt), denn wir haben ja noch gar nicht quantisiert.

Das machen wir jetzt mit der Matrix?

Die meisten Leser werden das obige Bild schon mal in TMPGEnc bemerkt haben. ;-)

Die Aufgabe einer solchen Matrix ist es, die Zelleninhalte möglichst zu homogenisieren, also einander angleichen (wie heißt dieser neue Film? "Was nicht passt, wird passend gemacht?". Ich denke, das trifft die Vorgänge ganz gut).

Dieses aneinander Angleichen ist wichtig, da im folgenden Schritt eine Kompressionsmethode angewendet wird (RLE), die darauf angewiesen ist, dass möglichst viele gleiche Werte hintereinander folgen.

Wie wir jetzt wissen, stehen zur Zeit die Zelleninhalte (Elemente) stellvertretend für die Komplexität des Blocks. Die Quantisierungs-Matrix selbst enthält Zahlen, die mit denen der Zelleninhalte verrechnet werden. Der Trick ist nun der, die Zahlen der Matrix so zu wählen, dass das gewünschte Ziel erreicht wird, nämlich möglichst viele Zellen auf gleiche Werte zu bringen. Richtig! Das Ziel ist nicht unbedingt, möglichst viele Zellen auf Null zu setzen, obwohl man das auch machen kann.

Was wir damit erreichen ist, dass die RLE-Codierung jetzt besser greift. Sie schaut einfach nach, ob mehrere gleiche Werte hintereinander folgen. Stehen am Ende der Quantisierung z.B. in vier Zellen nacheinander (welche das sind ist abhängig von der Scanorder, der Reihenfolge, in der die Zellen abgefragt werden) gleiche Werte, wir nehmen mal an, das sei die 8, dann werden nicht mehr vier Achten, sondern nur noch der Wert und die gefundene Anzahl gespeichert. Also statt 8,8,8,8 nur noch 4,8. Kann man viel Platz mit sparen. Das ist der positive Effekt der Quantisierung.

Natürlich hat die Sache auch einen Haken: Wir verändern damit auch die ursprünglichen Frequenzinformationen, die quasi "abgeschwächt" werden - und das lässt sich ab einem gewissen Grad der Quantisierung, nämlich dann, wenn dadurch zu viele Rundungsfehler entstehen, nicht mehr rückgängig machen!

Je brutaler dabei eine Matrix vorgeht, desto besser (es gibt Ausnahmen, deshalb existiert z.B. die CG-Matrix) kann komprimiert werden, desto mehr Frequenzanteile und damit auch wiederherstellbare Bildinformationen gehen aber auch unwiederbringlich verloren. Und das wollen wir nicht.

"Ja, aber hohe Frequenzen, das ist doch Rauschen, und das werden wir damit auch gleich los". War es dass, was viele jetzt einwenden wollten? Ja? Ich muss Euch enttäuschen, das stimmt nur zum Teil.

Erinnert Euch: Die DCT erstellt Interferenzmuster! Und zwar für jede Zelle basierend auf dem gesamten Block und eben nicht nur auf einer Frequenz oder einem bestimmten Frequenzband. Und schon gar nicht bezogen auf irgendeinen speziellen Pixel innerhalb des Blocks. Das hohe Quantisieren entfernt also das Rauschen nicht wirklich, sondern nimmt dem Bild selbst an Komplexität. Damit ist dass Rauschen nachher vielleicht nicht mehr ganz so stark sichtbar, es ist aber noch immer vorhanden!

OK, nachdem wir jetzt das Bild so stark versaut haben, fragt man sich doch bestimmt, wie man daraus dann doch wieder ein gutes Bild gewinnt, und dazu brauche ich die Steine, den Mathematiker und den See von eben.

Der Mathematiker versucht, aus den Wellenmustern (den Zelleninhalten), die er sieht, zu errechnen, was für Steine (unsere Pixel, die wollen wir ja irgendwann wiederhaben) wo ins Wasser (Position der Pixel) geworfen wurden. Dazu sind aber bei drei Steinen nur die Daten von zweien erforderlich, die Werte des dritten ergeben sich zwangsläufig aus denen der beiden ersten. Im Klartext: Er errechnet 2 Steinpostionen und sonstige Daten, sieht aber, dass da noch Wellen von einem dritten Stein sind. Aus den bisherigen Daten und dem, was man da sonst noch hat, lässt sich ableiten, was wann und wo dazu geführt hat. Nichts anderes tut später die Umkehrung der DCT, die iDCT. Jede Zelle des Blocks ist also einer unserer Steine (Pixel), bzw. die Information über einen solchen mit Bezugname auf alle anderen. Im Klartext: Jede Zelle ist eine der Wellen bzw. das Interferenzmuster mehrerer, die einer der Steine beim Aufschlag auf das Wasser erzeugt hat.

Zunächst wird mit Hilfe der hoffentlich im MPEG-Stream gespeicherten Matrix (ist sie nicht gespeichert, wird die Standardmatrix benutzt, war aber beim Encoden eine andere aktiv, entsteht dann Müll) der Quantisierungseffekt umgekehrt, was übrigens verlustfrei wäre, gäbe es nicht ein kleines Problem: Bei der Quantisierung entstehen Rundungsfehler und dadurch auch unbeabsichtigte Nullwerte, und das umso mehr, je stärker eine Matrix quantisiert.

Um das zu erklären, benutze ich jetzt mal Addition und Subtraktion, obwohl das mathematisch absolut falsch ist. Ich will damit nur zeigen, was Quantisierungsfehler überhaupt sind und wie sie sich auswirken. Nehmen wir also mal an, die ursprünglichen Zellenwerte nach der DCT seien (ausschnittsweise) folgende gewesen: 24, 16, 22, 23, 22, 11, die werden jetzt quantisiert (wie gesagt, wir subtrahieren einfach mal) und zwar mit den korrespondierenden Matrixwerten 22, 22, 22, 24, 24, 24. Am Ende kommt also das dabei heraus (negative Werte und solche mit Kommastellen gibt's dabei nicht): 2, 0, 0, 0, 0, 0. Jetzt drehen wir die Quantisierung mit der gleichen Matrix um: 24, 22, 22, 24, 24, 24, und das hat mit dem ursprünglichen Bild nicht mehr viel zu tun (lies sich aber prima komprimieren: "Hurra! Gar keine Blockbildung bei schnellen Bewegungen in meinem Video mehr, eine super Matrix", so sprach's der User. Darauf gähnte Kika und meinte lakonisch: "Stimmt, und das Bild ist auch so wunderbar unscharf! Und erst das Pumpen! Genial! Wie heißt der Künstler?") Anm. des Autors: Hat jemand den Witz verstanden?

OK, OK, in Wirklichkeit wird nicht einfach addiert und subtrahiert, außerdem geht in die Rückberechnung zu Pixeln auch nicht nur jeweils ein Zelleninhalt mit ein; all das weiß ich auch (immer diese Zwischenrufe, furchtbar *grins*), es zeigt aber, was passiert, wenn (zu) hoch quantisiert wird und warum dann eben kein vernünftiges Bild mehr erzeugt werden kann.

So, jetzt wissen wir also, wie die kleinste Bildeinheit bei MPEG, nämlich der Block, und außerdem die DCT und die Quantisierung (und damit die Matrix) funktioniert, zumindest grob. Daraus stellt sich dann die Frage: Was sollte eine gute Matrix tun?

Die Antwort ergibt sich aus den Erklärungen von selbst: Sie sollte möglichst viele Zelleninhalte in der richtigen Reihenfolge auf gleiche Werte setzen, es dabei aber tunlichst vermeiden, durch zu hohe Quantisierung zu viele Rundungsfehler (die Nullwerte aus dem Rechenbeispiel) als unbedingt nötig zu erzeugen. Und daraus ergibt sich noch etwas: Matrizen mit 99er Inhalten sind prima zum Komprimieren, aber sie führen zu starken Quantisierungsfehlern und unscharfen Bildern. Daher ist auch die interlaced Matrix von mb1 ein gutes Beispiel für eine gute Matrix: Sie beachtet die Scanorder (alternate, daher nur für interlaced brauchbar) und quantisiert auch nicht so hoch.

Natürlich gibt es auch einen Nachteil: Da diese Matrix nicht sehr hoch quantisiert, sinkt dadurch auch die Wahrscheinlichkeit, dass viele Zelleninhalte den gleichen Wert haben. Dann greift aber die RLE-Kompression nicht so gut und wir benötigen höhere Bitraten.

Aus dem bisher gesagten lässt sich aber noch etwas ableiten: Die Aussagekraft des Q-Levels beim beliebten Bitrateviewer ist mit Vorsicht zu genießen.

Denn ein hoher Level besagt nur, dass ein Block nach der Quantisierung viele gleiche Werte enthielt, und das kann auch des Ergebnis eines perfekten Zusammenspiels von Quantisierung und RLE-Kodierung bedeuten! Und das wiederum heißt, dass in einem solchen Fall zwar hoch quantisiert wurde, die Bildqualität aber auf dem höchsten möglichen Level war! Da aber kaum jemand wirklich versteht, was es mit dem Q-Level tatsächlich auf sich hat, lasse ich lieber die Finger von Interpretationsversuchen.

So richtig schlaue Köpfe, die verstanden haben, was ich hier schrieb (ich habe da selbst Probleme mit), könnten auf die Idee kommen zu sagen: "Hey, wenn das so ist, wie Kika schreibt, dann ist die optimale Matrix die, deren Zelleninhalte möglichst gleichmäßig ansteigen". Prima, wenn Ihr auf diese Idee gekommen seid, habt Ihr es verstanden, leider stimmt's nur nicht, denn da gibt es böse Fallen.

Kein Bild, und somit auch kein Block, hat einen geradlinigen Anstieg der Komplexität der Frequenzstruktur, vielmehr ist das Ganze ziemlich chaotisch verteilt. Bei Zeichentrickfilmen hingegen gibt es das, da funktioniert eine solche Matrix tatsächlich, aber eben NUR da. Trotzdem würde eine solche Matrix das beste Bild erzeugen, wäre da nicht die Obergrenze der erlaubten Bitrate, was übrigens für jede verwendete Matrix gilt. Und die bringt alle schönen Überlegungen durcheinander.

Reicht die Bitrate nämlich nicht mehr aus, um alle Informationen aufzunehmen, werden die Encoder ziemlich brutal: sie quantisieren viel höher als es die Matrix vorschreibt! Viele Leute nennen das Nachquantisierung (ich auch), was aber nur ein Hilfsbegriff ist. Wo und wie das tatsächlich stattfindet, das ist eines der bestgehütetsten Geheimnisse der Encoderprogrammierer, denn es entscheidet sehr stark über die erreichbare Bildqualität.

Dass es einen solchen Vorgang gibt, und dass die Encoder da unterschiedlich vorgehen, zeigt schon ein Vergleich von TMPGEnc und dem Cinemacraft-Encoder. Kommen die beiden in den Bereich, in dem die Bitrate nicht mehr genügt, reagieren sie unterschiedlich. Während TMPGEnc ziemlich schnell sichtbare Blöcke aber ein durchaus scharfes Bild erzeugt, treten beim CCE solche Blöcke sehr viel später auf, dafür wird allerdings das Bild unschärfer. Beide Encoder verfolgen hier also völlig verschiedene Strategien. Meine Vermutung diesbezüglich ist, dass TMPGEnc einzelne Blöcke stärker quantisiert, wärend CCE sich das gesamte Bild vorknöpft. Wie gesagt, ist das nur eine Vermutung, sie würde aber diesen Unterschied erklären.

Wer also selbst ein wenig mit Matrizen experimentieren möchte, der sollte dabei stets im Hinterkopf behalten, dass die Encoder da durchaus auch ihren eigenen „Willen“ haben. Die beste Matrix bringt also nichts, wenn man dem Encoder bzw. dem Video nicht die ausreichende Bitrate gönnt.

So, damit sind wir am Ende des ersten Teils angelangt. Vieles konnte nur stark vereinfacht erklärt werden, was auch in meiner Absicht lag. Wer das Ganze etwas detailliert haben möchte, kann auf folgenden Seiten vorbeisurfen:

Ach ja, eines bin ich Euch noch schuldig: die Erklärung des Begriffs "Scanorder".

Dabei geht man von der Theorie aus, dass nach der DCT und der Quantisierung zwei benachbarte Elemente gleiche Werte aufweisen. Benachbart muss man hier aber zweidimensional sehen. Gemeint sind damit nicht nebeneinanderliegende Werte innerhalb einer Zeile oder Spalte, sondern innerhalb eines gewissen Frequenzspektrums, deshalb wird beim Abfragen der Zelleninhalte im Zickzack-Muster vorgegangen, was der betreffenden Scanorder den netten Namen ZigZag eingebracht hat.

Bei Interlaced-Video benutzt man den sogenannten Alternate Scan. Auch er geht nach einem Zickzack-Muster vor, wenn auch einem, das auf den ersten Blick ziemlich chaotisch aussieht. Es trägt aber dem Bildaufbau bei einem auf Fields und nicht auf Frames basierenden Videoformat Rechnung.

Die beiden Möglichkeiten sieht man auf dem Bild ganz gut.

Links der ZigZag-, rechts der Alternate Scan

OK, nach so viel Theorie jetzt ein wenig Praxis. Wir alle wollen ja unsere Filme möglichst platzsparend und in möglichst hoher Qualität speichern.

An der Qualität können wir kaum etwas ändern, denn egal was wir tun, also egal welche Matrix wir benutzen, nach der Quantisierung kann das Bild nie wieder das sein, was es im Original war. Es wird immer etwas unschärfer und auch blasser. Was wir aber tun können, ist an der Kompressionsschraube drehen und Verblockung minimieren.

Dazu noch folgendes: Aus dem bisher Gesagten lässt sich ableiten, dass das ursprüngliche Bild auch dann noch rekonstruiert werden kann, wenn weniger Informationen zur Verfügung stehen, also komplette Frequenzbereiche entfernt werden. Je mehr Informationen wir also bei der Quantisierung wegwerfen, desto besser kann komprimiert werden. Wir bezahlen das mit einem Verlust an Bildschärfe und Farbbrillanz.

Eine Quantisierungsmatrix ist nämlich nichts anderes als ein Filter für Frequenzbereiche, und das kennen wir alle aus dem Audio-Bereich. Bei Musik-CDs ist die maximale Audiofrequenz 22 kHz, das menschliche Ohr kann so hohe Frequenzen aber gar nicht oder nur sehr schlecht wahrnehmen, was man sich bei der Audio-Komprimierung zunutze macht, und Frequenzen über 16 kHz einfach abschneidet. Genau das können wir auch mit der Matrix bei der MPEG-Komprimierung erreichen.

Eine Matrix besteht aus 8x8 Feldern. Von links nach rechts stehen ihre Element für immer höher werdende Horizontal-Frequenzen, von oben nach unten für die Vertikalfrequenzen.

Ein Tiefpassfilter, also einer, der niedrige Frequenzen durchlässt, hohe aber abschneidet, sähe als Matrix so aus (die rot gekennzeichneten Felder sind die veränderten Felder. Basis war die Standard-Einstellung von TMPGEnc Ver 2.53.35.130):

Abb: 1 (by S.U)

Bei dieser Matrix werden die hohen Frequenzanteile komplett weggeworfen.

Analog dazu würde ein Hochpassfilter also wie folgt aussehen:

Abb: 2 (by S.U)

Ein solcher Filter lässt die niedrigen Frequenzen im Nirwana verschwinden.

Die dritte Filterart, die es gibt, nämlich der Bandpass, lässt sich dann ebenfalls verwirklichen:

Abb: 3 (by S.U)

Er beschneidet alle Frequenzbereiche gleichmäßig, ohne einen zu bevorzugen. Kann durchaus auch Sinn machen, nämlich bei Bildern, die von sich aus nicht so komplex sind, beispielsweise Zeichentrickfilme (nicht computeranimierte! Unter TMPEG finden wir das in der Einstellung "CG/Animation" wieder).

Nun haben die meisten von Euch sicherlich schon mal Matrizen für hohe Kompression gesehen, und die sehen ganz anders aus. Richtig, dafür gibt es einen dummen Grund: Den Fernseher! Denn der hat eine deutlich sichtbare Zeilen- aber keine sichtbare Spaltenstruktur. Bei Monitoren ist das anders, da PCs nun mal pixelorientiert arbeiten, Fernseher tun das nicht, und dem muss man leider Rechnung tragen.

Beim Cinemacraft Encoder (CCE) gibt es z.B. eine Low-Bitrate-Matrix mit folgender Struktur (die "xx" zeigen und nur, dass hier keine Veränderung vorgenommen wurde):

Abb: 4 (by S.U)

Diese Matrix entfernt fast ausschließlich horizontale Frequenzen und lässt die vertikalen unberührt. Eine prima Sache, denn die Bildqualität leidet darunter nur sehr sehr wenig. Das liegt daran, dass das Fernsehbild zwar (digital gesehen) immer 576 Zeilen hat, die Horizontalauflösung aber in Linien gemessen wird, grob gesagt in Zeitabschnitten, und je nach Signalart ist die Auflösung horizontal sowieso niedriger.

Der CCE bietet auch die Möglichkeit, diese Matrix zu transponieren (rotieren), das sieht dann so aus:

Abb: 5 (by S.U)

Lustige Idee, denn das führt, da wir ja eine FESTE Vertikalauflösung haben, zu Linienstrukturen im Bild.

Das ist übrigens auch der Grund, warum der Tiefpassfilter oben zwar bei Bildern auf dem PC-Monitor hervorragend funktioniert (besser geht's nicht!), bei Videos für den Fernseher aber plötzlich scheinbar schlechter ist. Außerdem stimmt es nur in Teilen mit der Scanorder überein.

So, natürlich kennen die meisten auch Angels Matrix (vergl: http://www.uni-kassel.de/~eckhardm/hq.htm), die diagonal Werte auf 99 setzt. Was macht die denn dann genau? Sehen wir sie uns in einer einfachen Variante einmal an:

Abb: 6 (by S.U)

Tja, aus der Sicht der Frequenzspektren eine eher unglückliche Lösung, da sie in jeder Richtung nur den halben Weg geht und Spektren nur zum Teil entfernt.

Aber schaut Euch noch mal das Schaubild zur Scanorder an, dann seht Ihr sofort, was hier der Trick ist: Es werden nämlich Werte in genau der richtigen Reihenfolge hoch quantisiert, wodurch die RLE-Kompression hervorragend funktioniert. Problematisch ist eben, dass sie auch Vertikalfrequenzen entfernt, was wegen der erwähnten Zeilenstruktur des Fernsehbildes nicht sehr günstig ist. Wer aber mit der Scanorder tricksen will, hat keine andere Wahl.

Fast optimal wird die Sache, wenn wir zwei Matrizen kombinieren: Die Low Bitrate von CCE und die Angelmatrix, was dann so aussieht:

Abb: 7 (by S.U)

Die Horizontalfrequenzen werden stark beschnitten, die vertikalen ein wenig, und der untere Teil stimmt mit der Scanorder überein.

So, ich hoffe, dass an diesen Beispielen jetzt klar geworden ist, was Matrizen für hohe Komprimierung eigentlich tun.

Ersetzt die "xx" überall durch die Werte der Standard-Matrix der Encoder und spielt unter Beachtung dessen, was hier gesagt wurde, mit der Anordnung der 99er Werte, und schon könnt Ihr selbst experimentieren, bis die CPU qualmt.

Der Trick beim Erforschen von Optimierungsmöglichkeiten ist nun der, nicht nur die richtige Anordnung der Werte zu finden, sondern auch entsprechend günstige Werte. Die 99 wirft die Frequenzen ja komplett weg, was immer für Unschärfe sorgt, wenn man es aber schafft, die Werte so zu setzen, dass die Frequenzanteile erhalten bleiben, die RLE-Komprimierung aber dennoch gut greift, dann haben wir das Optimum...

Allerdings forschen daran schon seit vielen Jahren die Leute, ohne DIE Lösung gefunden zu haben. Und ab einer gewissen Bitrate machen Optimierungen zum Platzsparen auch nicht mehr viel Sinn, dann geht es plötzlich darum, möglichst scharfe Bilder zu erzeugen. Und in einer dazu gedachten Matrix kommt mit Sicherheit nirgends eine 99 vor ;)

Das waren jetzt alles Beispiele für die Intra-Matrix, die non-Intra habe ich bewusst außer Acht gelassen, denn da gelten zum Teil andere Regeln. Eine Regel ist dabei universell: Sie sollte nicht so hoch quantisierend sein wie die Intra-Matrix.

Außerdem sind alle hier vorgestellten Matrizen mit Ausnahme der drei Filter (Tief-, Band und Hochpass) nur bei progressiven Videos vernünftig einsetzbar, nicht bei Interlaced- Video.

Übrigens, wäre das mal eine gute Idee für Programmierer von AVISynth- und VirtualDub-Filtern: Ein frei einstellbarer Quantisierer! Und zwar einer, der abschwächen aber auch verstärken kann. Was wir dann hätten, wäre ein Equalizer für Bilder und Videos, und damit könnte man vieles tun...

Das war es aber jetzt wirklich. Der nächste Teil, der hoffentlich irgendwann mal fertig wird, dreht sich dann um das Thema: Motion Prediction und Estimation - Schiffeversenken unter erschwerten Bedingungen!

Euer,
Kika

P.S. Vielen Dank auch an shh, vielen sicherlich als Programmierer des Tools FitCD bekannt, der mir bei den etwas komplizierteren Teilen mit Rat und Tat zur Seite stand.

ViSdP: Kika, München

Weiterführende Infos - vergl: