[FFmpeg-devel] [PATCH] libmpcodecs support

[Diego Biurrun]

On Sun, Jan 16, 2011 at 04:37:15PM +0100, Stefano Sabatini wrote:
> 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,

I very much doubt it will make a difference to a branch.

> and the users which want to have that feature *right now* (without to
> rely on another branch).

They will never care about libmpcodecs removal once they have something
that is barely good enough.

> 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.

Your optimism is enviable.  Unfortunately I see no past experience that
supports your plans/wishes to become reality, much less in the timeframe
you expect.

> > 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.

I planned to work on it this weekend, but now I'm busy flaming.

I don't see why I should adjust my work schedule to FFmpeg's needs in
this case.  I'm currently plenty busy and don't want to commit to any
timeframes during which I will get such work done.  Certainly I will
not accept a ban on libmpcodecs changes of any kind, including cosmetic
ones, due to an inclusion in FFmpeg.

Diego