10:33 a.m.
On Wed, Jun 18, 2008 at 8:21 AM, Nicu Buculei <nicu(a)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.
1:29 p.m.
New subject: Now, that I got people talking...
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.
4:38 p.m.
New subject: Now, that I got people talking...
On Thu, Jun 19, 2008 at 10:29 AM, Ricardo Garcia <rick.g777(a)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
5:13 p.m.
New subject: Now, that I got people talking...
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? :)
6:17 p.m.
New subject: Now, that I got people talking...
On Thu, Jun 19, 2008 at 3:13 PM, Ricardo Garcia <rick.g777(a)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
9:14 p.m.
New subject: Now, that I got people talking...
On Thu, Jun 19, 2008 at 6:17 PM, Jeff Spaleta <jspaleta(a)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 ;-)
11:12 p.m.
New subject: Now, that I got people talking...
On Thu, Jun 19, 2008 at 7:14 PM, Ricardo Garcia <rick.g777(a)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
7:07 a.m.
New subject: Now, that I got people talking...
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(a)gmail.com>:
On Thu, Jun 19, 2008 at 7:14 PM, Ricardo Garcia
<rick.g777(a)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(a)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 :::::
10:06 a.m.
New subject: Fixing ffmpeg (was: people talking...)
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(a)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
11:11 a.m.
New subject: Fixing ffmpeg (was: people talking...)
On Mon, Jun 23, 2008 at 9:06 AM, Greg Dekoenigsberg <gdk(a)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?
12:04 p.m.
New subject: 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.
--g
7:48 p.m.
New subject: Fixing ffmpeg (was: people talking...)
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.
7:49 p.m.
New subject: Fixing ffmpeg (was: people talking...)
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)?
8:15 p.m.
New subject: Fixing ffmpeg
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
10:58 a.m.
New subject: Fixing ffmpeg
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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
5793
days inactive
5800
days old
marketing@lists.fedoraproject.org
14 comments
6 participants
participants (6)
-
Chip Smith -
Greg DeKoenigsberg -
Jef Spaleta -
Lucas - Linux Sys. Admin (CEFETCE/UAB) -
Rahul Sundaram -
Ricardo Garcia