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

David Conrad lessen42
Tue Jun 1 02:00:05 CEST 2010

On May 28, 2010, at 9:21 PM, Michael Niedermayer wrote:

> 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 thought there was some case other than 0 since it happens in every I've tried, but going back and actually checking confirm that indeed, it's doing MC from 0.

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

More information about the ffmpeg-devel mailing list