[XviD-devel] Question about VfW, frame order and Linux

[suxen_drol]

On Sat, 15 Mar 2003 23:59:58 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> 
> On Saturday 15 March 2003 21:55, ChristianHJW wrote:
> > Hi,
> >
> > stupid question of the day, sorry about that, but none of the people i
> > did ask could answer, and GomGom wasnt active on IRC :
> >
> > When using B-frames, as Linux tools like mencoder etc. are not limited
> > by the VfW interface ( Vdub is ), in what frame order are they writing
> > their AVIs ?
> >
> > Do they insert dummy frames as placeholders as well, and are writing the
> > first b-frame into the same data chunk with the I/P frame ? Or are they
> > simply writing the frames in coding order, putting one frame into one
> > data chunk, as always ?
> mencoder + libavcodec / ffmpeg: coded order, no dummy frames, exactly like the 
> MPEG4 standard requires

xvid can operate in two modes:

unpacked: where the encoder outputs frames normally (same as libavcodec)
	[i] [p] [b] [b] [p] [b] [b]

packed: where the encoder groups p and b frames together, and adds a
dummy frame where the p should be displayed. this is intended for avis.
	[i] [pb] [b] [dummy] [pb] [b] [dummy]

important: either mode can be stored in an avi container.
but, if you attempt to decode an unpacked avi with vfw, a 1-frame
decoding delay is introduced. whereas if you decode a packed avi with
vfw, there is no decoding delay.

divx 5.00 generates unpacked streams
divx >=5.01 generates packed streams. xvid mimics divxnetworks packed
format. we were gonna develop our own packed standard, as the divx
"dummy" frame sucks (as is a waste of bits).

-- pete; life is like a box of ammo