Re: xvid decompression

reno reballos wrote:
> thank you for a clear and precise answer to my question.... 

Hm. I didn't think they were very helpful, because they are not at a very 
detailed level... :-)

> when you were decoding, the frames... what type of frame are you decoding 
> in?

I don't know what you mean. "Type of frame" could mean many things, can 
your rephrase?

> >If you absolutely _have_ to use RGB, then use 32 
> >bits, 16 bits will only slow it down.
> --my encoder output color space is RGB16 bits that will probably save me 
> more bits than using RGB 24 or RGB 32, isn't it or i am wrong ? 

To support RGB16, the code has to do more things than to support RGB32. 
Maybe it can be avoided, but RGB16 means more bit shuffling, RGB24 usually 
means to access memory non-aligned. Like I already said in my previous 
mail, I expect RGB32 to perform better than RGB16. But even better, if you 
use the YCbCr422 color space, the memory requirements are the same as for 
RGB16, while having more precision and no color space conversion takes 
place, so it should be a lot faster. Using YCbCr420 means even less memory, 
but has less precision in the color channels, but mostly that is what the 
codec uses internally, so it should be even faster. Your graphics card 
should usually support converting YCbCr in hardware, AFAIK, it can be a 
texture color space for the 3D engine. And I would expect Windows to 
support that through some API (I am no Windows programmer though).

> >The last time I tested 
> >the speed, I decoded 684 by 384 video with YCbCr colorspace, and that 
> >took about 4 or 5 ms per frame on a Core 2 Duo @ 1.8 GHz. Using both 
> >cores, you should be able to decode about 7 streams. Of course the 
> >encoding takes more CPU, but I have not done that myself and have no 
> >numbers ready.
> --- before you decode the compressed data what is the size of the data or 
> what is the size of the compressed one frame before decoding?

Sorry, no idea and I have no time to check. It's regular video files with 
only few keyframes (possibly per 100 frames or fewer), so it is compressed 
well.

> Stephan, what other tips you can have me when decoding the frames so that 
> i can avoid the lagging problem?

A "lagging problem" can have many reasons. Without knowing your code, I 
cannot help you. Even if I knew your code, I doubt that I have the time to 
help you. I can recommend looking at the source code for popular open 
source video players to get some ideas about possible designs. It should be 
possible to get the internal latency of your player to the duration of one 
frame if you use two buffers. Then there would be the network latency on 
top of that, which you probably cannot avoid.

Best regards,
-Stephan