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

[Dennis Smit <synap yourbase nl>]

On Tue, 2002-09-17 at 19:58, Steve Baker wrote:
> > 2. Use gst-player as a base, integrate it with the desktop, maybe port
> > it to mm. - Donno about this one, it already has the nautilus view, but
> > it's maintainers dont want to complicate it or use monkeymedia, os
> > personally if totem could be used I would leave gst-player out(sorry ppl
> > working on it)
> 
> 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.

An APPLICATION developer doesn't want to know how gstreamer is building
pipelines and connecting elements. It just wants an simple BUT also
flexible way of controling the media.

As we are talking about multi media right now. Which is not only audio
or video. it's both and more, think about visualization of an audio
stream. CDrom playback. Reading the tags of ogg (and mp3) files even
being able to change them. Advanced features like these won't make the
api more difficult. It just gives it a bigger scope since which you
won't need you simply don't use but it is there for those who want 
to do more advanced multi media programs.

As an example rhythmbox is one of those more advanced applications that
use monkey media for all their multi media functionalities but recently
i've been writing a tiny player just to learn some more about gtk and 
monkey-media and i must say it fits there as well. It's very simple but
also gives you control where you want it. Yes monkey-media is more than 
a play_this_file (const char *filename) api. But i think media
applications also want more than such an api. Also monkey-media is
very nice because it reduces the code duplication. Where in the past
every player, recorder or just in general every multi media application
had their own methods of doing their things you can now use monkey-media
not only as an higher level gstreamer development thing. But also for
things that aren't in the scope of gstreamer as i said before reading 
and editing tags and not to forget cddb stuff. 

How neat would it be if a simple application can embed kickass 
visualizations via a simple gtk widget using monkey-media functions
it's just all making it very easy for the developer multi media lib.
Not only as a wrapper for gstreamer but beyond the scope of gstreamer

> I find it bizarre that people are insisting that all Gnome media apps
> should use monkey-media because that throws away all the power and
> flexibility that GStreamer provides in the first place. If someone
> writes a GStreamer based video player that meets all of gnome's needs it
> doesn't matter one bit if monkey-media is sitting in the middle or not.

Actually it isn't that bizarre seen monkey-media offers a SIMPLE api
while gstreamer offers a POWERFULL but low level api. As i said before
i don't want to do a gst_element_connect_many neither i want to know
which elements are involved and in how they are connected. I don't 
want 10 lines spilled to element construction what i want is just a
few lines to load the stream and an api to manipulate it. As in play,
stop, pause, play at this point in the stream etc etc.

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.

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.

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.

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

> Now that I've let off that steam I can say that there will be a basic
> playlist added to gst-player, but it will not be visible in the nautilus
> view since the view should only ever be invoked on single files.

Nice to hear that, it's always very nice when you can queue a few small
pron avis so you don't need to select a new one all the time *grin* =]

Well it seems i've been kinda repeating my point of view but what the
heck. Hopefully it's clear but don't hestitate to suggest or give
comments. This is an important matter because we NEED multimedia in
gnome.

Cheers,
Dennis (sienap).