[XviD-devel] Transcode module

Christoph Lampert xvid-devel@xvid.org
Wed, 2 Oct 2002 11:28:39 +0200 (CEST)


On Wed, 2 Oct 2002, peter ross wrote:

> > > a) the width/height dimensions must be either specified on the cmd
> > >    line, or you need to modifiy xvid to auto detect width/height.
> >
> >Not a big problem. Transcode (and I guess all other encoding application)
> >have parameters for width/height. And I thought the feature to read
> >from stream was added to XVID a while ago, or "almost" added?
> 
> what "read from stream" feature are you talking about?

Sorry, I meant "read the image dimensions from MPEG-4 bitstream". 
Anyway, at least transcode needs image dimensions in advance for raw input 
anyway. 
 
> >I thought of 2*framesize (=width*height*3), I read somewhere that this is
> >an upper bound. Don't ask me where...
> 
> 
> 2*framesize is simply for handling packed-bframes-within-avi
> (where P and B-vops are stored in the one frame).

No, it was somewhere else. But you are right, packed mode has to get a
twice as large bigger buffer. Anyway, even 4*framesize shouldn't be
problem. 

> > >    * modify xvid to support some kind of buffer underflow callback.
> > >
> > > api3 does not currently address decoding buffer underflows.
> >
> >Is there still need for this if our buffer is large enough?
> 
> nope.

Then lets make the buffer big enough. 
 
> >Most important for me for the moment:
> >      * It should be possible to detect where the next VOP starts
> >        without decoding the whole frame to enable some kind of
> >        "pass-through". Is this simple?
> 
> yep. jsut search for the start_codes.
> start_codes are {0x00, 0x00, 0x01, X }. where X identifies the
> start code type. eg.
> 
> #define VIDOBJ_START_CODE	0x00000100	/* ..0x0000011f  */
> #define VIDOBJLAY_START_CODE	0x00000120	/* ..0x0000012f */
                                                ^^^^^^^^^^^
                                                  what's this? 

> the decoder, currently scrolls through the input bitstream until
> it files a VOP, or runs out of bytes. the number of bytes consumed
> is returned.

Great. This should make a hyperfast passthrough (embed raw MPEG4 into AVI)
mode. 

gruel