On Mon, Jun 23, 2008 at 9:06 AM, Greg Dekoenigsberg <gdk@xxxxxxxxxx> 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? -- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-marketing-list
