[FFmpeg-devel] [PATCH] PAFF: Derivation process for chroma motion vector

[Michael Niedermayer]

Hi

On Mon, Oct 15, 2007 at 08:17:12AM +0000, Carl Eugen Hoyos wrote:
> M?ns Rullg?rd <mans <at> mansr.com> writes:
> 
> > > --- libavcodec/h264.c	(Revision 10738)
> > > +++ libavcodec/h264.c	(Arbeitskopie)
> > > @@ -1729,7 +1729,10 @@
> > >
> > >      if(MB_FIELD){
> > >          // chroma offset when predicting from a field of opposite parity
> > > +        if(MB_MBAFF)
> > >          my += 2 * ((s->mb_y & 1) - (h->ref_cache[list][scan8[n]] & 1));
> > > +        else if(pic->reference != PICT_FRAME)
> > > +            my += 2 * ((s->mb_y & 1) - (pic->reference & 1));
> > >          emu |= (my>>3) < 0 || (my>>3) + 8 >= (pic_height>>1);
> > >      }
> > 
> > Is that if() needed?  Wouldn't pic->reference work also for MBAFF?
> 
> I don't think it would work: For the MBAFF sample I have (BBC HD Test)
> pic->reference is always PICT_FRAME (which makes my original patch in this
> thread wrong, of course), while h->ref_cache[list][scan8[n]] alternates between
> even and odd (for one macroblock).
> 
> So if ref_cache can't be used for PAFF (that's what Michael says), the if() is
> necessary IMO.

well as far as i understand the problem currently
ref_cache&1        is not field parity in PAFF
pic->reference & 1 is not field parity in MBAFF

so the solution is to either change one of them to be field parity on both
cases or introduce a field_parity variable
adding an if() in a such a inner loop wont happen unless its absolutely
unavoidable

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071015/255abe5e/attachment.pgp>