[FFmpeg-devel] [PATCH] (New patch) Missing emms_c() calls causing weird Windows crashes with deshake

Ray Simard rhs.ffmpeg at sylvan-glade.com
Thu Jan 12 06:36:38 CET 2012


On 1/11/2012 9:09 PM, Michael Niedermayer wrote:
> On Sun, Jan 08, 2012 at 12:28:31PM +0100, Reimar Döffinger wrote:
>> On Sat, Jan 07, 2012 at 09:51:23PM -0800, Ray Simard wrote:
>>> On 01/07/2012 03:07 AM, Reimar Döffinger wrote:
>>>
>>>> Doing emms_c in the inner loop will (at least on some processors) be
>>>> far, far slower than not using MMX at all.
>>>> An obvious approach is to do the conversion to double only after the
>>>> emms_c.
>>>> Of course I couldn't really figure out why the motion values are float
>>>> anyway, it seems to me that they only ever get assigned ints anyway
>>>> (and none of the video codecs use floating point for motion vectors,
>>>> so IMHO the filter must be doing something wrong if it needs doubles)...
>>>
>>> True, and there's no reason why it should be necessary to assign the int
>>> values of x and y to mv inside the loops at all, even if the ultimate
>>> values coming out of the process for some reason should be doubles.
>>> Using a couple of simple int variables in the loops and assigning them
>>> to the motion vector afterward does exactly the same thing, but with
>>> less overhead and, of course, dodging the need for the emms_c() call.
>>>
>>> This patch does that.  	I've tried it on a variety of files and as far
>>> as I can tell, it's working properly.  I ran FATE on it manually and
>>> there were no problems. I'm not sure what other testing is needed at my
>>> end, so please advise me.
>>
>> Well, I had hoped you could test my patch.
>> Yours needs more code changes and also leaves those pointless
>> int<->double conversions in (for example when comparing against rx/ry
>> limits).
> 
>> Do we have a maintainer for that file? That would be the best person to
>> decide.
> 
> iam not sure if daniel has time, but adding him to the CC

I've tried out Reimar's changes and they work perfectly. I'll be posting
the patch with it shortly.  In the light of the other crash issue above
it needed to be regenerated, but aside from that, it's his suggestion
verbatim.

Ray Simard
rhs.ffmpeg at sylvan-glade.com



More information about the ffmpeg-devel mailing list