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

Michael Militzer xvid-devel@xvid.org
Thu, 15 Aug 2002 20:45:19 +0200


Hi,

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


> On Thu, 15 Aug 2002, Dead2 wrote:
>
> > > > In my opinion the red and blue dc coefficients are saturated
> > > > by  a bug in  the bitstream  writer or  a MB  coding bug  (remainder
:
> > > > blue+red give pink :-) because pink MBs have an pink average color
and
> > > > the dc coefficient is the average chroma value of MB so...
> > >
> > > Nono, pink is not red+blue (that's RGB mode, forget it). Pink is the
> > > channel with "pink vs. green" (which is either U or V, I don't
> > > remember; the other is "blue vs. yellow". I hope.)
> >
> > Yep, this is the same problem as in the [XviD-devel] [BUG] thread.
>
> Bug found, bug squashed, problem fixed.
>
> 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...

bye
Michael