[FFmpeg-devel] [RFC] libavfilter and libmpcodecs

[Michael Niedermayer]

On Sat, Oct 09, 2010 at 08:54:59PM +0200, Stefano Sabatini wrote:
> On date Saturday 2010-10-09 20:05:12 +0200, Michael Niedermayer encoded:
> > On Sat, Oct 09, 2010 at 07:23:59PM +0200, Stefano Sabatini wrote:
> > > On date Saturday 2010-10-09 19:11:29 +0200, Michael Niedermayer encoded:
> > > > On Sat, Oct 09, 2010 at 06:51:23PM +0200, Stefano Sabatini wrote:
> > > [...]
> > > > Code ported from other projects must not be cosmtically reformated because
> > > > it makes merging changes between trees impossible, that is unless both sides
> > > > are identically reformated or one is removed and replaced by using the other
> > > > (tabs are the exception because we cant commit them)
> > > 
> > > I don't think that's much of an issue as the code is not mechanically
> > > moved, so a patch against one file cannot be mechanically applied to
> > > the other file, and manual intervention is required anyway.
> > > ...
> > 
> > the correct way is to mechanically copy all files and spend 5 days writing
> > a wraper to load libmpcodecs filters.
> > you spend 2 days for each of the 76 filters, which is half a year work
> > i dont mind honestly if you port all and format them pretty in K&R but i
> > think this is the much harder way.
> > So if you like we can continue with this patch here and i can take another
> > look at it or we can forget that and work on a wraper?
> > (filters like crop/scale are different of course they are fundamental enough
> >  so we want them truly ported and not used over a wraper)
> 
> I also want to know about what the MPlayer guys plans are. Are they
> going to drop libmpcodecs and use libavfilter instead? In this case I
> believe it makes no sense to write a wrapper which will be dropped
> anyway.
> 
> On the other hand I'd like to avoid dependencies, and rewriting the
> libmpcodecs filters has its advantages (cleaner code and closer
> integration with FFmpeg/libavfilter) and in the case libmpcodecs will
> be dropped (at least for filtering purposes) we'll have less code
> duplication (and possibly less work for me).
> Also note that not all the filters need to be ported, so they're way
> less than the number you mentioned, and during the libavfilter design
> stage some of the MPlayer devs (Ar'pi IIRC) even volunteered for
> porting some of the filters.

All work/input/comments from arpi is very welcome, and he can have a svn
write account if he doesnt have one.
Id also be eternally happy if he would together with attila be root at mphq
again. And thats not meant to say i do not appreciate the work diego and mans
did ...


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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/20101009/7a3152f1/attachment.pgp>