Re: xvid decompression

Hi Stephan,


>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).
--- i dont think so, xvidcore will do a lot of bit shuffling since my raw video is RGB 16, already and my xvid encoder output color space  is RGB 16 too, i use RGB 16 as raw color space so that i can compress more, rather than using RGB 24 or RGB 32 which i think will do much job for the xvid encoder....

>I don't know what you mean. "Type of frame" could mean many things, can 
>your rephrase?
-- i mean, type of frame to be decoded, is it I-frame, b-frame or P-frame, in my case i use all I-frames since when i insert P-frames the decoder does not decode.. i dont know what causes this, for local real-time encoding and at the same time decode the compressed frame no problem but the problem occurs when the i send now the compressed frames which is a series of I P P I P P frames over the TCP/IP the decoder do not decode...


another thing, i experience the phrase " fatal: invalid run or index" while i am on debugging mode, by the way i am using the xvidcore-1.1.3 stable version.. why it occurs this...? do you have any idea?


thank you... looking forward to hear from you...


regards,
reno