[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

On Fri, Jan 14, 2011 at 03:55:31PM +0100, Janne Grunau wrote:
> On Fri, Jan 14, 2011 at 01:58:15PM +0100, Michael Niedermayer wrote:
> > On Fri, Jan 14, 2011 at 12:32:01PM +0100, Stefano Sabatini wrote:
> > > On date Friday 2011-01-14 08:04:01 +0100, Luca Barbato encoded:
> > > > On 1/14/11 5:37 AM, 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.
> > > > 
> > > > In order to keep things sane, please DO NOT.
> > > > The swscale experience is fresh again for me and I'd rather not.
> > > > 
> > > > >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.
> > > > 
> > > > Mind keeping that in a branch so people interested may get it and
> > > > people scared can live w/out? I'm not sure if that code is less
> > > > scary than swscale BUT your following comment says much.
> > > > 
> > > > >Ahh before i can commit this, libmpcodecs and subdirectories must not get
> > > > >blocked by the tab&  trailing whitespace checkin scripts.
> > > > 
> > > > Are you joking? If you are _really_ serious I'd suggest (or even I'd
> > > > do myself) to clean it up at least to be properly indented in
> > > > mplayer.
> > > > 
> > > > So in short, to cut all the bikeshed and in the as calm as possible tone:
> > > > 
> > > > since directly importing code from mplayer collides with:
> > > > - coding style
> > > > - basic respect for structured code
> > > > - people that might be interested in contribute optimizations
> > > > 
> > > > I'd rather have it polished before, either in mplayer or here, if
> > > > you are itching to commit it, make a branch and advertise it so
> > > > before it hits the master those 3 points might be addressed already.
> > > 
> > > Before to pronounce I would like to know which is the long term plan.
> > > Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
> > > MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
> > > or we'll have to keep this code and burden duplication forever?
> > 
> > We will try to keep the libmpcodecs code as similar to mplayers as possible
> > and update our copy whenever there are significant changes in mplayers
> > libmpcodecs. This makes cleanup inside our libmpcodecs impossible, it would
> > conflict with future merges.
> 
> I'm very much convinced that copying source files and maintaining them in
> more than one place is a sure path to insanity. And I'm coming from a project
> which makes unfortunately heavy use of that technique. It's just not going to
> work, is much more effort than expected and I would expect that the copy will
> stay there for ever.

So in the very worst case predictions its still the best we can do to move
forward.


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- 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/20110114/106d7a5a/attachment.pgp>