Re: Gnome Video Player - WAS:Re: A baggage-free approach to gnome-media

[Thomas Vander Stichele <thomas urgent rug ac be>]

Hey Dennis,

> > Ok, lets get this straight. Gst-player is based on gstreamer.
> > Monkey-media is based on gstreamer. The lib I have referred to as
> > libgstplay is a *tiny* wrapper lib (currently packaged within
> > gst-player) which hides the underlying gstreamer pipeline while
> > presenting a nice simple api for media playback.> 
> 
> Maybe you shouldn't see monkey-media just as a wrapper, but as a higher
> level library which covers the low level bits of gstreamer and more than
> just that.It allows one to be flexible but also shields one from how the
> pipelines are laid.

That's true.  Monkey-Media is good at that.  However, it does present an 
extra step in abstraction, which sometimes make things harder too.  It's 
fully GObject-ized, which is nice, but hard to follow since I find myself 
jumping from one virtual function to another.  I'm not saying that's bad, 
it just means that it's a complicated library to hack on.  That's not a 
problem, since it does really well what it was designed to do - support 
rhythmbox.

If monkey-media would evolve to a more general GStreamer wrapper (which it 
can, we just need to work out how, if we want that), it will definately 
need a lot more features.

What I mean by that is
a) monkey-media is very good for rhythmbox at this point
b) monkey-media isn't very close to what a gnome developer currently needs 
from a multimedia API.   It allows you to play mp3 and ogg files using
a few objects, but that's it. (There's nothing wrong with that btw !)
c) Monkey-media currently has an API where you need
to create stream and mixer objects, connect to an eos callback, go to the 
main loop, and set the state to playing.  The "simple" case (playing a 
sound) takes about as much code as the equivalent GStreamer code.

2) is normal, it was designed from another perspective, namely, "here's a 
cool app called Rhythmbox, what API does it need".  libgstplay has about 
the same problem, although it was from the ground up redesigned with 
providing a simple play API in mind.

3) is a problem.  The sample command-line player is indeed short, but 
should be shorter for a gnome developer.  It's about just as long as a 
gstreamer app that plays the audio.

> Also an video player or and mp3 player doesn't want the EXTREME
> flexibility gstreamer is allowing. In matter of a fact why is gnolin
> created when it simply sits between ? I guess giving the developer
> a simpler api meant for doing NLE stuff. And maybe to do things that
> aren't in the scope of pipelines.

gnonlin is a very good example of ways to extend the GStreamer API.  I'll 
come back to the analogy later on in your mail.  Gnonlin is a natural 
extension of GStreamer, with further subclassing, while Monkey-Media is 
more of a wrapper.

> Also it actually does matter if monkey-media is between or not. Think
> about it like this: monkey-media can be for gstreamer what gtk is for
> gdk. Simpler development.

Actually, if you look at the analogy, it's more like this :

(GStreamer internals)	Gdk
GStreamer		Gtk
gst-plugins		gtk widgets
gst-editor		glade
gnonlin			one of the extended gnome API's

Just as no normal gnome programmer should have to wonder about Gdk's 
internals, so does a normal gnome programmer not need to know how 
GStreamer works internally.  Schedulers, memory management, object 
creation, how events are implemented, and so on.

Elements and pipes are like widgets in gtk.  They're the basic building 
blocks, and the analogy works really well.  You create a pipe as you do 
with a toplevel widget, you create elements and add them to pipes as you 
do with buttons and pixmaps.
Knowing about elements and pipes and connections is helpful to an app 
developer, just as it's good to know how widgets work when your layout is 
screwed up.
Gst-editor is the designer you would use to test and implement pipelines.
And Gnonlin is a special-purpose library, that further subclasses Gnome, 
to do more complicated things and avoid code duplication to do it.
This is like the file selector dialog widget in the Gnome library, if you 
will.

> Also i saw someone suggesting that nobody cares about when applications
> can choose between gstplay and monkey-media well actually having code
> and functionality duplication in the development libraries of an 
> desktop platform isn't a very good idea.

I agree that code duplication is not a very good idea.  That doesn't mean 
there needs to be, we just need to find sets of features that are 
orthogonal.  It's pretty certain that RhythmBox will always have needs 
that are specific to RhythmBox.  Think about it - if all of the features 
that RhythmBox would need were all in this one library, then the only 
thing you can decently write with that library are RhythmBox clones.

It is very likely that there is some middle ground where some common 
functions can be abstracted away, but it is also likely that some 
functions will be rhythmbox-specific.

> Another thing i read or heard at irc the last few days is that a few
> people think that monkey-media is bloat. Well if you think that
> monkey-media is bloat for media application what do you think off 
> gstreamer being ? 

I don't think it's bloat.  It's not easy to code in, because it has a high 
abstraction level, but it's not bloat.
Neither is GStreamer, btw - it can be as thin as you want and you can run 
it embedded as well.  Bloat is a matter of perception, and most people 
that complain about bloat can be easily uncovered to be not very 
knowledgeable on the subject.

Compare to me saying that bonobo is bloat.  I don't even know what bonobo 
really is on the inside ;)

> there was something about the mixer that only
> rhythmbox needs it. I think not. I can imagine that there are more
> applications that would like to use cross fading or volume 
> normalization. but if you don't agree proof me wrong.

Simple gnome apps won't need it.  I can imagine other apps that do, and 
I'm probably going to write one or two myself for various other projects.  
When I do, chances are high that I will make it depend on whatever 
monkey-media evolves into, since that's what it was designed for.

Thomas

-- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
god loves his children
yeah
<-*- thomas apestaart org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/