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

[Loren Merritt]

On Mon, 15 Oct 2007, Martin Zlomek wrote:
> On Mon, 15 Oct 2007 01:10:06 +0200, Michael Niedermayer wrote:
>> On Sun, Oct 14, 2007 at 10:12:23PM +0000, Carl Eugen Hoyos wrote:
>>> Michael Niedermayer <michaelni <at> gmx.at> writes:
>>>
>>>> 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?

In MBAFF, the reference list is generated as a list of frames, and then 
split to make fields. So a field pair is always adjacent in the list, and 
ref_index&1 is the parity.

In PAFF, fields may be independently reordered in the list (and even if 
no reordering is used, the default order isn't always the same as 
MBAFF), so use pic->reference&1 instead. But you also need to change
pic_as_field() to set reference appropriately.

pic->reference&1 could work in MBAFF too, if you set reference
approriately in fill_mbaff_ref_list().

--Loren Merritt