[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fixing ffmpeg (was: people talking...)

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]