[XviD-devel] newpred

Michael Militzer xvid-devel@xvid.org
Wed, 6 Nov 2002 22:53:22 +0100


Hi,

----- Original Message -----
From: "Christoph Lampert" <chl@math.uni-bonn.de>
To: <xvid-devel@xvid.org>
Sent: Wednesday, November 06, 2002 9:59 PM
Subject: Re: [XviD-devel] newpred


> On Thu, 7 Nov 2002, peter ross wrote:
>
> > >From: Christoph Lampert <chl@math.uni-bonn.de>
> > > > has anyone read-up on the newpred mode?
> > >
> > >Where is that?
> >
> > iso/iec 14496-2, page 314:
> >
> > "In NEWPRED mode, decoder may have the additional reference VOP memory
> > to store previously decoded VOPs. When the reference VOP is indicated
> > by vop_id_for_prediction, the decoder select reference VOP from
> > reference VOP memory or additional reference VOP memory to switch the
> > reference picture to the indicated one."
> >
> > the newpred mode is inteneded for feedback systems, where the decoder
> > can send a message to the encoder saying "oops, the last frame i
> > received was corrupted. dont bother resending it, just send me the next
> > frame, but use a previous vop as the reference."
>
> Yes, that sounds completely reasonable... 8-}   Now we know why the
> Stndard has so many pages...

hm, well I never read the whole standard so I never came across this
"new_pred" description, however your description does not sound "completely
reasonable" to me. Considering that a typical XVID video has I-frames every
300 frames (or even more), it seems impossible to me to let the decoder
buffer all frames in between two i-frames. I suppose this new_pred mode was
made for broadcasting purposes where normally a lot more i-frames are placed
in the stream to allow quick channel switching...

> > >Sound good (and slow)...
> >
> > from what've ive read the previous vop can refer to any vop
> > up-and-until the last i-vop, an there's talk of newpred+bvops.
> > yay, more ambiguity.

btw: there's something similar possible in JVT (aka MPEG-4 v.10). iirc, JVT
allows to specify a max number of previous frames which can be used for
prediction in the bitstream headers (so the decoder would know in advance
how many frames it would need to buffer and if there's enough memory
available to play the video). Also, in JVT, different reference frames can
be specified for each MB, which of course pretty much slows down ME (because
you have to do several ME steps for several reference frames) while my early
tests didn't show any significant improvement in compression...

bye,
Michael