Re: Fw: Fw: libxvidcore decompression
Stephan Assmus <[email protected]>
| Newsgroups | gmane.comp.video.xvid.devel |
|---|---|
| Message-ID | <[email protected]> |
reno reballos wrote: > > Hi Master Stephan Assmus, > > how can i calculate the data size of after encoding process when i am > encoding the resolution of 320x240 @30fps? is there any formula to > calculate the data size after encoding? I am not sure what you mean by "output stream". Usually, what you want from xvid are uncompressed frames of video. The size of the memory needed to store one frame depends on the image size and the color space. Assume you want to display 32 bpp RGB images. Then you would calculate it like this: 320 * 240 * 4; // 32 bits, or 4 bytes per pixel The FPS is irrelevant, since you just want one frame at a time from xvid and can reuse your previous buffer (actually, use a ring buffer of three frames, I explained that before IIRC). The colorspace that you want from the xvid decoder is configured via the "xvid_dec_frame_t::output" structure. Just have a look at the example, all the usual colorspaces are covered by xvid and it does any needed conversion for you. > and another thing i am now decoding the compressed video stream but i am > not getting any output stream from the decoding process... and i dont > think so i am having problem in assigning the values with the decoder > API's? please help me.... Like I said, I don't know what you mean by "output stream". Basically it works like this: 1) prepare your output image buffer. size_t outputBufferSize = 320 * 240 * 4; uchar* outputBuffer = malloc(outputBufferSize); 2) Then you prepare your inputBuffer, this is just a buffer for the separate chunks of the input stream. It can be any size you like, but have a look at the xvid decoder example for efficient values. 3) Then you read as much data from your stream and copy it into your input buffer as that buffer holds. 4) You pass that buffer to the xvid decoding function. You setup the xvid_dec_frame_t structure (fill out the variables with your buffers and sizes, wanted color space and so on). Again, you can see this in the xvid decoder example. 5) You get something back from the xvid decoding function, which is how many bytes of your *input* buffer it processed. This could be equal or less in size of your input buffer. Say you pass an input buffer of 2048 bytes, because you thought 2048 was a nice number. xvid will tell you if it processed the whole 2048 bytes *or* less. If it processed the whole buffer, you can simply read the next chunk of data from your stream, completely replacing the input buffer. If it was less then that, you have several options to implement fetching additional chunk data. One method is to move the remaining part of the buffer, the one that xvid indicated it did not need (yet), to the beginning of your input buffer and then fill the rest of this buffer with new data from your stream. During each iteration of the above loop, you keep watching for the type field of the xvid_dec_stats_t structure that you pass as the last argument to xvid_decore(). If it is > XVID_TYPE_NOTHING it means you have a complete frame in your output buffer. You can display that to your screen. All that said, I am not an xvid developer, so I might have gotten something wrong. I have simply used the xvid decoding example before to write an xvid decoder plugin for Haiku. I have posted the URL to my code before, and I even updated the code in the meantime. You can compare everything I just said with my code and also with the xvid decoding example. That example is also pretty straight forward. It stores completed frames as TGA or something similar IIRC. All you need to do is instead to display these frames to the screen. Really, the code is your friend and best advice for what you need to do. I was about to type up an example, but then I thought... nah it is all pretty well covered. Best regards, -Stephan