[XviD-devel] xvid decompression
Stephan Assmus
superstippi at gmx.de
Wed Jun 11 15:07:05 CEST 2008
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
More information about the XviD-devel
mailing list