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

Stefano Sabatini stefano.sabatini-lala
Mon Aug 16 23:43:59 CEST 2010


On date Saturday 2010-07-03 23:34:36 -0700, Eli Friedman encoded:
> 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.

There are some news regarding this? Is someone already working on it?

Regards.
-- 
FFmpeg = Fostering and Formidable MultiPurpose Eretic Gadget



More information about the ffmpeg-devel mailing list