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

[Martin Zlomek]

On Mon, 15 Oct 2007 13:12:59 +0200, Loren Merritt  
<lorenm at u.washington.edu> wrote:

> 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

Thank you very much, it's much more clear now.

According to the h.264 specs, MBAFF reference picture should be considered
as a frame, right? And if the reference picture is a frame, 'my' coordinate
in mc_dir_part() should not be modified, right?
Does the original code take into account this?


-- 
Martin Zlomek
martin.zlomek at email.cz