[FFmpeg-devel] [PATCH] Implement PAFF in H.264

[Martin Zlomek]

On Sat, 13 Oct 2007 21:48:52 +0200, Michael Niedermayer <michaelni at gmx.at>  
wrote:

> On Sat, Oct 13, 2007 at 11:52:00AM +0200, Martin Zlomek wrote:
>> On Fri, 12 Oct 2007 02:32:48 +0200, Michael Niedermayer  
>> <michaelni at gmx.at>
>> wrote:
>>
>> > On Wed, Oct 10, 2007 at 08:09:11PM +0000, Carl Eugen Hoyos wrote:
>> >> Martin Zlomek <martin.zlomek <at> email.cz> writes:
>> >>
>> >> > > The attached patch fixes chroma motion vectors as specified
>> >> > > in the h.264 spec in section "8.4.1.4 Derivation process
>> >> > > for chroma motion vectors", table "Table 8-10 ? Derivation
>> >> > > of the vertical component of the chroma vector in field
>> >> > > coding mode".
>> >>
>> >> > Previous patch (paff.5.patch) should be replaced be the attached  
>> one.
>> >> > I am not sure if 'emu' flag is updated correctly, but if it is
>> >> > correct in surrounding code, it is correct in this patch as well.
>> >> > If anyone (e.g. svn user lorenm) deeply understands edge emulation,
>> >> > please check this patch.
>> >>
>> >> This patch fixes smearing issues in several files I tested.
>> >>
>> >> Michael, could you comment?
>> >
>> > yes, why does the original code not work?
>> >
>> > [...]
>>
>> The original code alters 'my' depending on mutual relation between the
>> current macroblock parity and the picture index (in reference picture
>> list) of the reference macroblock part. Well, I think it is wrong for
>> MBAFF macroblocks anyway. Or can anybody explain to me how can I
>> put into relation macroblock parity and picture index, not parity of
>> the picture at the index? What have I missed?
>> Anyway, if the reference picture is a frame (neither top field nor
>> bottom field), no altering should be realized...
>
> patch rejected
> either i dont understand you or you dont understand the code
> also this needs a benchmark and some _clear_ explanation of why we cannot
> use the same code for MBAFF and PAFF but why we would need another  
> special
> case in speed critical code
> and iam not saying the current MBAFF code should work for PAFF just that
> i see no need to fork it and calculate the stuff totally differently
> it seems only ref_cache is wrong for PAFF?
>
> [...]

No, I think that the original code is wrong for MBAFF as well. It uses
reference picture index, not parity of that picture.



-- 
Martin Zlomek
martin.zlomek at email.cz