Re: designing a wrapper lib

[Jorn Baayen <jorn nl linux org>]

On Wed, 2002-09-18 at 22:02, Wim Taymans wrote:
> On Wed, 2002-09-18 at 20:43, Jorn Baayen wrote:
> > Hi,
> > 
> > Assuming everyone agrees we need to use one wrapper library for all
> > gnome core apps, I want to start up a brainstorming session on what we
> > want to have in the lib (let's just call it gmedialib for now, to avoid
> > any references to either mm or gstplay). When we have a list of things
> > we need we all agree on, we should start to design an API, implement it,
> > and push it as new standard lib.
> > 
> > Please, if you disagree we need to use one single library, reply and
> > discuss why you think we need multiple. (We're talking about the core
> > desktop lib here, we definetely need an embedding lib (gstplay?) as
> > well, but that's not what gnome-multimedia is about, IMHO).
> > 
> > To start with, here are a few things I could think of. If you think they
> > dont belong here, just start a discussion.
> > 
> > - simple audio/video playback
> > - gapless transition/crossfading (Not sure about this one, at least RB
> > will need it, but i can imagine other apps needing it. It's just a very
> > nice feature that would ideally Just Work on any mediaplayer.)
> > - relative volume
> > - equalizer backend, perhaps a widget as well?
> > - visualization
> > - good audio cd support (with things like eject and cd availability
> > signals as well)
> > - metadata reading and writing
> > - internet radio support
> 
> Jorn, you're designing an app.
> 
> Allow me to make this little analogy (with flaws, as with all analogies,
> but you'll get the point).
> 
> pretend: GStreamer~=GDK/GTK
> 
> What you're designing is a set of custom widgets/dialogs for, say, your
> 'mail reader' app and hope to have that other, say, 'newsgroup reader
> app' reuse as many of the dialogs as possible, which is fine... I'm not
> interested in another mail reader, I want to make a, say, spreadsheet
> app. Are you forcing me to use your lib with dialogs? 
> 
> What I'm saying is that Gtk/Gdk is equally lowlevel as GStreamer yet we
> don't build many applications solely around libraries of GtkWindows.

While this is ofcourse a valid point, this is not what, in my idea, the
mm lib would be about.
Only a small part of the lib would wrap gstreamer, say 20% of the actual
code. This would be actual the playback code. The rest of the library
would be audiocd services like open tray, close tray, get number of
tracks, and metadata. This stuff is not in gstreamer, and IMHO it would
suck badly if this had to be copied into every app.

Also, obviously the library is not meant for any kind of mm app within
gnome, just playback apps. It would not make sense to make a less
flexible layer on top of gstreamer for any and every mm app, but, I
think, it would be nice to have a lib with some nice utilities so you
dont have to create a pipeline with error handling and blah blah in
every app yourself just to play a simple file.

> 
> Are you saying that my (one of my mid-term goals) VirtualDub clone
> should use that single library of yours? I can give you some of my
> requirements then... Are you also saying that my (one of my long-term
> goals) NLE library should use that single library of yours too?

No, definetely not.
 
> 
> GStreamer is the lowest common denominator between multimedia apps, be
> open to that fact that all generalisations have limited scope (player
> lib, monkey-media, NLE lib, gst-record, dj turntables, RT guitar
> effects,...). 

Sure. Like I said before, the lib obviously isn't meant to be a complete
simplifying blanket on top of gstreamer for every app. This would be
totally silly.

> 
> I don't believe in the one-library-for-everything approach. I do believe
> in simple _play_URI type of APIs for people that just want to play a
> sound/video, whatever. The mixing/crossfading thing is too limited in
> scope, nobody other than RB is going to use that. The other requirements
> are RB requirements IMO, or are you suggesting we create N apps to play
> and mix a collection of mp3s?

eq, vis and crossfading may be too app specific, although it would be
nice to have equalizer and vis readily available. (Eq would be nice too
for a video player, if you want to turn the bass down to not wake the
neighbours up, for example)

About crossfading you probably are right, although gapless transition
would be really nifty for any app using playlsits. If it just worked out
of the box, this would IMHO be pretty nice. But, this is ofcourse me
talking as RB dev.. I may very well be on bad crack here.

> 
> This discussion is turning into a debate of what other multimedia
> applications RB should assimilate in a lib, instead of focusing on what
> the requirements are for multimedia in GNOME.

Again, this is not what I want ..


Cheers
Jorn

> 
> my list of provided mm services in GNOME: (short term)
> 
>  - cd-player (run and forget, it just plays the damn cd)
>  - mp3/ogg/.. player on steroids with mixing, visualisation, playlists,
>    etc.. and no, I don't want all my mp3 ID3 tags parsed in my playlist
>    and the mixing stuff and vis plugins and the gconf keys for default
>    audio device and relative stream volume and the equalizer and the
>    metadata editing stuff when I just want to play my cd or do a beep.
>  - play_URI type of lib for apps to use (think instructional
>    video/audio track)
>  - app to quickly preview any type of media you throw at it (based on
>    the play_uri API), embedable, bonoboized, scriptable but simple. 
>  
> long term:
> 
>  - mm authoring app (NLE for audio/video, transcoder, tag/metadata
> editor, targets include cd/dvd burner, ...)
> 
> My 2 cents,
> 
> Wim
> 
> 
> 
> > 
> > Cheers
> > Jorn
> > 
> > _______________________________________________
> > gnome-multimedia mailing list
> > gnome-multimedia gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-multimedia
> > 
> 
> 
> 
> _______________________________________________
> gnome-multimedia mailing list
> gnome-multimedia gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-multimedia
>