[FFmpeg-devel] [PATCH] Revert
Paul B Mahol
onemda at gmail.com
Fri Nov 2 02:49:51 CET 2012
On 11/1/12, Reimar Doeffinger <Reimar.Doeffinger at gmx.de> wrote:
> 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
>>> 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, ctx->v_data_ptr,
>>> ctx->v_data_size, 10)))
>>> return res;
>>> + emms_c();
>>> if (ctx->frame.data)
>>> 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
> 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?
That is easy to test, but I bet it is marginal.
Also it is written in inline assembly.
More information about the ffmpeg-devel