[Ffmpeg-devel] [PATCH] fix mpeg4 lowres chroma bug and increase h264/mpeg4 MC speed

Michael Niedermayer michaelni
Tue Feb 20 03:29:18 CET 2007


Hi

On Mon, Feb 12, 2007 at 12:49:30PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Feb 12, 2007 at 02:24:58AM -0800, Trent Piepho wrote:
> > On Mon, 12 Feb 2007, Michael Niedermayer wrote:
> > > On Sun, Feb 11, 2007 at 03:40:39PM -0800, Trent Piepho wrote:
> > > > On Fri, 9 Feb 2007, Michael Niedermayer wrote:
> > > > > > Do you disagree with me that avg_h264_chroma_mc4_mmx2 is completely broken?
> > > >
> > > > How come you never answer this?
> > >
> > > well, its brokenness depends upon what it is supposed to do, i didnt write
> > > that code ....
> > >
> > > we could add a requirement that some extra bytes must be allocated after the
> > > buffer but that might cause problems for some users of ffmpeg and wont help
> > > with the multithreading also it doesnt seem like the correct solution for this
> > > rather minor internal issue
> > >
> > > maybe using the plain C version of the code for the rightmost column would be
> > > an option ...
> > 
> > I'm not talking about *PUT*_h264_chroma_mc4_mmx2, but *AVG*_h264_chroma_mmx2.
> > That function does not overwrite the destination bytes, but averages them
> > with the result.  The first two bytes are averaged correctly, the second
> > two bytes are averaged with zero.  Adding extra padding or using the C
> > version on the rightmost column won't fix it at all.  The entire image is
> > incorrect.  It is supposed to compute result = (new + old)/2, but what it
> > is doing is result = (new + old/2)/2
> 
> oops, you are correct, avg_h264_chroma_mmx2 is broken

after rethinking this, i must retract my agreement, iam not sure what i was 
thinking, seems i wasnt thinking at all
the avg code is not more broken then the put code, you implicitly assume
that its executed on a static image which is false its exceuted with put
interleaved

so both put and avg are are buggy if executed at the rightmost column and
your patch does NOT fix this with 1 thread per slice there still is a race
condition in which the data will be trashed also the write over the end of
the picture is still there

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070220/858b9f41/attachment.pgp>



More information about the ffmpeg-devel mailing list