[FFmpeg-devel] [PATCH] libmpcodecs support

[Stefano Sabatini]

On date Sunday 2011-01-16 15:53:52 +0100, Diego Biurrun encoded:
> On Sun, Jan 16, 2011 at 01:45:06AM +0100, Michael Niedermayer wrote:
> > On Sat, Jan 15, 2011 at 11:52:59PM +0100, Reimar D?ffinger wrote:
> > > On Sat, Jan 15, 2011 at 11:37:25PM +0100, Michael Niedermayer wrote:
> > > > What is really important to me is that theres a point after which you wont
> > > > accept further cosmetics from diego in libmpcodecs. I know diego will always
> > > > find more that needs cleanup once he starts looking. And its not fun if 50% of
> > > > commits are useless cosmetics and one has to merge that by hand.
> > > 
> > > That is fine by me, but Diego needs to get a say in that.
> > > Actually I'd prefer if you two could discuss this directly, since I
> > 
> > Ok, lets try.
> > 
> > Diego, ping! you are in CC
> > i suggest we leave it at the tab removial and continue as soon as luca and
> > ronald agree.
> > comments?
> 
> This libmpcodecs thing is the stupidest idea I have heard in a long time.
> Sorry to be blunt, but you are not exactly known for mincing words
> yourself.  However, I do not expect to have the slightest say in this,
> same as the other devs in this thread.  Apparently all that counts are
> a few voices on the ffmpeg-users mailing list.
> 
> Temporary hacks like this have never had a lifetime smaller than infinity
> in the past, this one will not be an exception.  If this gets committed,
> it will stay with ffmpeg until the heat death of the universe.  Nothing
> reduces motivation to work on an improved system more than one that is
> more or less good enough; witness libfaad2 or Flash player.
> 
> If this is supposed to help porting filters, publish a branch and write
> a filter porting HOWTO that instructs people where to pull that branch
> from.  There is absolutely no need to have this code in trunk/master.

It may simplify the work of the developers which work on the porting,
and the users which want to have that feature *right now* (without to
rely on another branch). The code may/should be disabled by
default. Having more users means more testers and more contributors.

And we can run a GSOC and/or funding for porting the filters, we can
realistically expect all the filters to be ported in two years, at
that point we may remove the hack.

Also consider that libmpcodecs is GPL, when porting we may change
licensing when applicable to be LGPL, this may be an incentive for
companies to sponsor filter native integration.

> I also see that Carl Eugen just committed the tab removal that directly
> conflicts with my uncrustify work without any previous discussion, even
> though Reimar mentioned that I am working on something related.

How much time will it take for your uncrustify work to be applied? If
it is along the lines of one/two weeks I suppose we can wait, if it
may take months then I don't think it is worthful to block development
for that. After all libmpcodecs code stands there since almost ten
years, and nobody felt the need to cleanup up it before.

> I vividly remember a certain flamewar caused by rewording Doxygen
> comments without previous discussion.  But apparently the rules have
> been momentarily disabled or they never applied to everybody equally
> in the first place.
> 
> Don't tell me that the tab removal was discussed here previously.
> Obviously the place to discuss MPlayer changes cannot be an FFmpeg
> mailing list, else I will just run FFmpeg through uncrustify after
> I have done it to MPlayer.  I'm sure I can find a mailing list where
> nobody will find my announcement within the 24h timeframe between
> commit threat and execution.
> 
> Diego
> 
> P.S.: *Not* having a DLL loader was one of the earliest policy decisions
> made by Fabrice, he added it to the FAQ in r145.  It has stood ever
> since and nobody except you ever contested it.

Let me say again: libmpcodecs import in FFmpeg won't affect the
developers of other areas of FFmpeg and will be disabled by default,
so I believe that's fair this to be a decision of the libavfilter
maintainer and contributors as stated by the policy.

If many developers are strongly against libmpcodecs in FFmpeg for
philosophical reasons (it hurts my eyes, it's ugly, it scares me),
then I'm not against using a git topic branch (so we'll have to wait
for proper git migration I suppose?), but I'd prefer to keep it in the
main branch, as this means less work *for me* and for potential
contributors.
-- 
FFmpeg = Fabulous and Fundamentalist Multipurpose Pure Ecumenical Ghost