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

[Eli Friedman]

2010/7/3 M?ns Rullg?rd <mans at mansr.com>:
> 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.

We already use cmov and MMX unconditionally (i.e. assume a Pentium-II
equivalent) if ffmpeg is built on a machine that has them... not sure
if that was intentional, but as far as I know there haven't been any
complaints.  So that seems fine.

-Eli