On Wed, Jun 18, 2008 at 8:21 AM, Nicu Buculei nicu@nicubunu.ro wrote:
Ricardo Garcia wrote:
But my dream codec library would be one with a pluggable architecture, so people could add their popular patent-encumbered codecs to it. But it needs to be cross-platform (i.e. Windows / Linux). If you know one, please don't hesitate in telling me.
That sounds an awfully lot like GStreamer. And I believe GStreamer dews work on Windows and Mac (or is being actively ported to).
I see. I'll investigate further. Thank you.
A new note on OpenVIP. I got a mail from Antonin Slavik, the OpenVIP author, and he gives me these great news:
--- snip --- Hi Rick,
the only part of OpenVIP that is ffmpeg-dependent are the FFMpegInput and FFMpegOutput plugins. So it would be relatively easy to get rid of ffmpeg by writing different I/O plugins, provided that you find another good encoding/decoding library. We have chosen ffmpeg simply because it supports a lot of formats and codecs, and because it runs both under Linux and Windows. The annoying thing is a poor documentation and unstable API. --- /snip ---
Regarding FFMPEG and decoding libraries, I don't quite think GStreamer is what i'm looking for. That library is too extense - it handles synchronization, threading, audio and video streaming, and a lot of stuff that I *don't need. Besides, I haven't found anything about codecs in its webpage (maybe i didn't search enough).
If anyone knows of a codec library besides ffmpeg that I can use, please share.
Finally, what are the patent-encumbered formats and codecs that ffmpeg (I mean libavcodec and libavformat) includes? Having a particular list would be very helpful.
Sincerely, Rick Garcia. Saya-VE, Project Leader.
On Thu, Jun 19, 2008 at 10:29 AM, Ricardo Garcia rick.g777@gmail.com wrote:
If anyone knows of a codec library besides ffmpeg that I can use, please share.
. Does xine-libs work for you?
Finally, what are the patent-encumbered formats and codecs that ffmpeg (I mean libavcodec and libavformat) includes? Having a particular list would be very helpful.
To get an idea of what is being talked about. Take a look at xine-lib, xine-lib-extras as packaged in Fedora then look at xine-lib-extras-nonfree as packaged in Livna. You may want to have a discussion with the xine-lib and xine-lib-extras-nonfree maintainer(s) concerning the history on how such a split was decided.
You'll note that even xine-lib-extras-nonfree ends up using libavcodec. Quite frankly I don't think there is a way to avoid using libavcodec for somethings. The ultimate problem is ffmpeg has made no effort to make it easy to use what libavcodec provides in a modular fashion and lump all capability into a compile time choices instead of run time detection.
-jef
The ultimate problem is ffmpeg has made no effort to make it easy to use what libavcodec provides in a modular fashion and lump all capability into a compile time choices instead of run time detection.
Now *THAT* is a good idea for a project.
Forking libavcodec and making a nice C++ pluggable interface to it. If you want your module, just compile it using the "insert your codec library here" API and have the plugin in .so format.
I think this idea is advanced and interesting enough for people to get interested. And say the sooner this is started, the better. I absolutely hate to depend on an unstable and ever-changing API.
Volunteers? :)
On Thu, Jun 19, 2008 at 3:13 PM, Ricardo Garcia rick.g777@gmail.com wrote:
Forking libavcodec and making a nice C++ pluggable interface to it. If you want your module, just compile it using the "insert your codec library here" API and have the plugin in .so format.
I think FORKING ffmpeg is a very very bad idea. A bad use of resources and a very bad thing for Fedora as a project to get behind. Forking upstream codebases is absolutely NOT what we should be doing. As a project, we must engage with the existing ffmpeg developers and offer to do the work necessary to make the ffmpeg codebase flexible enough to meet our needs. Doing an end run around the upstream developers is not how we should do things.
Unless the ffmpeg developers show a complete unwillingness to work with us, then I will actively and vocally discourage any call to fork the codebase. Its not clear to me if there has been a reasonable discussion inside ffmpeg about the possibility of restructuring the codebase if there were developers interested in doing it as part of the ffmpeg roadmap.
-jef
On Thu, Jun 19, 2008 at 6:17 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Unless the ffmpeg developers show a complete unwillingness to work with us, then I will actively and vocally discourage any call to fork the codebase. Its not clear to me if there has been a reasonable discussion inside ffmpeg about the possibility of restructuring the codebase if there were developers interested in doing it as part of the ffmpeg roadmap.
From what I've read in various web rants, I think they're not
interested... particularly I mean this long discussion thread, entitled "Using ffmpeg libs in an OSS project is a nightmare" - http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2005-August/002989.html which was linked from this blog page: http://glandium.org/blog/?p=148.
The entry says:
--- snip --- Guess what happens when someone complains to ffmpeg developers that their software management and API suck. Well, he gets answered repeatedly to include a CVS snapshot of ffmpeg and link statically against it, "like everyone does". Splendid. --- /snip ---
More disturbing is comment 9039 at the blog, by one of the actual ffmpeg devs (and this was written in August last year) :
--- snip --- Justin Says: That link to the ffmpeg-devel archives is 2 years old. Not that the problem has gotten any better, but there have at least been some good discussions on the topic since then. Inevitably they all lead to the same end though. The typical response from FFmpeg developers (and I am one of them) to making official releases is "we really don't have the time. do you have the time? do you want to do it?". So as long as nobody volunteers, it won't get done. It's not that most of us wouldn't like to see nice, clean, stable releases, it's that it is a *volunteer* project with nobody currently willing to give the time and effort to take on the task of release management. Gasper suggested that someone set up a site for unofficial releases. Well it's easier than that; just volunteer to create and maintain official ones." --- /snip ---
Personally, I think stopping ffmpeg development for 2, 3 or even 6 months to do a code restructuring is indeed worth it (the mozilla guys did it, and now we have Firefox thanks to them). Perhaps it would be nice to ask the ffmpeg devs again, who knows? It might just work - specially coming from the Fedora marketing team ;-)
On Thu, Jun 19, 2008 at 7:14 PM, Ricardo Garcia rick.g777@gmail.com wrote:
Personally, I think stopping ffmpeg development for 2, 3 or even 6 months to do a code restructuring is indeed worth it (the mozilla guys did it, and now we have Firefox thanks to them). Perhaps it would be nice to ask the ffmpeg devs again, who knows? It might just work - specially coming from the Fedora marketing team ;-)
If you want to step up and help them change to be more compatible with our policy, you are welcome to do that. But you sure as hell better not walk into their process telling them what they do sucks. You MUST approach the conversation without judgment or blame and you must do what you can to show that you are serious about doing the hard work necessary to help them restructure in a way that is compatible with our policy so that our users can benefit from their work.
We can not blame them for not caring about what we care about. Everyone works on projects for their own reasons. If they don't care about the issues of patent encumbrance or API stability, that does not devalue the work they do. They simply have different interests. What matters is if that their project structure is open enough to include new people with new interests who are willing to work in good faith to make ffmpeg easier to use and distribute. And we aren't going to find that out if people want into their process telling them what they are doing is wrong. It's not wrong, its just not what we need. So we need people in our community who have the development skills, and a civil tongue, to offer to help them make ffmpeg a better fit for our needs in a way, for the greater benefit of all.
-jef
Jeff Spaleta, if you want some help doing this, let me know and I'll help you every way I can :) including talking to the ffmpeg people :)
Lucas do Amaral, Fedora Ambassador - Brazil --
2008/6/20 Jeff Spaleta jspaleta@gmail.com:
On Thu, Jun 19, 2008 at 7:14 PM, Ricardo Garcia rick.g777@gmail.com wrote:
Personally, I think stopping ffmpeg development for 2, 3 or even 6 months to do a code restructuring is indeed worth it (the mozilla guys did it, and now we have Firefox thanks to them). Perhaps it would be nice to ask the ffmpeg devs again, who knows? It might just work - specially coming from the Fedora marketing team ;-)
If you want to step up and help them change to be more compatible with our policy, you are welcome to do that. But you sure as hell better not walk into their process telling them what they do sucks. You MUST approach the conversation without judgment or blame and you must do what you can to show that you are serious about doing the hard work necessary to help them restructure in a way that is compatible with our policy so that our users can benefit from their work.
We can not blame them for not caring about what we care about. Everyone works on projects for their own reasons. If they don't care about the issues of patent encumbrance or API stability, that does not devalue the work they do. They simply have different interests. What matters is if that their project structure is open enough to include new people with new interests who are willing to work in good faith to make ffmpeg easier to use and distribute. And we aren't going to find that out if people want into their process telling them what they are doing is wrong. It's not wrong, its just not what we need. So we need people in our community who have the development skills, and a civil tongue, to offer to help them make ffmpeg a better fit for our needs in a way, for the greater benefit of all.
-jef
-- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
:::: CONTRIBUA COM O MEIO AMBIENTE. NÃO IMPRIMA ESTA MENSAGEM :::::
Wow. Some really interesting traffic all of a sudden. Seems like the f-mktg-list is turning into the f-video-list. :)
Comments inline.
On Thu, 19 Jun 2008, Jeff Spaleta wrote:
On Thu, Jun 19, 2008 at 7:14 PM, Ricardo Garcia rick.g777@gmail.com wrote:
Personally, I think stopping ffmpeg development for 2, 3 or even 6 months to do a code restructuring is indeed worth it (the mozilla guys did it, and now we have Firefox thanks to them). Perhaps it would be nice to ask the ffmpeg devs again, who knows? It might just work - specially coming from the Fedora marketing team ;-)
Oh, Rick, if only we had those magical powers. :)
We may be able to use our name to open a legitimate discussion, though. The absolute key is to be able to bring resources to the table who can actually do the work. In the world of Free Video, this seems to be the hardest challenge.
If you want to step up and help them change to be more compatible with our policy, you are welcome to do that. But you sure as hell better not walk into their process telling them what they do sucks. You MUST approach the conversation without judgment or blame and you must do what you can to show that you are serious about doing the hard work necessary to help them restructure in a way that is compatible with our policy so that our users can benefit from their work.
Yep.
We can not blame them for not caring about what we care about. Everyone works on projects for their own reasons. If they don't care about the issues of patent encumbrance or API stability, that does not devalue the work they do. They simply have different interests. What matters is if that their project structure is open enough to include new people with new interests who are willing to work in good faith to make ffmpeg easier to use and distribute. And we aren't going to find that out if people want into their process telling them what they are doing is wrong. It's not wrong, its just not what we need. So we need people in our community who have the development skills, and a civil tongue, to offer to help them make ffmpeg a better fit for our needs in a way, for the greater benefit of all.
Yep again. This is why Jef is on the Fedora board. ;)
Still, in a code project, nothing talks like code. Sometimes the best thing to do is just write some code.
When the project maintainers say "we don't have time to do this work," frequently the most useful question to ask next is, "do you have time to describe the work so I can do it for you?" Because that really is the key part of the task: actually understanding what work needs to be done, and why.
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.
As far as "forking" goes, sometimes it's necessary to carry a temporary fork. I don't know what the project velocity of ffmpeg looks like, but it's my guess that a lot of the key bits don't change much, and a "fork" that conclusively proves its value can usually be merged without too much trouble. Especially if everyone shares that goal up front.
Anyway, thanks for showing up to the party, Rick. You may be the guy we've been looking for.
(Oh, and Lucas: maybe you're the guy we've been looking for also. Basically, whoever Shows Us The Code, wins.)
--g
On Mon, Jun 23, 2008 at 9:06 AM, Greg Dekoenigsberg gdk@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?
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
I'd like to add to the discussion a fact I just discovered.
As far as I know (I spent a while googling, if I'm wrong someone correct me please), there is *NO* alternative for ffmpeg regarding codecs. There might be one or two codec source codes out there, but as a package, ffmpeg is the only one. Xine sure works in some things, but it's exclusive for gnu/linux (ffmpeg is cross-platform), and in some parts it ends up depending on ffmpeg.
In other words, for all purposes, ffmpeg is indeed a monopoly (I'm not saying it's illegal or their fault, I'm just stating that there's no competition to ffmpeg yet). And as a result, we are at the mercy of one programming team and the decisions they make.
I'd like to correct my previous post. I researched more about Gstreamer, and it *seems* like it does what we need. Of course this is a different problem than the ffmpeg structure we've been talking about, since gstreamer is much wider than a codec collection.
However, if there are no publicly available (and easily downloadable, at least in source) gstreamer plugins to decode patent-encumbered formats (mp3 / mpeg4 / divx / wmv), then what I said in my previous post is accurate and we're stuck with ffmpeg. This implies that actions *MUST* be taken sooner or later, otherwise the year of desktop Linux will NEVER arrive.
Can any GStreamer expert enlighten us about this problem (codec availability)?
Ricardo Garcia wrote:
I'd like to correct my previous post. I researched more about Gstreamer, and it *seems* like it does what we need.
It does.
Can any GStreamer expert enlighten us about this problem (codec availability)?
Not a expert by any means but refer to
http://gstreamer.freedesktop.org/releases/gst-plugins-ugly/0.10.8.html
Also, gstreamer-ffmpeg provides a bridge if you would prefer that.
Rahul
Sorry for my lack of attentionn when it comes to the list,however I have been busy with amount many things my sisters graduAtion. I think that getting this codec hurdek solved wilallow Linux wider market shAre thusbtingomg it near to Windows and Os X Leopard.
Sent from my iPhone
On Jun 24, 2008, at 9:15 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Ricardo Garcia wrote:
I'd like to correct my previous post. I researched more about Gstreamer, and it *seems* like it does what we need.
It does.
Can any GStreamer expert enlighten us about this problem (codec availability)?
Not a expert by any means but refer to
http://gstreamer.freedesktop.org/releases/gst-plugins-ugly/0.10.8.html
Also, gstreamer-ffmpeg provides a bridge if you would prefer that.
Rahul
-- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
marketing@lists.fedoraproject.org
-
Chip Smith -
Greg DeKoenigsberg -
Jef Spaleta -
Lucas - Linux Sys. Admin (CEFETCE/UAB) -
Rahul Sundaram -
Ricardo Garcia