[FFmpeg-devel] [PATCH] Convert MMX deinterlacing code to YASM

[Måns Rullgård]

Vitor Sessak <vitor1001 at gmail.com> writes:

> On 07/29/2010 01:00 AM, Michael Niedermayer wrote:
>> On Thu, Jul 29, 2010 at 12:33:17AM +0200, Vitor Sessak wrote:
>>> On 07/28/2010 11:56 PM, Michael Niedermayer wrote:
>>>> On Wed, Jul 28, 2010 at 05:54:18PM +0200, Vitor Sessak wrote:
>>>>> $subj, fixes the warning
>>>>>
>>>>>> In file included from
>>>>>> /misc/fate/build/x86_32-linux-gcc-4.3/src/libavcodec/imgconvert.c:41:
>>>>>> /misc/fate/build/x86_32-linux-gcc-4.3/src/libavcodec/x86/mmx.h:24:2:
>>>>>> warning: #warning Everything in this header is deprecated, use plain
>>>>>> __asm__()! New code using this header will be rejected.
>>>>>
>>>>> -Vitor
>>>>
>>>>>    imgconvert.c        |   99
>>>>> +++++++---------------------------------------------
>>>>>    x86/deinterlace.asm |   81 ++++++++++++++++++++++++++++++++++++++++++
>>>>>    x86/dsputil_mmx.h   |   13 ++++++
>>>>
>>>> That deinterlacer is deprecated, we have better code in libpostproc
>>>> libmpcodecs and probably other places
>>>
>>> Anything LGPL and MMX optimized?
>>
>> The idea is to get some commercial company to donate money to the authors
>> and our non profit to relicence to LGPL
>
> Since we know this can take some time (remember swscale), I think my
> patch is useful to have cleaner code in the meantime.
>
>>> BTW, talking about x86/mmx.h, is x86/idct_mmx.c deprecated also or is it
>>> worth converting it to plain asm?
>>
>> i dont know, but it doesnt seem very high priority to me
>
> It is not, but it is something that is really fast to do (a good part
> of the work is done by the C pre-processor). Low cost (and low gain)
> work.
>
>> if you have time to kill, optimizing h264*c will make many more people
>> happy than converting that to plain asm
>
> Just finding a good target for optimization in h264 would take me
> longer than the whole of this conversion. Also I find ugly that some
> code that has been deprecated since I joined the project is still
> around (even more ugly given how easy it is to get rid of it).

I'm all for converting that code to some more palatable form if
someone is willing to do the work, and Vitor apparently is.  Removing
it outright would be a regression, so I do not consider that an
alternative until a replacement is ready.

-- 
M?ns Rullg?rd
mans at mansr.com