[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

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_blackframe.o
>   vf_cropdetect.o
>   vf_dsize.o
>   vf_mirror.o
>   vf_rectangle.o
>   vf_rotate.o

they can be droped after a quick speed & feature comparission


> 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?


> 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

vf_screensot needs some API amendments on our side, so its WIP


> 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


>
> And how did you handle filters like vf_remove_logo which fopen()
> an image file and decode it internally, totally ingnoring several layers
> of abstraction ?

i dont know what you mean by handle, the filter does what it does. ive not
changed that. Changeing this is completely outside the scope of this patchset


> I guess it should be handled by simply having a second input pad
> allowing the application to feed it with any kind of decoded picture.

Not only would it be alot of work to implement this, it would also make
the use of the filter much more complex.


>
> 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 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

What i had hoped was that other people would help me with this and be happy that
i implemented one of the most asked for and important things for libavfilter.


[...]
--
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/9cffadd2/attachment.pgp>