Xvid & DVD2AVI 64bit mode

[MaTTeR]

The subject sort of says it all. I'm wondering if anyone has done any testing with 64bit floating point mode out of D2A. I would assume we could expect the same results as with Divx3 or Divx4? Which is what? Better quality but slower than 32bit MMX?

Any thoughts are appreicated.

[Synth]

Well 64bit sounds superior so I always use it :)

[Teegedeck]

...but I don't know anyone who ever could tell the difference.

[ChristianHJW]

My question is .... if we use DVD2AVI to create a .d2v project file, will the setting be valid in any way ? AFAIK the iDCT is done in the MPEG2DEC.dll and not in DVD2AVI, so maybe it has no use at all for GKNot ??

Thiangs may be different of course if you use DVD2AVI to create AVIs ....

[Nic]

MPEG2DEC.DLL is DVD2AVI but in DLL version (pretty much). All the iDCT code is there & in the .d2v file it specifies which iDCT method to use.

So the iDCT is used :) & will make a difference (although normally more of a difference to speed rather than quality :)

-Nic

[Synth]

How much speed difference it is when making a d2v anyway? a few minutes?

Anyway, this begs the next question...

If avisynth uses mpeg2dec.dll which idct it uses internally during processing?

[Koepi]

read that post before yours...

it uses that one that you choose in dvd2avi.

stop mass posting, PLEASE!

Read, think and understand first...

[Synth]

Just found this in the dvd2avi.txt:

[iDCT Algorithm]

iDCT algorithms possess the quality of MPEG-2 decoding.

First of all, these three iDCTs are all IEEE-1180 compliance which confirms the
quality of iDCT algorithms. It's really hard to tell the difference perceptually.

Generally speaking, speed of 32-bit MMX/SSEMMX > 64-bit Floating Point > IEEE-1180 Reference iDCT
In view of this, [32-bit MMX/SSE MMX iDCT] is recommended.

Mathematically, quality of IEEE-1180 Reference > 64-bit Floating Point > 32-bit MMX/SSEMMX iDCT
Reference iDCT implies lossless transformation for those who pursue for the limit.

SSE MMX is a bit faster than MMX iDCT because it invokes PSHUFW instruction.
If your CPU supports (P3, P4, Athlon, Duron, some Cerelon), DVD2AVI will choose the faster one automatically.

[OxP]

A slightly old, but probably still very useful comparison was written up by doom9. If you goto Guides, then dvd related articles, then effects of idct algorithm on mpeg4 encoding. Since it relates to flask:eek: and not xvid encoding, i dont know how they compare, but i am sure that the time vs general quality still applies.

[MaTTeR]

Originally posted by Synth
How much speed difference it is when making a d2v anyway? a few minutes?

Of course you don't see much of a speed difference during the D2A process. Where you will see it is in the Vdub encoding though.

[Synth]

Unless of course your already bogged down by your particular avisynth filter combo, in that case it doesnt seem to matter significantly speedwise.

Btw there is and interesting thread here, with a new (work in progress) version of dvd2avi here for those who didn't know:

http://forum.doom9.org/showthread.php?s=&threadid=11442

[ChristianHJW]

[i]Of course you don't see much of a speed difference during the D2A process. Where you will see it is in the Vdub encoding though.

I honestly didnt know MPEG2DEC.dll will use the iDCT setting as set ( or reported ) by DVD2AVI in the .d2v project. But this is maybe the reason why i cant see any speed decrease when using it :

My SMP system ! As one of the two CPUs ( thats my guess ) is doing all the iDCT in MPEG2DEC and resizing/filtering, the other one is probably mainly dealing with the encoding itself, and this is still the bottleneck .... so all i do when using 64 instead of 32 Bit iDCT algo is increasing my CPU usage ( like from 88 to 92% ), but i dont get any speed decrease. This should be much different on a normal PC with one CPU only ...

[Nic]

ps
The MMX (SSE) integer iDCT isn't IEEE-1180 compliant
(XMPEG can do a check for you)

(But you won't notice any difference)

Cheers,
-Nic

[ProfDrMorph]

ps
The MMX (SSE) integer iDCT isn't IEEE-1180 compliant
(XMPEG can do a check for you)

AFAIK IEEE-1180 compliance means the calculated values are in a certain limit. So MMX (SSE) iDCT IS IEEE-1180 since it's still in the limit but there are iDCT algorithms that come even a bit closer to the original.

[Nic]

My mistake then, as I always assume the other person is correct.

MMX iDCT I had heard does not fall into this limit.

Oh Well,

-Nic

ps
http://www.geocities.com/liaor2/mpeg2avi/mpeg2avi.htm

I recommend downloading the iDCT pack from there & glancing through the tests. It appears some MMX implementations are compliant whereas others aren't

[kastro68]

Could someone plz tell me what AFAIK stands for? Is it an acronym?

[MaTTeR]

AFAIK= As Far As I Know

Search the web for a nice netiquette site:)

[R3g]

A few months ago, I read an article from someone doing comparison between all the iDCT provided by MPEG2AVI. The comparison was made by a calculating a mathematical difference between the original and the resulting frame. All I can say is that almost all of the iDCT had the same results : differences weren't in the same place in the frame, but were in the same quantity. The only noticeable difference between the algorithms was speed.
So in D2A I always use 32-bit MMX iDCT which is a little faster.

[MaTTeR]

So judging by the feedback I think it might be safe to sum up this thread by saying...64bit FP mode doesn't really give any quality advantage generally speaking. It certainly does appear to be slower than 32bit MMX though.