[FFmpeg-devel] [PATCH] Make MMX2 put_no_rnd_pixels _x2 and _y2 bitexact

Michael Niedermayer michaelni
Sat May 29 03:21:14 CEST 2010

On Fri, May 28, 2010 at 06:49:57PM -0400, David Conrad wrote:
> On May 28, 2010, at 6:34 PM, Stefan Gehrer wrote:
> > On 05/29/2010 12:27 AM, David Conrad wrote:
> >> On May 28, 2010, at 6:25 PM, Stefan Gehrer wrote:
> >> 
> >>> On 05/28/2010 11:49 PM, David Conrad wrote:
> >>>> Hi,
> >>>> 
> >>>> The mmx2/3dnow put_no_rnd functions don't always round correctly, since they compensate for the +1 in pavgb by subtracting 1 from one of the inputs. This causes our theora decoder to not be bitexact to libtheora, though I haven't found any real source where the error accumulates enough to be visible.
> >>>> 
> >>>> This fixes it by using the property that (a+b)>>1 is equivalent to ~(~a+~b+1)>>1. This makes these functions 5 cycles slower on my penryn, but on my atom the additional instructions appear to be free probably due to load stalls.
> >>> 
> >>> Wouldn't it be worth creating new bitexact functions, but still
> >>> override them with the old/faster ones if BITEXACT is not set?
> >> 
> >> The problem is that theora must always be bitexact,
> > 
> > Why is that? If I don't see the difference I would think
> > I can decode it with deviation.
> Same reason H.264 must be: it's part of the spec.

and MC in mpeg4 asp which is using these functions
try to think about in which case the result differs or consider that in all
thouse years not a single video was found where it makes a
(vissible) difference

i can see political reasons to get rid of this difference for theora but
i cant see a technical or quality related reason


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- 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/20100529/f5843990/attachment.pgp>

More information about the ffmpeg-devel mailing list