GNOME.org
 

Re: Mplayer Bonoboized: lumiere (gstreamer - standardization)

Hi all,

I'm not a gui / mmedia developer myself..

On Mon, 2003-01-06 at 00:03, ' ' wrote:

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
level.


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.


Umm.. Maybe you should stay in touch with mplayer development. Right now
mplayer can play almost(*) all formats including the latest Quicktime
files with sorenson video & qdm audio.

* --> I say almost all formats lest someone should come up and inform
the list about a new/obscure codec/format which is not supported :-)

Regards,
Imran



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
gstreamer.


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 
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 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?

Eric




--- ' ' <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
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]