[FFmpeg-devel] [RFC] libmpcodecs libavfilter wrapper?

[Michael Niedermayer]

On Sat, Nov 27, 2010 at 05:08:50PM -0800, Alex Converse wrote:
> On Thu, Nov 25, 2010 at 3:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > On Thu, Nov 25, 2010 at 03:02:12PM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Thu, Nov 25, 2010 at 2:41 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > On Thu, Nov 25, 2010 at 08:20:06PM +0100, Luca Barbato wrote:
> > > >> On 11/25/2010 05:03 PM, Michael Niedermayer wrote:
> > > >> > 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
> > > >> > libmpcodecs.
> > > >> > Now you can surely take vf_*.c from libmpcodecs and check that into
> > > >> > libavfilter/libmpcodecs
> > > >> > and then write the surrounding code to translate libavfilter API to libmpcodecs
> > > >> > API.
> > > >> > You dont want to implement it that way maybe, i dont know but iam not aware of
> > > >> > any problem in this approuch
> > > >>
> > > >> There isn't a problem per-se beside the fact mplayer codebase is quite
> > > >> scattered and the faster way to achieve a wrapper might be fix the
> > > >> missing function/struct one by one through the gcc output...
> > > >>
> > > >> > 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.
> > > >>
> > > >> 24h? Probably, maybe 30h and I guess we'd have some restriction in its
> > > >> usage.
> > > >
> > > > i think we should ask arpi, the foundation could pay him for it
> > >
> > > To port, or to wrap?
> >
> > Anything that allows us to use >=90% of the libmpcodec filters in libavfilter
> > implementation should be completely up to arpi to decide
> >
> 
> I'm uncomfortable with the idea of all this money being blown on a
> wrapper. I also think if money is to be spent on this we should look
> into porting filters from LGPL sources (e.g. gstreamer) or pay off the
> copyright holders to LGPL the mplayer filters. I don't think it's
> particularly helpful to have an LGPL filter framework with all its
> actual functionality requiring the GPL.

Foremost, performance matters, the filters must be fast and well implemented.
This is true for many (though of course not all) filters in mplayer.
I dont know the filters from gstreamer. Personally i have no interrest in
picking inferrior code (if it is inferior) just because the other has another
FOSS license.
Either way a wraper for both filter frameworks is a good idea.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- 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/20101128/70ae0ff0/attachment.pgp>