[FFmpeg-devel] [PATCH] PAFF: Derivation process for chroma motion vector
Michael Niedermayer
michaelni
Mon Oct 15 01:10:06 CEST 2007
Hi
On Sun, Oct 14, 2007 at 10:12:23PM +0000, Carl Eugen Hoyos wrote:
> Hi!
>
> Michael Niedermayer <michaelni <at> gmx.at> writes:
>
> > > Attached is a patch that removes smearing from PAFF test files I use. It
> > > implements Table 8-10 (Derivation of the vertical component of the
> > > chroma vector in field coding mode) by only allowing my to be changed if
> > > the reference picture is a field. (Cosmetic patch will be applied if
> > > accepted.)
> > >
> > > For my sample, it has the same effect as Martin Zlomeks patch: I can't
> > > see any bottom fields being referenced.
> >
> > but if fields of different parity will be referenced then its wrong or
> > am i missing something?
>
> If the original code works apart from changing my also for non interlaced
> reference frames (if h->ref_cache[list][scan8[n]]&1 really shows the parity of
> the referenced field) it will correctly calculate my += +/- 2
>
> I can s/h->ref_cache[list][scan8[n]]/pic->reference
> but that is a separate issue IMO.
well if h->ref_cache[list][scan8[n]]&1 where correct in PAFF with the current
code then your change should not be needed at all
so no i dont think these are seperate issues
as far as i understand the issue and i didnt extensively study the current
h264.c or the h.264 spec, (so i could be wrong) is that
h->ref_cache[list][scan8[n]]&1 matches field parity in MBAFF but not in PAFF
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/10ce4c8a/attachment.pgp>
More information about the ffmpeg-devel
mailing list