Re: new release: pre38

Hi,

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

yes. this is why libmpeg2 works this way, too.
(mpeg video is splitted to so-called slices, a line of macroblocks, so yo
have to read many of them to get a whole frame)

>  IIRC, realloc() uses memcpy, right?  So this fragmented

yes

> packets would be less memcpy since there is no realloc over and over.
> Is this correct?

yes
and realloc is slow anyway, it have to search for matching size free blocks.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu