[XviD-devel] [BUG] Pink Frames (still lacks fix) ++

Michael Militzer xvid-devel@xvid.org
Thu, 15 Aug 2002 21:09:40 +0200


----- Original Message -----
From: "Christoph Lampert" <chl@math.uni-bonn.de>
To: <xvid-devel@xvid.org>
Sent: Thursday, August 15, 2002 8:44 PM
Subject: Re: [XviD-devel] [BUG] Pink Frames (still lacks fix) ++


> On Thu, 15 Aug 2002, Michael Militzer wrote:
>
> > > It was motion compensation for chroma components.
> > > That tried to use image-based interpolation as soon as #BFRAMES was
> > > defined, but that only works if XVID_HALFPEL is on.
> > > The combination b-frames + non-halfpel is not possible, of course, but
> > > the combination BFRAMES + non-halfpel, say exactly when max_bframes=0
> > > or max_bframes=-1.
> > >
> > > So we'd better check for XVID_HALFPEL in motion_comp.c, even when
> > > BFRAMES is active.
> >
> > hm, the #ifdef stuff simply is not the best. It makes no sense to always
> > perform image-based u,v interpolation when BFRAMES are defined, even if
the
> > encoder isn't allowed to produce b-frames at all. We talked about it
already
> > but it seems that a major clean-up is finally needed...
>
> Currently it always does _block_ based (hope you meant that). I would have
> checked for max_bframes>=0 or XVID_HALFPEL as a bugfix, but there's no
> access to these flags from the function


simply modify encoder.c to perform _always_ the image-based interpolation
even if no halfpel flag is specified when #ifdef BFRAMES. This should do for
now: Ok, that's slow and may not be needed, but hey: if someone defines
BFRAMES, he should know that it's slow and experimental...

bye
Michael