IEEE oder MMX?

Tom's Hardware Guide hat vor einiger Zeit Intels neuen Pentium 4 Prozessor getestet, unter anderem mit FlaskMpeg und seine Ergebnisse zeigten, daß der P4 eine signifikant bessere Leistung zeigte als jeder AMD Prozessor. Ein Leser schlug vor den IEEE-1180 iDCT (inverse discrete cosine transformation) anstatt des standard MMX iDCT für den Test zu benutzen. Tom schob einen zweiten Test nach und diesmal war das Fazit ein anderes. Aufgrund der überlegenen Fließkommaeinheit des Athlons schnitt die Intel CPU erstaunlich schlecht ab. Tatsächlich konnte der 300MHz schnellere P4 keinem einzigen der getesteten Athlons Paroli bieten.

Sofort nach erscheinen des Artikels begann die Gerüchteküche in der Ripping Szene zu brodeln. Die Leute fragten sich, ob sie die ganze Zeit mit dem MMX iDCT falsch lagen, vor allem da dieser von allen bekannten FlaskMpeg Anleitungen empfohlen wurde. Dies schrie förmlich danach eine Reihe von eigenen Tests durchzuführen.

Test Aufbau

Im Gegensatz zu Tom werde ich alle Details meiner Tests aufführen, um meine Tests wiederholbar und die Resultate verifizierbar zu machen.

Ich habe jeweils einzeln Kapitel 28-30 der DVD "The Matrix" mit Smartripper gerippt. Kapitel 28 ist die Befragung von Morpheus im Polizeigebäude; an den grauen Wänden gibt es viele unruhige Details und es ist offensichtlich eine Low-Motion Szene. Kapitel 29 ist der Kampf in der Empfangshalle und wahrscheinlich die berühmteste Szene des Films. Diese Szene besteht aus schneller Action und fordert den Codec erheblich. Kapitel 30 beinhaltet den Kampf auf dem Dach und die Explosion des Fahrstuhls - die schwierigste Szene im gesamten Film.

Es wurden drei Tests mit folgenden Einstellungen durchgeführt:

Alle Tests wurden mir FlaskMpeg 0.594 unter Verwendung des AVI Output Plugin 0.591 und dem DivX 0.311alpha Low-Motion Codec durchgeführt. Crispness ist auf 100 eingestellt. Der Algorithmus zur Größenanpassung in FlaskMpeg war HQ bicubic, die Bearbeitung der Audiospur war abgeschaltet. Jeder Test wurde zweimal durchgeführt, einmal mit dem MMX iDCT und einmal mit dem IEEE-1180 Referenz iDCT.

Die Ergebnisse

Zuerst einen Blick in die FlaskMpeg Dokumentation. Darin steht:

"Die Videoinformation innerhalb der MPEG Dateien wird statt räumlich (die Bilder die wir sehen) im Frequenzbereich gespeichert. Auf diese Art wird die Information verdichtet und danach komprimiert (reduziert). MPEG benutzt dafür den DCT (Discrete Cosine Transform = Diskrete Cosinus Transformation) um die räumliche Information in den Frequenzbereich zu übertragen. Um diese räumliche Information wieder aus dem MPEG Stream zu extrahieren kommt der iDCT zur Anwendung, der Inverse Discrete Cosine Transform (umgekehrte DCT), also der DCT, der während des Komprimierens benutzt wurde.

Obwohl MPEG nahezu deterministisch ist (die Ausgabe des MPEG Streams sollte mit allen Dekodern identisch sein), erlaubt dieser Standard einen bestimmten Spielraum bei der Wahl des iDCT. Auf diese Weise kann der Dekoder abhängig von der zugrundeliegenden Hardware weit einfacher implementiert werden. Der Standard schreibt dem Dekoder nur vor, daß der iDCT die IEEE-1180 Spezifikationen erfüllen muß, oder einfacher ausgedrückt, daß der Fehler des iDCT nicht über den vorgeschriebenen Wert der IEEE-1180 Spezifikation hinausgeht.

Zur Zeit hat FlasK MPEG drei iDCT Algorithmen, alle IEEE-1180 konform. Ein MMX Algorithmus, einer auf Ganzzahlen und einer auf Fließkommazahlen basierend. Auch wenn alle dem IEEE Standard entsprechen, ist letzterer genauer, kostet aber wesentlich mehr CPU Zeit. Der Ganzzahlenalgorithmus sollte für diejenigen ohne MMX ausreichen, der MMX iDCT sollte für alle anderen standardmäßig eingestellt sein. "

Mit anderen Worten: Alle drei Algorithmen sind IEEE-1180 konform und Flasky selbst rät zum Einsatz des MMX iDCT.

So weit so gut...

Der Geschwindigkeitsunterschied war recht markant: Den 1800kbit/s Clip kodierte FlaskMpeg mit 6.82 Bildern pro Sekunde auf meinem P3-550 Rechner wohingegen der selbe Clip unter Einsatz des Reference Quality iDCT auf 2.08fps absank. Rechtfertigt der Qualitätsunterschied wirklich den höheren Zeitaufwand?

mmx idtc

ieee reference

So, welcher ist welcher? Das ist die große Frage. Fährt man mit dem Mauszeiger über eines der Bilder wird der jeweils benutzte Algorithmus eingeblendet. Hier sind zwei weitere Screenshots, die die rot markierten Ausschnitte größer zeigen.

mmx idctieee reference

Schwer zu sagen, welcher nun welcher ist, richtig? Ich muß hinzufügen, daß die Wand des Ausgangsclips nicht wenige Störungen in der Textur aufweißt. Das ist der Grund für die große Anzahl Makroblocks. Selbst mit höheren Bitraten bleiben einige der Blöcke bestehen. Das ist eben die Art und Weise wie DivX das Bild komprimiert. Ich habe ebenfalls TMPG im 2pass Mode getestet und hier wurden die Störungen ohne Blockcharakter wieder hergestellt. Letztlich ist es Geschmacksache und deswegen gehe ich zu den nächsten Screenshots über:

ieee reference

mmx idct

ieee referencemmx idct

Handelt es sich hier nicht um ein und die selben Bilder? Ich kann nur versichern, daß dies nicht der Fall ist. Eine der Datein brauchte beim Kodieren sogar dreimal länger.

Die Explosionsszene ein paar Sekunden später:

mmx idct

ieee reference

Und die herangezoomte Version:

mmx idctieee reference

Um die Sache abzurunden noch eine weitere Screenshot Serie:

mmx idct

ieee referencemmx idct

 

Fazit

Man dürfte sich nun allmählich fragen, worum es hier eigentlich geht. Nun... Genau darauf will ich hinaus.

Ich habe mir diese Clips nun einige Male angesehen und ich sehe keine merklichen Unterschiede. Selbstredend, daß ich mir die Clips in einem dunklen Zimmer und ohne Sound angesehen habe. Zudem skalierte ich die Ausschnitte auf Vollbild Auflösung (1152x864), um etwaige Fehler einfacher ausmachen zu können. Durch meine vorhergehenden Tests und durch meine Bitraten Tipps dürfte bekannt sein, daß ich keine Kompromisse in puncto Qualität eingehe. In diesem Fall habe ich mich sehr angestrengt irgendeinen Unterschied ausfindig zu machen, aber erfolglos.

Wie man den Screenshots entnehmen kann ist der Unterschied zwischen MMX iDCT und IEEE-1180 reference iDCT nicht feststellbar. Weder bei 1500kbit/s Clips, von denen die Screenshots sind, noch bei niedrigeren oder höheren Bitraten.

Auf Toms Hardware Guide Seite steht:

"Jedoch besteht die Tendenz viele Artefkate im fertigen MPEG-4 Video zu erzeugen, da alle Pixelwerte der dekodierten Frames nur Annäherungen sind. Die zweite DCT Umwandlung in MPEG-4 nähert wieder nur an und produziert so in einigen Fällen sehr störende Artefakte.

Der IEEE Algorithmus elminiert die meisten davon und erzeugt eine Ausgabe die mit den meisten DVDs konkurrieren kann, selbst wenn man diese auf 20% der ursprünglichen Bitrate setzen würde. (1.5mbps statt einem 7.5mbps DVD wie Matrix)."

Das ist genau das, was ich getan habe.. Ich habe Matrix mit 1500kbit/s komprimiert. Und doch: ES GIBT KEINEN UNTERSCHIED. Meine Augen sind noch immer sehr gut und man darf mir glauben, daß ich Kodierungsfehler auch dann entdecke, wenn andere versichern, daß es keinen Makel gibt. Aber in diesem Fall hatte der IEEE Referenzalgorithmus kein sichtbares Ergbenis, nur zeitlich einen dreimal höheren Kompressionsaufwand.

Man kann also wieder ruhig schlafen ohne das Gefühl, die gesamte DVD Sammlung erneut komprimieren zu müssen oder einen 1.2GHz Athlon zu kaufen, nur um in der Lage zu sein mit lausigen 6fps zu kodieren.

Was man Toms Artikel lediglich entnehmen kann: AMD hat eine wesentlich bessere FPU als Intel. Vielleicht wirkt sich das auf MPEG-2 Kompression aus, sicherlich aber nicht auf MPEG-4. Ich glaube der Reference Quality iDCT ist schlicht von der Referenzimplementation der MPEG Software Simulation Group abgeleitet. Gewöhnlich sind diese Implementationen sehr gut in Bezug auf Qualität aber leiden meist unter der niedrigen Geschwindigkeit. Ein Software DVD Player, der den Referenz iDCT benutzt, würde jeden Film zu einer langwierigen Einzelbildschau degradieren. Alle brauchbaren iDCT Algorithmen sind mindestens MMX optimiert - was nicht bedeutet, daß die Umsetzung in FlaskMpeg die beste ist... mit Sicherheit gibt es bessere.

Auch sollte man bedenken, daß sich in Toms ersten Artikel einige grobe Fehler befanden. Blight - www.inmatrix.com - wieß auf die meisten hin. Among these was the suggestion to use next neighbor resizing which results in really bad encoding. That has been amended since but they still write that for small filesize you should use that kind of filtering. Aber man darf mir glauben, man will es nicht einsetzen, es sieht schrecklich aus. Und ich glaube kaum, daß irgendein IEEE Referenzalgorithmus diese zerstörerische Art des Filterns wieder reparieren kann.


Last edited on: 06/30/2002 (no correction) | German translation by: mne | Content by Doom9.net - The definitive DVD backup resource