Re: xvid decompression

reno reballos <[email protected]>
Newsgroups gmane.comp.video.xvid.devel
Message-ID <[email protected]>

 
----- Original Message ----

From: Stephan Assmus <[email protected]>
To: [email protected]
Sent: Wednesday, June 11, 2008 3:19:28 PM
Subject: Re: [XviD-devel] xvid decompression

Hi Stephan,

thank you for your prompt reply... i am enlightened by your answer.... thank you and i would would like to have follow-up with your answer to my question if you wont mind....

>Yes, you can have multiple instances of the decoder. You can call
>int ret = xvid_decore(NULL, XVID_DEC_CREATE, &xvidDecoderCreate, NULL);
--- in my application i have at least five decoders, thus i have to create also 5 different decoder instances and 5 different decoder handle, then, with this situation that i have 5 decoders decoding at the same time, will it not affect the system performance, because right now i have lagging problem when the conference over TCP/IP are full, i mean there are 5 people are in the conference...

by the way, to give you a brief description with my application on video conference, raw video is 352x288 at 30frames per second, 16-bit RGB, the output of xvid encoder is also RGB 16-bit, the video conference is 1:4, thus in one computer there is one xvid encoder and 4 xvid decoders that will run simultaneously during the process.

when decoding the frames at the receiver, one thing that i noticed is that, decoder does not decode if it is a series of I P P I P P I P P... ? coz when i set the encoder to XVID_TYPE_AUTO so that i can have a series of I P P I P P...., the decoder at the other side gets trouble when decoding, thus i have to set it always XVID_TYPE_IVOP, in effect i got still big amount of data after compression at around 6000bytes...

is it safe to use multi-threading in the decoding process? will it not cause lagging problem?

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

regards,
reno
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.