[FFmpeg-devel] [PATCH] PAFF: Derivation process for chroma motion vector
Mon Oct 15 13:12:59 CEST 2007
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().
More information about the ffmpeg-devel