Email von Jim Quinlan, Multimedia & Intel(r) Xscale(tm), Intel Corporation
Hallo, Tom, Hier ist in Kürze das, was ich weiß. Wenn es möglich ist, sollten Sie Ihre Bekanntheit nutzen, um FlasKMPEG ein wenig festnageln und einige Fragen stellen, so dass Sie Antworten bekommen, vielleicht sogar Teile des Quellcodes. Ich werde versuchen, herauszubekommen, warum hier FP verwendet wird, aber ich denke, dass hier ein wenig detailliertere Nachforschungen erforderlich sind um Ihre Folgerungen zu untermauern. Ich bin das ganze Wochenende verfügbar, sollten Sie Weiteres wissen wollen. Zunächst kurz etwas zum Video-Kodierungsvorgang. Die meisten dieser Vorgänge sind ähnlich (MPEG1, MPEG2, MPEG3) darin dass ihre Basis auf 8x8 (i)DCT Blocks mit Bewegungskontrolle (motion control). MPEG4 verfügt über neuartige Technologie, die oft aber nicht aktiviert wird, da sie massive Rechenleistung braucht und ebenso eine gute Dekodierungsinfrastruktur. Es ist nun möglich, dass FlasK MPEG eines dieser Features aktiviert und durch die Verwendung von FP an optischer Qualität gewinnt, aber so sieht es ja momentan nicht aus. Die Spezifikationen von MPEG4, die gerade vor mir liegen, sagen im Anhang A, dass es gemäß des Standards von IDCT 1180-1190 notwendig ist, jedoch nicht ausreichend. Dort steht, dass man dies befolgen soll und "die Präzision wird ausreichend sein so dass keine signifikanten Fehler im Endergebnis auftreten..." Nun beinhaltet der Videokodierungsprozess einen Dekoder, der als Feedback verwendet wird: Der Sinn dieses Dekoders ist es, den tatsächlichen (angenommenen) Dekoder zu simulieren (mit dessen Schwächen), so dass der Kodierer einen bekannten Fehlerwert vorliegen hat, den er bei der Kodierung des nächsten erwarteten Frames zugrunde legen kann. Das Standarddiagramm dieses Modells können Sie aus jedem Einführungstext zu MPEG ersehen. Der zentrale Punkt ist der, dass der Kodierer die Fehlergröße des Dekoders weiß und ihn kompensieren kann, wie es gerade erforderlich ist. Etwas genauer: Der Dekodierer nimmt einen 8x8 Pixel großen Block und lässt ihn durch ein DCT laufen. Danach quantifiziert er die sich ergebenden Frequenzkoeffizienten. Das Ausmaß an Quantifizierung ist abhängig von den Entscheidungen bezüglich Qualität und Bandbreite, die der Kodierer vornimmt. Dieser Quantisierungsprozess schneidet kleine Teile weg, was ja Bestandteil des Komprimierungsprozesses ist. Jetzt tritt der interne Dekoder des Kodierers in Kraft. Bevor er diese Koeffizienten zum Huffmann-ähnlichen Kompressor (VLC) schickt, nimmt er eben diese quantifizierten Koeffizienten und schickt sie durch ein iDCT. Das einzige, was vom iDCT des Dekoders gefordert ist, ist, dass die IEEE-Standards eingehalten werden. Und da genau wundere ich mich über die FR-iDCT-Optionen: wie kann man in einem iDCT-Dekodierungsprozess zusätzliche Präzision gewinnen, wenn der Kodierer bereits angenommen hat, dass der Dekoder nur die IEEE-Präzisions-Standards einhält? Es kann sein, dass es da einige besondere Voraussetzungen gibt, welche die DVD-Leute hier machen, aber wenn dem so ist, dann sind diese über dem MPEG2-Standard. Wenn er vorher berechnet, was oder Dekoder berechnen wird, kann der Kodierer (1) entscheiden, ob der Fehler akzeptabel für den aktuellen Frame akzeptabel ist, und (2) und einen Fehler behalten, der für die Dekodierung des nächsten Frames verwendet und kompensiert wird. Wenn (1) nicht funktioniert, dann versucht sich der Kodieren mit geringerer Quantifizierung erneut, bis er mit dem Fehler der Kompression des aktuellen Frames zufrieden ist. Der kumulative Fehler bei (2) kann nicht kompensiert werden und gerät außer Kontrolle oder außerhalb des Determinismus des Kodierers... Naja, ich bin zugegebener Maßen nicht allzu bewandert mit dem Ripping-Prozess bei DVDs. Aber hier ist meine Vermutung, was dabei passiert: (1) der DVD-Inhalt wird entschlüsselt (2) Auswahl und Entpacken des gewünschten Audio- und Videomaterials (3) Völlige MPEG2-Dekodierung (4) MPEG 1/2/4-Kodierung von Schritt 3 Ich vermute, dass (3) und (4) gemacht werden müssen, da der Anwender die Bitrate ja reduzieren will (d.h. die Kompression erhöhen) oder das Dateiformat von (2) verändern will, so dass es auf einen PC oder was auch immer passt, so wie, wie eben auch bei MP3. Ich bin mir nun nicht ganz sicher, ob FlasKMPEG die Schritte 3 und 4 ganz durchführt, es sein denn sie haben einen besseren Weg gefunden, mit dem die Umwandlung mit FP profitiert. Das ist möglich, aber ich glaube eigentlich nicht, dass sie schon auf diesen Niveau sind, da dies ein relativ neues Verfahren ist, und nicht ganz einfach anzugehen. Deshalb denke ich, dass Sie (Tom's Hardware) FlasKMPEG in Ihre Analyse einbeziehen sollten. Die alleine wissen, was in ihrem Ripper vor sich geht (ich glaube nicht, dass sie Open-Source sind, sollte ich mich da irren, lassen sie es mich wissen und ich sehe mir ihren Code gleich an). Das FlasK MPEG-Dokument im Internet sagt dies über iDCT: "Im Moment hat FlasK MPEG drei Algorithmen um iDCT durchzuführen, alle entsprechen IEEE-1180. Einen mit MMX, einen, der ganzzahlbasiert ist und einer, der Fließkomma-Zahlen verwendet. Wenngleich alle IEEE entsprechen, ist der mit der Verwendung der Fließkommata der genauere, braucht aber eine Menge an Prozessor-Zeit. Der ganzzahlbasierte sollte für beinahe alle ohne MMX ausreichen und der MMX iDCT dürfte die Standard-Option für beinahe alle sein." Dieses Statement ist wahrscheinlich der Grund, warum wir beide noch nicht im Bett sind. Es macht ja die Aussage, dass FlasK MPEG eine FP-Version hat, die "genauere" ist. Es ist möglich, dass sie FP-Version die "genauere" ist, aber das muss nicht heißen, dass sie Leute, welche die ursprungliche DVD-Kodierung gemacht haben, auch annehmen, dass die Dekodierung mit einem ganzzahlbasierten iDCT gemacht wird (ich weiß leider nicht, welche Hardware in einem typischen DVD-Spieler ist, und auch nicht, ob es da grobe Richtlinien gibt. Auf ihrer Benutzeroberfläche (auf ihrer Website) bieten sie dem Anwender drei Möglichkeiten an: "MMx IDCT (fastest), non-MMx fast IDCT, IEEE-1180 reference quality IDCT (Slowest)". Diese Auswahlmöglichkeiten erscheinen komisch; sie stimmen nicht mit den Aussagen von vorher überein, obwohl es nicht ungewöhnlich ist, dass die graphische Benutzeroberfläche nicht mit den zugrundeliegenden Codes übereinstimmt. Es könnte sein, dass FlasK MPEG empirische und qualitative Daten hat, dass dieses FP iDCT wirklich ein großer Gewinn ist. Oder es könnte ähnlich dem Unterschied beim MP3-Rippen sein zwischen @192 und @168. Oder es gibt gar keinen Unterschied. Wenn Sie nun eine ganzzahlbasierte und eine FP-Version gerippt haben und einen Sichttest durchgeführt (mit all der vernünftigen wissenschaftlichen Grundlage) und Sie herausgefunden haben, dass es tatsächlich einen signifikanten Unterschied gibt, dass haben Sie und Toby hier wirklich Recht. Aber ich habe noch nichts gesehen, was dies wirklich unterstützt. Wäre ich Sie, dann wäre ich hier wirklich nachdrücklich und würde Flask MPEG bitten, Ihnen die MMx iDCT-Source zu geben so dass Sie sicherstellen können, dass sie die IEEE-Version verwenden und nicht die nicht standardgemäße IEEE "Aan"-Version. Ich sage das deswegen, weil ich schon gesehen habe, dass Leute der Meinung sind, dass man die MMx-Aan-Version in eine MMx-IEEE-Version verwandelt kann, indem man einfach die Wandelungskoeffizienten austauscht; aber das ist ein riesiger Irrtum. Wenngleich ich vermute, dass die Jungs bei FlasK viel zu clever sind, um einen solchen Fehler zu machen, tut es doch nicht weh, diese Dinge zu bestätigen, wenn man mehr als 1 Million Hits auf seiner Seite hat. Wenn Sie möchten, kann ich mir gerne den MMx-iDCT-Code ansehen und eine Einschätzung bezüglich dessen abgeben, inwiefern er IEEE entspricht. Prima, dass ich etwas beizutragen wusste und: Weiter so mit Ihrer guten Arbeit! Jim Quinlan, |