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
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.