Fixing ffmpeg (was: people talking...)

[Greg Dekoenigsberg]

On Mon, 23 Jun 2008, Ricardo Garcia wrote:

> Wait wait wait - when you say ' and Rick, you are *really* "the other 
> right guy",', is that included in the *if*, or it's actually an 
> affirmation?

Looks like I dropped an "if".  But honestly, you're the rightest guy I've 
seen come along so far.  :)

> If it's an affirmation, well,there's a little problem (besides the busy 
> schedule)... ffmpeg is written in pure C, while I believe C++ is more 
> appropriate (IMO it's cleaner, more versatile (even if we decide not to 
> use exceptions). Virtual functions, IMHO, were made exactly for this 
> kind of problem - getting a file's video/audio with a different codec. 
> There are projects (like fobs.sourceforge.net) which wrap ffmpeg under a 
> C++ interface, but it's like pinching a giant blob of flesh and organs 
> (think oversized Tetsuo in the movie "Akira") and getting pipes out of 
> it. It's just not the same, and the problem is worked around rather than 
> solved. I had tried to do this on my own a few years ago, but after 
> seeing the maze of code that ffmpeg is, I gave up only a week after I 
> started. (Then again, I was younger and inexperienced).
>
> So, when I said "fork", I meant "take each libavcodec/libavformat
> module, clean it up and make it internally C++, with a C interface".

Hm.  Well, that would imply that you would probably become the owner of 
those modules.  Which may or may not be something you're up to doing.

> I don't know if I could do it, but the greatest problem will be trying
> to talk to the ffmpeg guys. I fear that If by some mistake I end up
> saying the wrong thing (like suggesting to use C++, it could start an
> epic flame war), they'll kick me out. So how do I say "hey guys, I'd
> really like you to stop adding new things, do a code freeze and make
> an official release so we can all be happy everafter"?

It's a difficult question.  Sometimes the only thing that convinces folks 
is code.

> The guy I quoted tried to do the same (completely in the wrong way, I 
> admit) but he made his point clear (I read all the thread), and yet it 
> was completely rejected (there's no official ffmpeg release up to this 
> date). If the authors don't have time to do a code freeze to make a 
> release, how come they do have time to do more development and add the 
> snow codec and other stuff? This, I fail to understand. But then again, 
> who am I to complain, if I haven't contributed anything?
>
> (Allow me to disgress a little:This "I haven't contributed, therefore
> I have no right to complain" is the lamest excuse I've been told more
> than once in open source projects - ffmpeg excluded because I haven't
> asked yet, but the fear is there - . Just because I'm not a member of
> the team I'm not allowed to complain about something I don't like? If
> I complain, I'm not welcome. If I try to join the project just to "fix
> my bug" because nobody would accept my patch (as it happened in a php
> project - which became obsolete by now, btw), I'm set aside. If I
> fork, I'm a code stealer and a traitor. So how on earth am I supposed
> to deal with that? God help us.)
>
> But I guess I'll have to start thinking how to solve the problem when I 
> touch the ffmpeg code again for my video editor project. I think I'll be 
> more qualified to complain when I actually get to understand the code a 
> little better.
>
> But now that I think of it... perhaps we should start with a much more 
> friendly step: Documenting libavcodec and libavformat. And by 
> documenting, I don't mean "list all functions and explain their 
> parameters", but rather "do a full documentation, make UML diagrams and 
> make some sense out of this mess, with practical examples". If this is 
> already done elsewhere, please share! If not, please help!
>
> Perhaps that would be a much better task and it will flatten the terrain 
> for further negotiations / forks / patches etc.
>
> What do you guys think?

Well, contributing something that's actually useful to the community 
almost always gives one the necessary prestige to tackle the more 
difficult tasks.  Documentation is one of those things that's 
*incredibly* valuable to newbies, but frequently doesn't get written 
because by the time one understands everything necessary to write the 
docs, one no longer needs the docs.  So that sounds like a great start. 
And if it's work you need to do anyway for other reasons, it sounds like 
a win to me.

--g