[FFmpeg-devel] [RFC] libmpcodecs libavfilter wrapper?
Thu Nov 25 17:03:51 CET 2010
On Thu, Nov 25, 2010 at 01:43:09PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2010-11-02 12:55:11 +0100, Michael Niedermayer encoded:
> > On Tue, Nov 02, 2010 at 12:06:37AM -0400, compn wrote:
> > > On Tue, 2 Nov 2010 02:00:24 +0100, Stefano Sabatini wrote:
> > > >The problem with libmpcodecs is that it isn't a library, and was never
> > > >meant to be usable from outside MPlayer, so trying to integrate it
> > > >into FFmpeg is a nightmare. Indeed the only way is to copy the files
> > > >to FFmpeg and all the dependencies (vf.h, mp_msg.h, help_mp.h,
> > > >m_option.h, m_struct.h, img_format.h, mp_image.h, mpc_info.h, vfcap.h
> > > >etc) and somehow patch it to the build system... and yet I have no
> > > >idea how I can map the MPlayer log system to that of FFmpeg and looks
> > > >more that I can withstand...
> > >
> > > (note that i have no idea what i'm doin and to take this mail as a
> > > joke)
> > >
> > > probably start small:
> > > s/mp_msg/av_log
> > > s/MSGL_ERR/AV_LOG_ERROR
> > > etc, then you can cross off mp_msg.h
> > >
> > > s/MSGTR_OpeningVideoFilter/"opening video filter"
> > > etc, then cross off help_mp-en.h
> > the obvious way:
> > #define mp_msg
> > #define MSGL_ERR 0
> > #define MSGTR_OpeningVideoFilter ""
> > ...
> > (if there is no header that satisfies these without introducing new unresolved
> > dependancies)
> > and once one or 2 filters work, one can look at changing these things to more
> > reasonable things
> > iam not aware of any real issue in libmpcodecs for porting it but as said
> > it needs someone with a bit more experience in such porting, aka this is
> > probably not a good case for ones first such project
> I already told that libmpcodecs is not a library but just a bunch of
> files scattered through a dir and so writing a wrapper around it is
> nothing which can be done without much pain, better is to redesign
> libmpcodecs but we have already such a redesign and is called
And i told already that such wraper needs to be written by someone who has
more experience with porting code between projects. For such person it should
not be much pain to do it.
You surely will have to agree that mplayer is able to use the filters from
Now you can surely take vf_*.c from libmpcodecs and check that into
and then write the surrounding code to translate libavfilter API to libmpcodecs
You dont want to implement it that way maybe, i dont know but iam not aware of
any problem in this approuch
Also ill wager a bet that arpi could implement a wraper in less than a day
arpi has very extensive experience with porting code between projects and he
wrote large parts of libmpcodecs.
> So from my point of view it would be just better (and easier) to make
> libmpcodecs implement a filter for libavfilter so that we can compare
> a libmpcodecs filter with a libavfilter port.
> Then in the long term it would be just better to make MPlayer directly
> use libavfilter and drop libmpcodecs filter support. This is not my
> idea but I believe this was implicitely decided three years ago when
> you choosed to design libavfilter from scratch.
I didnt choose that. i wanted people to use libmpcodecs as basis for the new
filter system aka improve upon the best existing system at that time.
That didnt work out as noone was willing to do it so now after 3 years
we are better in some ways (arbitrary filter graphs) than libmpcodecs and
still worse in others (like actual number of supported filters)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel