[FFmpeg-devel] [PATCH] yadif port to libavfitler

[Måns Rullgård]

Eli Friedman <eli.friedman at gmail.com> writes:

> 2010/7/3 M?ns Rullg?rd <mans at mansr.com>:
>> Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:
>>
>>> On 7/3/10 6:27 PM, Eli Friedman wrote:
>>>> On Sat, Jul 3, 2010 at 4:41 PM, Baptiste Coudurier
>>>> <baptiste.coudurier at gmail.com> ?wrote:
>>>>> On 7/3/10 8:06 AM, Carl Eugen Hoyos wrote:
>>>>>>
>>>>>> Baptiste Coudurier<baptiste.coudurier<at> ? ?gmail.com> ? ?writes:
>>>>>>
>>>>>>> Here is my first attempt to port yadif to libavfilter.
>>>>>>
>>>>>> Did you see this version which contains some SSE3 optimisations?
>>>>>> http://avisynth.org.ru/yadif/yadif.html
>>>>>>
>>>>>> There were also posts to mplayer-devel with optimisations:
>>>>>>
>>>>>> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-November/058981.html
>>>>>> http://article.gmane.org/gmane.comp.video.mplayer.devel/50353
>>>>>> (Thread very broken)
>>>>>
>>>>> Yes, I saw them.
>>>>> I think it's better to have the original version in svn.
>>>>> Afterwards, I'm sure optimizations gurus here will have a shot at it :)
>>>>>
>>>>> Nonetheless, I'm a bit stuck at porting mm_support to libavutil.
>>>>
>>>> Stuck? ?What's the issue?
>>>
>>> It fails linking when using shared libraries, and it needs renaming to
>>> av_mm_support and av_mm_flags.
>>
>> The whole thing is a mess. ?I think we should take this chance to
>> clean it up.
>>
>> Firstly, there is no need to store the flags in a global variable.
>> Every place using them calls the detection function anyway. ?If
>> detecting the flags is slow, the result can be cached in a static
>> variable within the function instead.
>
> Not quite... the one place where this is an issue is emms_c(); I
> strongly doubt we want to run CPU detection on every call to that.

How about instead making it compile-time conditional on ARCH_X86_32 &&
HAVE_MMX?  If there are still people around with non-mmx x86 machines,
they'd have to disable it when building, but what the hell.  It would
save a few cycles per call everywhere else.

This is also another absurd name we should fix.

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