[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