[XviD-devel] multithreading

tomas carnecky tom at dbservice.com
Fri Jan 30 20:21:25 CET 2004


hi,

I still think that a multithreaded encoder would be better.

The way of a frame thru the encoder (feel free to correct me).
The motion estimation is somewhere between these steps, but I
don't know where, this is from a ppt presentation of how JPEG
works.

1. Transforming to YUV colorspace
2. Color subsampling: 8x8 blocks
3. DCT [1]
4. Quantization
5. Serializisation
6. Coding (Huffman/Arithmentic)

And on what kind of data does the 'next' frame depend?
Christoph said that it depends on 'image data, which
means the frame after DCT/quantization/iDCT'.
Why after iDTC? This is the reverse operation as DTC, and
I thought that it's only used while decoding a stream?

Anyway, there are still two steps after quantization.
So while thread two processes the frame further (step 5 and 6),
thread one could already start analyzing the next frame.

Anyone has an idea of how long these different steps take (in
percent)? Which one is the most 'expensive' (cpu/memory/io)?

thanks


[1] JPEG 2000 uses DWT: Discrete Wavelet Transformation,
which seems to be better that DCT. Why isn't it used in
MPEG4? Is the usage of DCT defined in the standart?

btw: Sorry that I'm starting a new thread, but I didn't get any
email so far. Are there any problems with the mailing list?
I have checked my config twice and everything seems to be ok.

-- 
wereHamster a.k.a. Tom Carnecky   Emmen, Switzerland

(GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K  w ?O ?M
           ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+



More information about the XviD-devel mailing list