[XviD-devel] Bitstream header information

Michael Militzer xvid-devel@xvid.org
Sun, 18 Aug 2002 14:54:10 +0200


Hi,

----- Original Message -----
From: "peter ross" <suxen_drol@hotmail.com>
To: <xvid-devel@xvid.org>
Sent: Sunday, August 18, 2002 7:07 AM
Subject: Re: [XviD-devel] Bitstream header information


> >However after having reread your post (and rereading is sometimes
helpful)
> >this functionality is not sufficient to allow an application to use XviD
> >without specifying resolution information. The problem is that the memory
> >initializing is done _before_ BitstreamReadHeaders is called...
> >
> >you're right, we should implement proper support for this asap
>
>
> bill from mpeg4ip posted a patch a few months back; from memory, the
> patch provided a XVID_DEC_VOL and XVID_DEC_ALLOC functions to decode
> the vol, and reallocate internal buffers.  i think this is roughly what
> divx5 does.
>
> the other way is to use an event-based system. when it decodes the vol,
> it checks the bitstream dimensions against the current dec->width,
> dec->height. if they're different, realloc the internal buffers, and
> return an XVID_ERR_RESIZE message.
>
> xparam.width = xparam.height = 0;
> err = xvid_decoder(xframe,xstats);
> if (err == XVID_ERR_RESIZE)
> {
>      // application resizes its buffer, window, etc.
>      // the bitstream resolution is stored in xstats
>      xvid_decoder(xframe,xstats);
> }
>
> the statisics argument can be used for other things, such as returning
> info about the framerate.
>
> the big questions is: which method do we implement?
> - mpeg4ip method is working already (the use it in player), so its not
> much work to get going.
> - the event based method is more work, but imho makes things just that
> little bit easier for the application developer.

well, I initally had the idea to simply add a XVID_DEC_FRAME parameter to
decoder_create, so the resolution is read from the bitstream if no valid
width and height are specified in XVID_DEC_PARAM. However your event based
idea is even better because it allows resolution changes within the
bitstream (and that's a cool features ;-)) - btw: does the MPEG-4 standard
really allow sequences of different size within one stream? Because it might
be possible to dynamically change the resolution at i-frames, right?

bye
Michael