[FFmpeg-devel] [PATCH] libmpcodecs support
Michael Niedermayer
michaelni
Sat Jan 15 03:45:09 CET 2011
On Sat, Jan 15, 2011 at 02:26:40AM +0100, Aurelien Jacobs wrote:
> On Sat, Jan 15, 2011 at 12:44:26AM +0100, Michael Niedermayer wrote:
> > On Fri, Jan 14, 2011 at 11:34:28PM +0100, Aurelien Jacobs wrote:
> > > On Fri, Jan 14, 2011 at 05:37:45AM +0100, Michael Niedermayer wrote:
> > > > Hi
> > > >
> > > > Attached patchset makes libavfilter support most libmpcodecs filters
> > > > The libmpcodecs filters are practically unmodified and for keeping it
> > > > maintainable id like to keep them unmodified.
> > > >
> > > > I will commit this soon but wont enable it yet. That way others can help
> > > > cleanup the wraper (minus code that for maintainability should stay identical
> > > > to the original), fix bugs, rename all global functions so they wont conflict
> > > > with mplayers if they ever include this and generally help.
> > > >
> > > > Please dont bikeshed this to death.
> > > >
> > > > Ahh before i can commit this, libmpcodecs and subdirectories must not get
> > > > blocked by the tab & trailing whitespace checkin scripts.
> > > >
> > >
> > >
> > > > From 34072e13989ebed5e76a425b886b5b17756e6d5d Mon Sep 17 00:00:00 2001
> > > > From: Michael Niedermayer <michaelni at gmx.at>
> > > > Date: Fri, 14 Jan 2011 05:07:39 +0100
> > > > Subject: [PATCH 7/7] Enable libmpcodecs support.
> > > >
> > > > ---
> > > > libavfilter/Makefile | 65 ++++++++++++++++++++++++++++++++++++++++++++++
> > > > libavfilter/allfilters.c | 1 +
> > > > 2 files changed, 66 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > > > index fdb181e..0db4750 100644
> > > > --- a/libavfilter/Makefile
> > > > +++ b/libavfilter/Makefile
> > > > @@ -30,6 +30,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
> > > > OBJS-$(CONFIG_GRADFUN_FILTER) += vf_gradfun.o
> > > > OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
> > > > OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
> > > > +OBJS-$(CONFIG_MP_FILTER) += vf_mp.o
> > > > OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
> > > > OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
> > > > OBJS-$(CONFIG_OCV_FILTER) += vf_libopencv.o
> > > > @@ -54,6 +55,70 @@ OBJS-$(CONFIG_NULLSRC_FILTER) += vsrc_nullsrc.o
> > > >
> > > > OBJS-$(CONFIG_NULLSINK_FILTER) += vsink_nullsink.o
> > > >
> > > > +
> > > > +OBJS += libmpcodecs/mp_image.o
> > > > +OBJS += libmpcodecs/img_format.o
> > > > +OBJS [...]
> > >
> > > I guess all those libmpcodecs files should also be added to
> > > OBJS-$(CONFIG_MP_FILTER). I don't think we want them compiled
> > > unconditionally.
> >
> > i had hoped other people would help but ok fixed locally
> >
> >
> > [...]
> > > IIUC you said that the ultimate goal is to have all those filters
> > > converted to native libavfilter so that we can drop all the libmpcodecs
> > > filters. If so, why does this libmpcodecs filter list includes some
> > > filters which have already a native libavfilter version ?? Namely:
> > > vf_cropdetect.o
quick test says same speed
> > > vf_dsize.o
> > > vf_rectangle.o
not in svn
> > > vf_blackframe.o
> > > vf_mirror.o
> > > vf_rotate.o
wraped libmpcodec is faster than libavfilter
testing done by looking at the fps value from ffmpeg, differences where
significant (on the order of 5%)
> >
> > they can be droped after a quick speed & feature comparission
>
> It is usually the opposite. Code can *get in* after a speed & feature
> comparison.
> But as you want, as long as those duplicate filters don't stay in the
> repository for months.
benchmarked them, results are not pretty as above, there is something wrong
>
> > > Also vf_yvu9 is documented as "Deprecated in favor of the software
> > > scaler". So I doubt it is a good idea to keep it.
> >
> > why is it not droped from mplayer?
>
> Probably because libmpcodec is mostly un-maintained since years, and
> that the few person touching it fear removing anything, just in case
> somebody might still be using it.
> And maybe also to avoid breaking old scripts using "mplayer -vf yvu9".
suggest on mplayer-dev to remove it, if its really useless it should be
removed from mplayer not just our copy
>
> While we are on the subject, this libmpcodecs warper will probably
> also get used in all kinds of scripts. Maybe we should make it clear
> from the begining in the user documentation that those filters are
> bound to disapear, so people should be prepared to adapt their scripts
> later on.
All the filters from this are going to disapear one by one as they are ported
to libavfilter
>
> > > I also suspect vf_palette might already be handled by libavfilter.
> > > It might also be worth double checking vf_yuvcsp but I guess this one
> > > is not yet supported by libavfilter.
> > >
> > > I didn't check the code carefully yet, but I wonder how did you handle
> > > filters like vf_screenshot or vf_hue which require some external
> > > control/command to trigger some actions ?
> >
> > vf_hue worked when i did a quick test
>
> Yes, I guess you can set hue at the begining with a parameter and then
> you can't change it dynamically. This is certainly OK for now.
>
> > vf_screensot needs some API amendments on our side, so its WIP
>
> So it's not ready to go in ffmpeg's repository...
>
> > > I don't think there is any clean API to handle this in libavfilter.
> > > And I don't think vf_screenshot can have any kind of usefullness inside
> > > libavfilter.
> >
> > taking screenshoots is useful
>
> Yes, it is definitely useful !
> But it has nothing to do inside libavfilter !
> An application which want to take a screenshot will just grab the
> current picture out of the desired sink of the filter graph and encode
> it to png (or any codec) using lavc/lavf.
> This is much more flexible.
how many applications support it without a explicit filter?
does ffplay?
>
[...]
> > > Overall I don't think we should import a whole bunch of filters like
> > > this, without even trying all of them to check if they actually work
> > > and they actally make any sens at all in the libavfilter context.
> >
> > I tried all before submitting this patchset, i did not spend an hour per filter
> > for testing.
> > What i can say is none crashed, none failed assert
>
> Great ! That's already quite impressive.
thanks :)
>
> > and filters produced the
> > expected effect where one was expected which was for many filters without
> > finding specific input material and and and, no effect so its possible some
> > do not work completely
>
> It would be better to really test if all those filters are working, but
of course
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110115/d0c134f2/attachment.pgp>
More information about the ffmpeg-devel
mailing list