[FFmpeg-devel] Donations and what happens with them

Michael Niedermayer michaelni
Wed Jan 26 15:12:36 CET 2011

On Wed, Jan 26, 2011 at 01:48:29PM +0100, Diego Biurrun wrote:
> On Mon, Jan 24, 2011 at 10:40:29PM +0100, Benjamin Larsson wrote:
> > On 01/24/2011 08:33 PM, Michael Niedermayer wrote:
> > > On Mon, Jan 24, 2011 at 05:07:42PM +0100, Benjamin Larsson wrote:
> > >> On 01/24/2011 04:45 PM, Michael Niedermayer wrote:
> > >>>
> > >>> But then one of the developers on my side told me he has been offered money
> > >>> to work for / join the new maintainers.
> > >>> From where is that money?
> > >>> from our foundation it seems
> > >>>
> > >>
> > >> I'm not aware such events. Most likely not true. But how about we fund
> > >> you to keep working on your fork? I'm sure there are areas where we can
> > >> find an agreement for this to happen.
> > > 
> > > Thats an odd offer in this thread, but what amount are we talking about?
> > 
> > Suggest a project to the foundation board and an amount that you think
> > is reasonable for the task.
> I would suggest refactoring the motion estimation code as a project,
> it is old code that nobody dares touch.

Ive tried to clean it up already for free and i failed ...
The problem was that some changes that where needed to continue simply made
the code alot slower (yes its about gcc failing to optimize the code equally
so after a few alternatives ive tried ive given up with a "fuck gcc"

maybe gcc has improved but given the recent coup ill leave cleanup
of it to you, i dont feel like working for the new maintainers currently

> The impenetrability of the motion estimation code has already hampered
> development of the CAVS encoder in the past, likely other things as
> well.
> Furthermore it slows down parallel builds by an insane amount.  If you
> have a few cores available, compiling motion_est.c takes up more time
> than all of the rest of libavcodec.  Thus all linking stages are
> delayed and precious developer time wasted.

Iam thinking the build system recompiles far too much far too often
Its caused by basing its design on "recompile everything that might in some
corner case need it"
a rule like "minimize the average time it takes a developer to build a
working binary" would work better, id much prefer to have it rebuild just 10%
of what it does for a 1% chance that i need to manually do a make distclean; make
to get a fully working binary.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- 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/20110126/b4f869cf/attachment.pgp>

More information about the ffmpeg-devel mailing list