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

[Michael Niedermayer]

On Sun, Oct 14, 2007 at 08:19:01PM +0200, Martin Zlomek wrote:
> 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.

and i disagree here, these are the same in MBAFF
if iam correct then you dont understand the code and i wont apply a patch from
someone who doesnt understand the code
if OTOH you are correct and its wrong for MBAFF as well then your patch is
not correct as it does not fix the problem

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker, user
questions for the command line tools ffmpeg, ffplay, ... as well as questions
about how to use libav* should be sent to the ffmpeg-user mailinglist.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071015/dae35d3e/attachment.pgp>