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

[Martin Zlomek]

On Mon, 15 Oct 2007 01:10:06 +0200, Michael Niedermayer <michaelni at gmx.at>  
wrote:

> 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
>
> [...]


Well, that's the problem. h->ref_cache[list][scan8[n]] contains reference
index, thus h->ref_cache[list][scan8[n]]&1 can't match field parity.
Reference index and field parity are not related in general.
Am I wrong?
Loren, could you comment this thread, please?


-- 
Martin Zlomek
martin.zlomek at email.cz