Re: Mplayer Bonoboized: lumiere (gstreamer - standardization)
- From: "' '" <tint14 hotmail com>
- To: gtk-app-devel-list gnome org
- Subject: Re: Mplayer Bonoboized: lumiere (gstreamer - standardization)
- Date: Sun, 05 Jan 2003 11:03:44 +0000
This is natural for Free Software, that there are
multiple solutions. The existences of GNOME and KDE
are one example. Multiple media frameworks is a small
matter comparing to the "duplication" at the desktop
I think duplication at the desktop level is the same kind of problem, but a
smaller one in some areas, and a larger one in others. I think it is a
smaller problem in that there are only two "major" desktops with their own
widget sets and libraries, whereas there are many more than two media
players with different frameworks. Putting together a system that runs the
maximum number of graphical applications is a matter of installing two
desktops. Putting together a system that plays the maximum number of media
types is a matter of installing a number of media players.
On the other hand, not every user needs to deal with multimedia, while
nearly every user (and "potential" [read windows] user) needs to use a
desktop environment with a file manager, task area, program launcher system,
etc. In this way, the division of desktop software is more harmful as it
divides the user base (i.e. it is 50% less likely that the average new
gnu/linux user can lean into the next cubicle, ask a question about her
desktop environment, and get an answer from someone else using the same
environment (*1) ) and it divides the developer base. I'm not saying, of
course, that having more developers work on the same project means better
software (in fact sometimes the opposite is true), but whenever a new
application developer wants to create a graphical app, he must choose
between Qt and GTK+. In the most practical sense, having a single, standard
gnu/linux desktop would cut down on average install size (no libs for the
"other" desktop would be needed).
However, I think it would be far, far more difficult to standardize on one
desktop environment than it would be to standardize on one multimedia
system. The differences between those that support Qt and those that support
GTK+ are, many times, idealogical. People who develop for Qt believe that
commercial developers who wish to take advantage of Qt should have to pay in
order to do so. They intend to make money, and they should have to give some
of it to those who created the software that allowed them to make the money
in the first place. People who develop for GTK+ believe that anyone should
be able to use widget libraries in any way they choose without cost, but
should be prevented from benefitting from modifying those widget libraries
without giving those modifications back to the community that wrote the
overwhelming majority of the code. Others pick one widget set over the other
for aesthetic reasons. Getting an author of a Qt program to switch to GTK+
or vice versa would often mean changing their ideas of right and wrong. On
the other hand, multimedia application authors tend to write their own
backends, and the overwhelming majority of them are licensed under the GPL.
Getting authors of multimedia applications to standardize on one media
framework would be a matter of convincing them that one framework is
superior to another.
In my opinion, at least, changing someone's value system is much harder than
proving to them the technological superiority of a piece of code compared to
another. I believe that standardizing on a single multimedia framework is
both an important goal and an attainable one.
(*1) I realize that in a work environment where gnu/linux is used as the
primary OS, it is likely that the person in the next cubicle would be using
the same distro/desktop. I think the point is still valid that multiple
desktop environments divide the user base.
However, one has to wonder how much mplayer takes away
from gstreamer. Mplayer actually is a good example of
using multiple codecs available on GNU/Linux, and
gstreamer actually share some of the same codecs
(ffmpeg). In Free Software, sharing occurs naturally.
Multiple efforts do not necessary lead to waste.
MPlayer wraps around many codec interfaces. Same for
I think the gist of your email is that:
1. Mplayer is a good media player.
2. The existance of mplayer does not take much away from gstreamer.
I think that while those are valid points, a grand unified gnu/linux
multimedia framework for all gnu/linux multimedia applications could only
make things better. Without one, it is more difficult for commercial codec
companies to port their codecs to linux. The easier it is to port commercial
software on linux, the more commercial support for linux there will be.
On the other hand, what about divx? As far as I know, divx.com only released
one linux binary per version of their codec (although they have still not
ported version 5.02 encoder support), and yet mplayer, xine, and gstreamer
are all able to use it. This is because each team working on a linux
multimedia player independently implemented support for it. If there had
been a single, unified gnu/linux multimedia framework, only one group of
developers would have had to code support for it. The other groups could
have spent their time doing other things, and received double the benefit
for the same amount of work.
Besides, mplayer and gstreamer are really independent
projects. Existence of a mplayer bonobo component
really takes no resource away from gstreamer.
This I have to disagree with. While the developers may not distract
eachother, the users are definitely divided. Let's say that someone comes up
with a great idea for a new piece of linux PVR software (like freevo or
mythtv). They have to decide if they want to embed the gstreamer bonobo
component, or the mplayer bonobo component. Whichever one they go with, if
the PVR software becomes popular, the other one will not receive valuable
feedback and bug reports from end users and derivative software developers.
Not only does this make the work of the other component developers harder,
but the users of software embedding that other component do not get the
benefit of a large, bug-reporting user base. If, on the other hand,
gnu/linux did have a single multimedia framework, improvements could be
instantly available to everyone.
I realize that simply stating the problem without posing a solution is not
going to get anyone anywhere. This is why I'm making the following
To the developer of the lumiere bonobo component:
-You have stated that your component is a very early beta version, and does
not yet implement core features, such as the ability to stop once started.
Further down the line, when you may have invested a considerable amount of
effort in your bonobo component, it will be much harder to stop development.
I suggest you do that now, and instead encourage those looking for a
multimedia bonobo component to use gstreamer. It is available, usable, and
gives applications every capability listed on the gstreamer.net web site.
-While gstreamer plays a highly respectable variety of media types, encoding
support for those media types (something mplayer does not have at all!) is
progressing more slowly and can use extra developers. According to a
developer in the #gstreamer chat room, one of the programmers changed his
focus from developing the mpeg2 video encoder and mpeg2 muxer components to
other, more critical aspects of gstreamer and now those mpeg2 components are
incomplete. Working on those, if you are so inclined, would be a great way
to exercise your coding muscles. As an added benefit, your code would
instantly become part of far more applications than a bonobo component you
just started writing from scratch -- your name would end up in a very
important "special thanks" file.
-If writing video codecs is not your thing, you might want to work on
gstreamer language bindings. Judging from the beginnings of the lumiere
bonobo component, you seem to like bringing already-written capabilities to
brand new applications. How about bringing already written capabilities to a
whole new programming language, and hence a whole group of apps? :)
To other developers thinking about writing multimedia apps:
-Half of your work has already been done if you use the gstreamer framework.
You're free to focus on developing a user interface you can really be proud
of, and adding other features like visual effects plugins, rather than the
unnecessary drudgery of decyphering cryptically (or poorly) documented file
formats. Show off your coding skills doing exciting new things that nobody
has ever thought of before, not reinventing the wheel.
To codec developers.
-Right now, there is a working bonobo component for gstreamer. There is also
a player app based on it that plays most popular content. You'll be
interested in this quote from the gstreamer.net web page:
"While GStreamer is operated as an independent project we do have a close
relationship with the GNOME community. Many of our hackers consider
themselves also to be members of the GNOME community. There are plans to
make GStreamer an official part of the development framework of GNOME."
Chances are you already have a codec out for win32 environments. Notice how
windows xp can generate preview frames for multimedia encoded with your
codec? If gstreamer becomes part of the gnome framework, you will enjoy the
same benefits when a user examines a folder full of files encoded with your
codec in nautilus. Gstreamer, while being closely connected to GNOME, is not
dependent upon it. This means that KDE could also make gstreamer a part of
its development framework, and you could potentially enjoy exposure to those
who use KDE as well, all without rewriting your codec or having to wait for
multiple groups of coders to write a suitable wrapper for it.
How's that sound?
--- ' ' <tint14 hotmail com> wrote:
> I have mixed feelings about this announcement
> However, when there are
> multiple multimedia backends (e.g. xine-libs,
> gstreamer, lumiere, etc...)
> instead of a single multimedia framework (e.g.
> directshow), the developer
> base is fractured.
> This is bad for the user. When one backend is
> patched, only the apps that
> use that particular backend benefit. Other apps are
> still "broken" or
> This is bad for the developer. If one backend adds a
> capability that a
> developer wants and she is using a different backend
> it her app, she has to
> learn, all over again, how to use a new multimedia
> backend if she wants that
> This is bad for third party codec developers.
Andy Tai, atai atai org
Free Software: the software by the people, of the people and for the people!
Develop! Share! Enhance! Enjoy!
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
MSN 8 with e-mail virus protection service: 2 months FREE*
] [Thread Prev