[MPlayer-G2-dev] new release: pre38

Joey Parrish joey at nicewarrior.org
Sat Aug 2 23:34:36 CEST 2003

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?


More information about the MPlayer-G2-dev mailing list