Welchen iDCT Mode wählen?

P4? Ja, was überlegst du da noch lange? SSE2 natürlich! Der ist am schnellsten für deine CPU.

Unterschiede kann man eventuell messen - aber bestimmt nicht sehen.

Ich hatte auch mal verglichen. Mein Ergebnis war:

http://www.ligh.de/privhome/iDCT-Vergleich.htm

Du siehst: (1) MMX, (2) SSE/MMX und (5) SSE2/MMX sind bitidentisch (auf einem P4), und die anderen weichen auch nur marginal ab. Lediglich der (4) "Referenz" war kaputt-optimiert, und völlig verkorkst.

Danke für den Link, muss noch mal schauen, ob ich da noch mal was beitragen kann.

Eine Frage dazu:

Kann man eigentlich den Geschwindigkeitunterschied der verschiedenen iDCT-Algos messen (ausser mit einer Stoppuhr, z.B. mit einem Avisynthbefehl oder ähnlichem)?

Nur mit einer Stoppuhr, sonst gar nicht.

Das Programm AVS2AVI (wird an der Kommandozeile aufgerufen) sollte dafür brauchbar sein.

Hi,

welcher Modus is den für nen 64er Athlon der richtige?

Ich sehe da überhaupt nicht durch

Pacman

Ich würde mal annehmen auch SSE2/MMX, wobei sich da LigH besser auskennt.
Wenn Du nicht weißt, welche Befehlssätze Deine CPU beherrscht ist auch das Freewaretool CPU-Z ganz hilfreich.

Cu Rippraff

Hi,

erstmal danke :ja: .

Laut CPU-Z kann meine CPU unteranderem MMX, SSE und SSE2.

Dann könnte Ich ja wirklich SSE2/MMX.
Das wäre aber nur 32Bit.

Die CPU sollte doch aber auch 64 Bit können, da gibts aber nur Floating Point oder IEEE-1800 Reference.
Wäre eins davon nicht evtl. sogar besser? (Wobei sich das zweite irgendwie nach Intel anhört ).

Mal gucken was LigH dazu sagt :seher:

Doppelte Genauigkeit (64-bit-Fließkommazahlen) können durchaus genauere Ergebnisse bringen. Aber die Berechnung wird auch erheblich langsamer sein als MMX/SSE/SSE2.

Aber die Fließkommaberechnung mit doppelter Genauigkeit konnte auch schon ein 387-Coprozessor durchführen. Mit 64-bit-Speicheradressierung und zusätzlichen breiteren CPU-Registern (den eigentlichen Vorteilen der 64-bit-Architektur) hat das nichts zu tun.

Hier hab ich mal ein paar Differenzbilder - Subtract(iDCT 1/2/5, iDCT 4)

Solche einzelnen defekten Blöcke gab es bisher ab und zu:

0563 - 0630 - 1426 - 1663

Jetzt, mit DGDecode 1.3.1b6 sieht es so aus:

0563 - 0630 - 1426 - 1663

LigH
Hübsch, mit welcher Version wurden denn die erstellt?

Könntest Du den neuen Test vielleicht mit 1.1.0 machen? Es nützt ja nichts, wenn da mit 1.3.1b6 bessere Ergebnisse rauskommen, da die Version nicht mit dem RB läuft.
Ich weiß übrigens auch nicht genau, ab welcher Version idct=4 buggy war, das war glaub ich nicht von Anfang an, sondern hat sich irgendwann eingeschlichen, oder?
Schade, dass das engl. Forum momentan down ist...

Cu Rippraff

Die heutigen Differenzbilder liefen mit DGDecode 1.3.1b5. Und erstmals hatte ich DVD2AVIdg/MPEG2Dec3dg getestet. Das heißt: Mindestens alle Versionen dazwischen hatten den gleichen Fehler.

Leider läuft mein Script mit ~ 2 fps. Es dauert also noch etwas, weil ich noch mal sämtliche iDCTs vergleiche.