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

[Michael Niedermayer]

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?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- 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/20071013/6b751491/attachment.pgp>