Re: new release: pre38
Joey Parrish <[email protected]>
| Newsgroups | gmane.comp.video.mplayer.g2.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Aug 02, 2003 at 11:18:52PM +0200, Arpi wrote: > Only a few codec support 'truncated data', ie you can pass a fragment of a > compressed frame packet to the codec, and it will report 'i want more data' > until it gets enough. libmpeg2 0.3.x is such thing, and libavcodec also > supports this mode. It's interesting for raw formats, where the demuxer > cannot determine the frame boundaries, just can pass fragments to codec, and > let teh codec decide where a compressed frame ends. I see. So, in GIF format, a single image is split into blocks. You don't know how many blocks until you see a 'termination block.' What I just wrote was that the demux packet is resized over and over until all the blocks of one image are in one packet. Do you think preformance would be better if the GIF demuxer added a packet to the queue for each block and then let the LZW decoder ask for multiple packets? IIRC, realloc() uses memcpy, right? So this fragmented packets would be less memcpy since there is no realloc over and over. Is this correct? Thanks, --Joey