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

ffmpeg-devel at ffmpeg.org ffmpeg-devel at ffmpeg.org
Sun Jan 8 11:24:10 CET 2012


Better hold off on this one. I found some odd cases of crashes in the
same place in transform.c, though with different circumstances and
different data corruptions.  Unlike the previous case, which always
occurred, this only happens with a small fraction of the source files
I've tried, and I haven't had the chance to look into what traits are
involved. The great majority have worked properly.

So far everything I've read says that the requirement for the EMMS
instruction pertains to subsequent floating point operations, and this
patch removed all of them.  Seems there's an issue with integer
operations too, at least in certain cases.

On 1/7/2012 9:51 PM, 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.
> 
> Regards,
> Ray Simard
> rhs.ffmpeg at sylvan-glade.com
> 
> 
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



More information about the ffmpeg-devel mailing list