VirtualDub-Filter zum Intra-Matrix-testen

[A. Dittrich]

Hallo,
da ich mich auch schon etwas länger mit den DCT-basierten Videokompressions-Verfahren auseinandersetze habe ich mir ein Virtualdub-Filter gestrickt um die Wirkung der verschiedenen Matrizen testen zu können und inwieweit eine geeignete Vorfilterung die Kompression begünstigt.
Der Filter macht im Prinzip nichts anderes als eine JPEG-Codierung/Decodierung und zeigt dabei noch ein paar statistische Kenngrößen wie Daten pro Pixel und die Effektivwerte der DCT-Koeffizienten an. Klar, sagt natürlich wenig darüber aus, wie sich die zeitliche Prädiktion bei MPEG auf die Kompression auswirkt, gilt halt nur für die INTRA-Frame Codierung.
Ich finds ganz nützlich und habe es daher hier ins Netz gestellt.

Dort gibt es außerdem noch zwei andere Filter zum spielen, die bei mir gute Dienste leisten und die ich auch anderen zur Verfügung stellen möchte. Insbesondere mit dem "2d comb"-Filter erziele ich gute Resultate.

Viel Spass damit,
Andreas



Zuletzt bearbeitet von A. Dittrich am Juni. 05 2002,19:25

[Kika]

Hey, das kommt dem, was ich mir vor kurzem gewünscht habe, schon ziemlich nahe. ;)
Wünschwenswert wäre imho für diejenigen, die noch nicht so fit sind damit, eine kurze Erklärung zu den Parametern.
Und zu der Sache mit dem Scale-Faktor: meinst Du damit den AC-Wert in der Intra-Matrix? Der ist zumindest bei TMPGEnc IMMER 8, lässt sich also nicht ändern.

Gruß,
Kika

[A. Dittrich]

Hi Kika!

>> Wünschwenswert wäre imho für diejenigen, die noch nicht so fit sind damit, eine kurze Erklärung zu den Parametern.
Wenn man Deinen Beitrag hier gelesen hat, sollte doch das meiste selbsterklärend sein, oder? Ohne einige Grundkentnisse wird man mit dem Filter wahrscheinlich ohnehin nicht viel anfangen können.
Aber ok - wenn ich etwas Zeit über habe, schreibe ich noch einige Erläuterungen.

>> Und zu der Sache mit dem Scale-Faktor: meinst Du damit den AC-Wert in der Intra-Matrix? Der ist zumindest bei TMPGEnc IMMER 8, lässt sich also nicht ändern

Der "quantizer scale factor" ist quasi die wichtigste Stellgröße, um die Qualität bzw. Datenrate zu beeinflussen. Im MPEG Datenstrom wird dieser Wert pro Slice (optional pro MB) angegeben. Bei meinem Filter hab ich das so implementiert:
Dieser Faktor multipliziert mit den Matrix-Koeffizienten, geteilt durch 8 ergibt die Schrittweite des Quantisierers für die DCT-Koeffizienten.
Das werde ich aber noch ändern, um Standardkonform zu werden, denn dort ist dieser Faktor "quantizer_scale" geringfügig anders definiert.
Ach ja, zum DC-Koeffizient in der Matrix (links oben). Dieser hat bei mir (und auch bei MPEG Intra Frames) keinen Einfluss. Hierfür ist nur die Einstellung der DC-precision verantwortlich.

Gruss,
Andreas

[Kika]

Hallo Andreas,

alles klar, jetzt weiß ich, was genau gemeint war.
Hat übrigens auch gleich noch eine kleine, aber nicht unwesentliche Wissenslücke gefüllt, danke. ;)

> Wenn man Deinen Beitrag hier gelesen hat...

Tjaaaa, ich habe absichtlich versucht, ein einfaches, leicht verständliches Level für die Beschreibung zu wählen (hat mir auch Kritik eingebracht), trotzdem gab's etliche Rückfragen, sooo ganz verständlich isser also wohl leider doch nicht geworden, was auch einer der Gründe dafür ist, dass der zeite Teil immer noch fehlt - den will ich besser machen.

Gruß,
Kika

[ANDREAS]

Hallo Andreas,

ich verstehe Deinen Filter so, das ich mit ihm eine Mpeg Codierung simulieren kann, inklusive der Ergebnisse für die einzlenen "Frequenzen". Das von eimen AVI. Richtig?

Gruß
ANDREAS

[shh]

> Der "quantizer scale factor"

Du hast einen foat-qsf implementiert, richtig? Also einen "non-linear quantisizer" von MPEG2?

> Ach ja, zum DC-Koeffizient in der Matrix (links oben). Dieser hat bei mir (und auch bei MPEG Intra Frames) keinen Einfluss. Hierfür ist nur die Einstellung der DC-precision verantwortlich.

Ist das so MPEG-konform?
Ich meine, ist die DC-precision nur für den DC-Koeffizient zuständig und alle anderen AC-Koeffizienten haben 8bit Genauigkeit?

> Der "quantizer scale factor" ist quasi die wichtigste Stellgröße

Ist dir bekannt, wie die gängigen encoder das handhaben?
Dieser Wert (pro slice oder pro macroblock) scheint ja von den encodern offenbar dazu verwendet zu werden, eine eingestellte bitrate zu erreichen. (Hohe qs-Werte => niedrige bitrate)
Wie machen die wirklich guten encoder das scaling, um gute Qualität zu erreichen?
Ich vermute, daß die guten nicht nur per macroblock-scaling verwenden, sondern noch zusätzliche Methoden verwenden: zB zufälliges Weglassen einiger [hochfrequenter] AC-Koeffizienten. Abwegig?
Weißt du auswendig, wieviel bits zusätzlich pro macroblock draufgehen, wenn so ein per-macroblock scale-Wert eingesetzt wird?

Was bedeutet eigentlich das "RMS"? Das hat doch nichts mit dem GNU-Guru zu tun, oder? ;)

Exzellente Arbeit übrigens!!
Das wird etliche Tests mit Matrizen vereinfachen.

Mein Spezialwunsch:
Könnte man deinen Filter dahingehend erweitern, ein log über die Häufigkeit der AC-Koeffizienten eines ganzen Filmstücks zu erstellen?
Mein langjäriger Wunsch ist es endlich eine Analyse darüber zu bekommen, welche Koeffizienten wirklich wichtig sind, und welche wegrationalisiert werden können.
Zumindest für die I-frames wäre so eine Analyse sehr hilfreich.

Schönen Gruß
shh

NACHTRAG:
Ach ja, die bits/pixel-Angaben sind doch ohne VLE und Huffman-encoding, richtig? Wie sind die Werte zu verstehen?
Hmm, die kann ich dann wohl nicht auf meine bisherigen bits/block eines fertigen streams umsetzen...
_________________
shh >>> shh's MPEG-tools

[A. Dittrich]

@ ANDREAS
>> ich verstehe Deinen Filter so, das ich mit ihm eine Mpeg Codierung simulieren kann, inklusive der Ergebnisse für die einzlenen "Frequenzen". Das von eimen AVI. Richtig?

yepp, allerdings nur MPEG-Intra-Frames

@shh
>> Du hast einen foat-qsf implementiert, richtig? Also einen "non-linear quantisizer" von MPEG2?

als Eingabe float. Daraus wird bei mir dann die Schrittweite für einen linearen Quantisierer so berechnet: step(x,y) = round( qscale*W(x,y)/8 ), mit den Matrixeinträgen W(x,y).
Bei MPEG wird ein Wert namens "quantizer_scale_code" verwendet, der die Werte 1,2 .. 31 annehmen kann. Davon widerum wird der Wert "quantizer_scale" abgeleitet, wobei für die Zuordnungsfunktion quantizer_scale = f(quantizer_scale_code) zwei Möglichkeiten vorgesehen sind: linear und nichtlinear. Der Wert "quantizer_scale" wird im Prinzip genauso wie bei mir benutzt, d.h. als Skalierungsfaktor für die Quantisierungsmatrix. Die Quantisierung selbst ist aber IMHO immer linear (mit Ausnahme einer Totzone bei 0).

>> Ist das so MPEG-konform?
Ich meine, ist die DC-precision nur für den DC-Koeffizient zuständig und alle anderen AC-Koeffizienten haben 8bit Genauigkeit?

In der Tat nimmt der Intra-DC-Koeffizient eine Sonderstellung ein und wird je nach Wert von "intra_dc_precision" mit 8,9,10 oder 11 bit quantisiert. Alle anderen Koeffizienten werden gemäß der Quantisierungsmatrix und des Scale-Faktors quantisiert - könnten dann theoretisch aber auch bis zu 12 bit Auflösung haben. Der Standard geht glaube ich von einer 9 bit Genauigkeit vor der DCT bzw. nach der IDCT aus, und von 12 bit nach der DCT.
Ob jetzt allerdings der Wert DC-precision bei TMPGENC mit "intra_dc_precision" übereinstimmt, weiß ich nicht.

>> Wie machen die wirklich guten encoder das scaling, um gute Qualität zu erreichen?

Das ist wohl das am besten gehütete Geheimnis der Encoder.

>> Ich vermute, daß die guten nicht nur per macroblock-scaling verwenden, sondern noch zusätzliche Methoden verwenden: zB zufälliges Weglassen einiger [hochfrequenter] AC-Koeffizienten. Abwegig?

Alles denkbar. Möglich wären auch 1. Quantisieren, 2. IDCT, 3. Berechnung eines Visuellen Qualitätsmasses/Artefakterkennung und danach 4. erneutes Quantisieren mit besserer Schrittweite. Außerdem die Bitverteilung auf I, P, B Frames. Vieleicht auch eine adaptive Vorfilterung.

>> Weißt du auswendig, wieviel bits zusätzlich pro macroblock draufgehen, wenn so ein per-macroblock scale-Wert eingesetzt wird?

Auswendig nicht, aber ich habe noch mal nachgeschaut: 5 bit  (fixed length coded)

>> Was bedeutet eigentlich das "RMS"? Das hat doch nichts mit dem GNU-Guru zu tun, oder?

RMS = Root Mean Square, also Wurzel der mittleren Quadrate = Standardabweichung, oder auch Effektivwert. Bei einer Normalverteilung (siehe 10 Mark Schein ;)) entspricht das genau dem sigma.

>> Mein Spezialwunsch:
Könnte man deinen Filter dahingehend erweitern, ein log über die Häufigkeit der AC-Koeffizienten eines ganzen Filmstücks zu erstellen?

Hab es oben auf die ToDo-Liste gestellt. Meinst du mit Häufigkeit der AC-Koeffizienten ein Histogramm pro Koeffizient?

>> Mein langjäriger Wunsch ist es endlich eine Analyse darüber zu bekommen, welche Koeffizienten wirklich wichtig sind, und welche wegrationalisiert werden können.

Hmmm, ich dachte die Quantisierung soll sich danach richten, wie sehr das Auge (oder Gehirn) auf das "wegrationalisieren" reagiert, und nicht danach welche statistischen Eigenschaften das Bild selbst hat? Da wisst Ihr aber sicher mehr darüber.

>> Ach ja, die bits/pixel-Angaben sind doch ohne VLE und Huffman-encoding, richtig? Wie sind die Werte zu verstehen?
Hmm, die kann ich dann wohl nicht auf meine bisherigen bits/block eines fertigen streams umsetzen...

Mit VLE, allerdings so, wie es bei JPEG gemacht wird. Huffman habe ich mir allerdings erspart und statt dessen die Entropie geschätzt, d.h. dass, was man mit Huffman bestenfalls erreichen könnte. Und alles ohne Overhead. Somit ist diese Angabe eher etwas zu klein. Die Werte erschienen mir in meinen Tests plausibel - hab es aber noch nicht  systematisch mit einer echten JPEG-Komprimierung verglichen.

Gruss,
Andreas

[shh]

Danke für die Antworten! (Schön, mal wieder einen Spezialisten ausquetschen zu können )

> Die Quantisierung selbst ist aber IMHO immer linear

Hmm, ja. Ich glaube mich nur daran zu erinnern, daß bei einer Quantisierungsart mit dem quantizer_scale_code in einer Tabelle nachgeschaut wird, um dann den echten Quantisierungsfaktor zu bekommen (Tabelle ist nicht linear). Kann mich auch täuschen.

>>> [...] wieviel bits zusätzlich pro macroblock draufgehen, >Auswendig nicht, aber ich habe noch mal nachgeschaut: 5 bit  (fixed length coded)

Danke.
Hmm, grob geschätzt müßte sich dann so eine pro-macroblock-Quantisierung auf jeden Fall rentieren.

>> Häufigkeit der AC-Koeffizienten
> ein Histogramm pro Koeffizient

Genau. Sowas wäre perfekt.
Ich weiß, daß man sich auf so eine Statistik nicht besonders verlassen kann, zumal man ja auch bewegte Bilder hat und nur ein Bruchteil des Films aus intra coded blocks besteht. Man hätte aber wenigstens etwas in der Hand.
Vielleicht kann man so auch Film(material)-spezifische Probleme des Quellmaterials ausmachen (Körnung, Rauschen etc), um dann mit entsprechenden Matrizen entgegenwirken zu können.
Man hätte auch einen besseren Ansatzpunkt wo man überhaupt grob an den Matrizen rumwursteln muß, um einen einen evtl positiven Effekt zu erzielen. Bisher geht daß ja nur Pi*Daumen mit der Vermutung daß Koeffizient(7,7) reines Rauschen darstellt, die "rechts-unten"-Koeffizienten meistens "unnötig" sind..... und erfordert unzählige [sinnlose] Tests.

> VLE, Huffman usw

Mit dem RMS also trotzdem sehr schöne Werte mit dem ich/man was anfangen kann.

> 1. Quantisieren, 2. IDCT, 3. Berechnung eines Visuellen Qualitätsmasses/Artefakterkennung und danach 4. erneutes Quantisieren mit besserer Schrittweite

Hmm. Warscheinlich wird gleich beim Quantisieren schon der Fehler festgestellt und notiert. Abschließend wird eine Analyse gemacht, "wie gut" es denn geworden ist. Dann wird (spätestens beim 2pass) entschieden, welche blocks wie quantisiert werden... usw.
Bei den delta-frames wird so eine Analyse warscheinlich extrem kompliziert (kommt ja die motion-compensation, prediction und deren Kombination dazu). Die müssen da etliche gute Informatiker/Mathematiker im Entwicklungsteam haben, die sowas vernüftig abschätzen können, damit der stream effektiv komprimiert wird. :0

Dank nochmal
shh
_________________
shh >>> shh's MPEG-tools

[A. Dittrich]

Hallo,

dieser Thread ist zwar schon uralt aber ich hoffe es nimmt mir keiner übel dass ich den jetzt wieder hervorhole   .

Also zur Sache:
Endlich hatte ich mal wieder ein wenig Zeit etwas produktiv zu sein und habe den DCT-Q-IDCT Filter etwas überarbeitet.
Hier die größten Änderungen:

1.) Es wird jetzt wirklich MPEG2 codiert/decodiert (nur I-Frames).
Damit sollte die angegebene Speichergröße ein guter Richtwert für Versuche sein.

2.) Man kann ein Histogramm ausgeben lassen wie shh es damals angeregt hatte

3.) Auf der zugehörigen Homepage hier sind die ganzen Optionen hoffentlich genug genug beschrieben (mit Screenshots).
Ist alles in Englisch, da ich keine Lust hatte alles zweimal zu schreiben, ist aber hoffentlich kein Problem für die meisten.


Für Anregungen, Erfahrungsberichte, Bug-Reports etc. wäre ich echt dankbar.

Gruß,
Andreas