Re: Mplayer Bonoboized: lumiere (gstreamer - standardization)

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, 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 suggestions:

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 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 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
> "behind".
> 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
> capability.
> This is bad for third party codec developers.
> Eric

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*

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]