Fixing ffmpeg (was: people talking...)

Ricardo Garcia rick.g777 at gmail.com
Mon Jun 23 16:11:16 UTC 2008


On Mon, Jun 23, 2008 at 9:06 AM, Greg Dekoenigsberg <gdk at redhat.com> wrote:
>

> Still, in a code project, nothing talks like code.  Sometimes the best thing
> to do is just write some code.
> The ffmpeg guys likely have thought about the problem space, and have some
> idea about how to solve it, but don't have the motivation.  Maybe we can
> help them find that motivation.  Maybe you can locate "the right guy" and
> pick his brain.  Maybe offer him beer.  Maybe, if he's *really* "the right
> guy", and Rick, you are *really* "the other right guy",
> Red Hat could figure
> out how to get you in the same place, at the same time, to work on the
> project together for a weekend.

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?

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

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"? 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?




More information about the Fedora-marketing-list mailing list