[FFmpeg-devel] [PATCH] Revert

[Reimar Döffinger]

On 1 Nov 2012, at 02:08, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Nov 01, 2012 at 01:55:31AM +0100, Carl Eugen Hoyos wrote:
>> On Thursday 01 November 2012 01:45:28 am Michael Niedermayer wrote:
>> 
>>>> The problem is the MMX version of AV_COPY64()
>>> 
>>> try adding a emms_c() somewhere, maybe after parse_bintree()
>> 
>> Attached patch fixes direct rendering in MPlayer here when I revert my removal 
>> of CODEC_CAP_DR1.
>> 
>> Thank you, Carl Eugen
> 
>> indeo3.c |    1 +
>> 1 file changed, 1 insertion(+)
>> f958fd52d2eebcf9a0da9411a08cb8b5a3cf4c07  patchiv32dr.patch
>> diff --git a/libavcodec/indeo3.c b/libavcodec/indeo3.c
>> index 126bd2b..9501763 100644
>> --- a/libavcodec/indeo3.c
>> +++ b/libavcodec/indeo3.c
>> @@ -1094,6 +1094,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, int *data_size,
>> 
>>     if ((res = decode_plane(ctx, avctx, &ctx->planes[2], ctx->v_data_ptr, ctx->v_data_size, 10)))
>>         return res;
>> +    emms_c();
>> 
>>     if (ctx->frame.data[0])
>>         avctx->release_buffer(avctx, &ctx->frame);
> 
> patch ok, a emms is needed before calling outside code like
> release_buffer, though i see no float/double in mplayers
> release_buffer

If I remember right, get/release buffer will end up calling code in the vo, so in this specific case even stuff in for example NVidia's libGL.
Which might be doing all kinds of crazy stuff.
I seriously wonder if there is sense in using MMX for AV_COPY though, it has a seriously high risk for this kind of bugs and we might have to add emms_c all over the place.
Does it really give any performance benefit that is worth that?