Re: Mplayer Bonoboized: lumiere (gstreamer - standardization)

[Syed Imranullah Azeezullah <s i azeezullah massey ac nz>]

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
>