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

[Michael Niedermayer]

On Sun, Jul 04, 2010 at 03:59:34AM +0100, M?ns Rullg?rd wrote:
> 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.

iam ok with making it a compile time thing depending on mmx


> 
> This is also another absurd name we should fix.

i see nothing absurd on it

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100704/3979a368/attachment.pgp>