What is SimpleIDCT?

[trbarry]

This is only sort of an Xvid question but this forum is probably where the related knowledge is, so I guess I'll dare to pose it here.

I heard Xvid now optionally uses a different SimpleIDCT function that is faster or nicer than the old IDCT for some reason. Can anyone tell me if that would also be true if I ported it to my copy of MPEG2DEC2.dll (or MPEG2DEC3) for Avisynth frame serving?

Anyone know the advantages for MPEG-2? (speed?, quality?, would even work?)

Prior to this the IDCT for DVD2AVI's, MPEGDEC's, and Xvid appeared to have mostly the same lineage.

- Tom

[Nic]

Simple iDCT is just a very accurate version of iDCT, the iDCT we were using (and the one most use i.e. intel mmx code with peter gubanov's modifications) was just a little inaccurate which emerged as smearing in QPel.

It could very easily be put into dvd2avi, but the difference in quality (if any) would be minute I'd guess.

Hope that helps,
-Nic

[trbarry]

i.e. intel mmx code with peter gubanov's modifications)

Too bad. When we put in DmitryR's SSE2 version of that I made sure it gave exactly the same results as the other one. ;)

Do you know if SimpleIDCT is any faster or slower?

- Tom

[Nic]

Well micheal from ffmpeg has made the mmx version of it, get the latest xvid CVS code. Id guess it's a tad slower. The Intel one is spec compliant, but just inaccurate enough to make an error in QPel ;)

-Nic

[trbarry]

Naw, heck with it. ;)

If I wanted a very very slightly more accurate and slightly slower IDCT then I could just use float. I guess it was a dumb idea. And I don't even think MPEG-2 uses qpel.

- Tom

[Bishep]

Actually, I misunderstood. :confused: Is there smearing qpel problem in your latest decoder, Nic? Or it's OK.

[Nic]

Well my latest decoder uses simple idct, so im hoping it works fine, but havent had time to test for that QPel smearing properly (I looked, but couldnt see it). Any feedback would be appreciated :)

-Nic

[sungey]

Nic, how bout your xvid.dll build 30/03/2003 (encoding) ... is it using Simple idct too ?

[unplugged]

Interesting thread
@Nic, so we can say that smearing problem is basically a rounding problem...?
Talking about ffdshow (I'm using 20030103), Is that "simple" default iDCT profile equivalent to simple-iDCT?

Thanx!

[((( atom )))]

@nic: the smearing got a lot better, but it is still noticeable, at least with a small clip i kept for testing purposes.
the clip itself is a bit old and i will try to find the time and re-rip and -encode the scene the next days so i could tell for sure.

btw is that broken b-frame / missing ref-frame problem familiar to anybody? i always get that message on top of my movie (wich plays awfully jerky) when i want to use ffdshow with xvid-decoder.

[Didée]

Originally posted by ((( atom )))
@nic: the smearing got a lot better, but it is still noticeable, at least with a small clip i kept for testing purposes.
the clip itself is a bit old and i will try to find the time and re-rip and -encode the scene the next days so i could tell for sure.
Re-encoding is a very good idea in that case.
If I put all comments (dropped here, there, and somewhere) together correctly, then some older builds used qpel without actually using simple-idct. Those builds produced "burnt-in" smearing, I fear. Me myself found some older clips that show heavy smearing even with the newest filters or DLLs, whereas the smearing has gotten minor in encodes produced with the latest builds.

[Nic]

As far as I know, (I got GomGom to clue me in a little while back) The QPel smearing actually occured while encoding, rather than necessarily when decoding. So your old QPel clips that have that smearing may well always have it. Re-Encoding should remove all smearing with QPel.

Feedback always appreciated :)

Cheers,
-Nic

[((( atom )))]

so i reencoded that little testclip and beeing decoded with nic's the smearing is gone, totally. using ffdshow it is there as it always was.
so there seems to be a fix now, great.

that clip i have is really nasty in producing that smearing, so there are very good chances, no one else will find any smearing again.

so nic, as i understand you are able to tell what exactly caused the problem, right? please go and tell the libavcodec/ffdshow developpers (i have actually switched to linux for watching movies, so i can`t actually benefit from you decoder..).

:)

[Nic]

Im sure they now because its Micheal from ffmpeg code's we're using to do the simple idct :)

So I guess just be patient and they'll update :)

Cheers,
-Nic

[JimiK]

AFAIK there is already a new "libav". I'm not using linux for watching movies, but I think an upgrade of mplayer could do the trick. For all windows people: we have to wait until milan compiles a new ffdshow for us where he'll use the new libav. He said he'll do so this week.
Best regards,
JimiK

[CruNcher]

@ Nic
which fdct_ and idct_ function your build uses if SSE2 is detected fdct_sse2 and idct_sse2 ?

[Nic]

fdct_sse2 is used for fdct, but simple idct is used for idct no matter what processor is detected :)

Cheers,
-Nic

[CruNcher]

@ Nic

better use fdct_mmx even if sse2 is detected i tested it here on my P4 1.8 (williamete core) and it gives better results psnr wise http://forum.doom9.org/showthread.php?s=&threadid=49874 and it's only a tad slowerand the best filesize is decreased :)

[Nic]

Cheers for the update, makes me wonder if we need a simple fdct ;)

-Nic