[FFmpeg-devel] Development polices of the FFmpeg

Baptiste Coudurier baptiste.coudurier
Fri Aug 29 23:39:03 CEST 2008

Roman V. Shaposhnik wrote:
> On Fri, 2008-08-29 at 11:42 -0700, Baptiste Coudurier wrote:
>> We all work for the sake of bringing FFmpeg up here, and we all have the
>> same goal, we also have differents commitments and interests, discussing
>> as a "team" is needed, not necessarly in a "pyramid" way (Michael /
>> single dev people), however Michael tends to do everything around here,
>> so this is less obvious IMHO.
> That is really the crux of the problem. I don't think I can be part
> of the Michael's FFmpeg. He obviously doesn't seem very highly of
> me (not without a merit, though: compared to me he IS smarter and he IS
> a better coder -- I'll be the first one to admit that) and we both
> don't need the kind of aggravation we seem cause to each other. On
> the other hand, I would LOVE to be part of the FFmpeg of you, M?ns,
> Mike, Kostya, Diego and a dozen of other developers who I greatly
> respect. I just need to figure out what kind of project it is nowadays.

However Michael is project leader, and the quality of the code of FFmpeg
would not be the same without his reviews and nitpicks, I also need to
admit this.

> For example, when Michael throws a moody about something as trivial
> as: ((s->buf[1]>>2)&0x3) == 0 vs. (s->buf[1]&0xC) == 0. Is it something
> that would be of a concern to anybody but him? And if not, should
> he be payed attention to *IN THIS PARTICULAR CASE* (to be extra
> clear this is the case of a code NOT officially maintained by him).

To me, yes. Trivial fix, better said than not IMHO.

> Another example -- should threatening to revert the changes in the
> pieces of code that he doesn't maintain over trivial issues be his
> usual modus operandi, or should there be SOME level of involvement
> of other developers to decide whether such drastic measures are
> really called for, or whether it is better for the project
> to try and resolve issues first (with the code in question being
> in SVN) and only if it fails remove the offending parts.

Well even Loren submits patches are take comments into account from
everyone and even Michael's nitpicks. Loren is also brilliant ...

> Here's the deal: I used to contribute to FFmpeg much more
> actively a three years ago or so, but then I went through
> a period in my life where any major coding outside of my
> immediate employment was more of a luxury. I'm now back
> on track. I still have lots of interest in doing multimedia
> as my hobby. I also believe that I am capable of being mildly
> helpful to the overall success of the project, even though
> the nature didn't bless me with the kind of gift that 
> somebody like Michael is blessed with. Precisely because
> of that I'm also prepared to happily receive the kind
> of technical guidance that was exemplified by 
> dv100_dct_mode vs. mb->dct_mode change. The only thing that
> I ask for is that I work with a team instead of a single
> individual with his likes and dislikes and the team
> decides over the matters, instead of the individual
> lashing out at you over trivialities. Is it too much
> to ask for in return to the kind of work I am capable
> of? I honestly don't know. But please DO tell me.

Im thinking the same, however if someone brilliant other than Michael
jumps in and starts reviewing, finding extreme perfect optimizations and
algos, you would have to take care of them also.

This issue is also about shellscript where Mans/Diego are more
experienced, so when you write shellscript, expect nitpicks from them

Yes, this is hard and painful, but we, others, like you mentioned are
also discussing together on irc and privately and helping out each other.

I also see that oftenly it's really nice to have final review and know
that your work is ending in a very good shape. The steps are frustrating
though, I agree.

> Again, sorry for the digression, I just didn't want
> it to look like it is simply about me ramming DVCPRO HD
> code through. There's actually much bigger question
> for me at stake here.
>> Working around here is _not_ easy and we need to encourage ourselves.
> Once again, the only thing I'm asking for that it is a TEAMwork
> instead of a dictatorship.

It's a dictatorship in a way that who does the work gets to decide and
Michael does much work, however your point is and if not, must be, taken
into account. Raising a vote is possible, I even tried myself to do so
with mpeg demuxer, but failed badly, even if Michael tends to be ok with

You have svn write account, you can also object to some commits, and
argue, and IMHO are very welcome to use this right.

>>> I have 0 contract money at stake here. And trying to imply that I do
>>> is just pathetic. I knew you were a pompous jerk, but I would never
>>> imagined that you would go as low.
>> Well, Dans had, and some people already offered bounty for this work, so
>> while the commitment and the cleanup of Dans is clearly _obvious_, and I
>> think Michael should have realized it, this is not 100% true that there
>> is no contract / money behind DVCPROHD as a whole.
> I guess the above is the kind of truism that is always there. Of course
> I will gladly accept any kind of financial (or hardware) donation
> for my past work.  But it is quite different from working under 
> contractual obligations that regulate what you're supposed to
> do in the future. I have never done that around FFmpeg and I don't
> intend to do it any time soon.

Some people do and already did work under contractual obligations such
as "code to be included in svn", I understand the pain, but this is the
game you have to accept, and I agree with it.

> P.S. Thanks for acknowledging my contributions to FFmpeg. Even though
> honestly most of them are trivial compared to what Michael does.

You're very welcome, Roman, you know I really appreciate your work.

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA

More information about the ffmpeg-devel mailing list