Discrete Cosine Transform - XVID

[octapus]

I heard that Xvid uses Discrete Cosine Transform when compressing which performs really well judging from results.

I wanted to ask if there are any possiblities that it uses in the future some of the new motheds that have come out like
Discrete Wavelet Transform. From what i understand if something like that happens xvid leaves MPEG4 Standard but adopting to new compression techniques will have a better visual quality.

[Nic]

I haven't seen a good video implementation of Wavelets yet....

http://www.cwaip.nus.edu.sg/demo/wavc.html

is interesting, & picvideo's implementation is very bad.

The other implementations ive seen have not been successful either (however, ive seen some very good wavelet image compressors)

-Nic

[-h]

I heard that Xvid uses Discrete Cosine Transform when compressing which performs really well judging from results.

That's what the MPEG4 specs tell us to use.

I wanted to ask if there are any possiblities that it uses in the future some of the new motheds that have come out like Discrete Wavelet Transform. From what i understand if something like that happens xvid leaves MPEG4 Standard but adopting to new compression techniques will have a better visual quality.

There are more advanced (and significantly more complex) profiles in the MPEG4 spec that cater for wavelet transforms. the DWT is a more efficient transform (in theory, anyway), but someone has to sit down and code it. No one really has the urge (or knowledge?) at the moment, as there is a significant amount of tweaking that XviD can undergo in other areas, which will most likely give greater benefits than a DWT would on its own.

But.... we'll never know until we test it :)

-h

[tangent]

Yes well, just about everything uses DCT. MP3 uses an overlapping window variation called MDCT, JPEG also uses DCT.

Ogg Tarkin is currently experimenting with 3D DWTs (time being the 3rd dimension). Interesting stuff, but I you would probably need a huge memory buffer to implement.

Check out the Tarkin development list on http://www.xiph.org/archives if you're interested in following the development.

[duartix]

Do you have any idea as to wy j2k aka JPEG 2000 is still a spread out no go?

I presume the same reason as to why these WCT codecs won't ever leave their base. They perform notable miracles and kick the asses of all other codecs at low bitrates but when you start pumping up the bitrate they won't go as far as the others. It's a pity though... I would really love to see some technology shift in these matters... If not WCT (wavelets) maybe someone will came up with something like FCT (fractals) if applicable.

Now for these gentleman at:
http://www.cwaip.nus.edu.sg/demo/wavc.html

How can we ever take them seriously when their 4MB DivX 3.11 which can be considered a but top of the art codec, since probably hasn't been done using 2 pass and not to be ignored:Their 4MB divx sample has got 2MB of audio while their 3.5MB has 350K of audio? and still their sample get's it's ass kicked?

Who are these people trying to foul?
So probably that's not only PicVideo's implementation that sucks...

[gruel]

Originally posted by octapus
I heard that Xvid uses Discrete Cosine Transform when compressing which performs really well judging from results.

I wanted to ask if there are any possiblities that it uses in the future some of the new motheds that have come out like
Discrete Wavelet Transform. From what i understand if something like that happens xvid leaves MPEG4 Standard but adopting to new compression techniques will have a better visual quality.

Wavelets are very good for low bitrates and still images (that's why JPEG2000 is superior to JPEG). For highbitrates the difference is less obvious and there is one very big problem: motion estimation!

"Normal" motion estimation is based on 16x16 or 8x8 (macro)blocks. It's is extremly efficient and there has been research for a long while.

There is no such easy motion estimation algorithm for wavelets (known to me). You should not use the block based algorithms, because the resulting residuum is blocky. No problem for MPEG, which acts on blocks, but since wavelets always act on the whole picture, you get into serious trouble there.