[MPlayer-G2-dev] new release: pre38
arpi at thot.banki.hu
Sat Aug 2 23:47:56 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
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
> packets would be less memcpy since there is no realloc over and over.
> Is this correct?
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
More information about the MPlayer-G2-dev