[Fwd: Re: [Rhythmbox-devel] monkey-media future]

[Bastien Nocera <hadess hadess net>]

Thought it'd be a good idea to talk about it here.
-- 
/Bastien Nocera
http://hadess.net

#2  0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
Segmentation fault

--- Begin Message ---

• From: Bastien Nocera <hadess hadess net>
• To: in7y118 public uni-hamburg de
• Cc: Bob Smith <bob thestuff net>, Rhythmbox Dev <rhythmbox-devel gnome org>
• Subject: Re: [Rhythmbox-devel] monkey-media future
• Date: 31 Jul 2003 17:48:19 +0100

Hello Ben,

On Thu, 2003-07-31 at 13:38, in7y118 public uni-hamburg de wrote:
> GStreamer should and will do all of this.
> But generating a playback pipeline is more code then just calling playback_file 
> (filename);

Agreed.

> What Gnome (and GStreamer, too) really is in need of is a library that 
> abstracts common multimedia tasks and makes them easy to use in YourApp(tm).

That's why I want to make the widget more public than it is now.

> However it needs to still be flexible enough if it wants to support media 
> players.

Nod.

> The needs for such a lib from my point of view:
> - simple API for audio and video playback of anything (files, streams, audio 
> recording, ...)

Ok, it does that already.

> - widgets to control the playback or view information about the playback (time 
> slider and display, video output, ...)

Only the video output is in there. Time slider and display?

> - extensions for this (volume widget, visualization, equalizer and user defined 
> stuff, buffering for internet streams (?))

there's buffering signals already, I might add equaliser support (not
sure yet).

> - metadata retrieval

It's there in some way for the currently being played stream, and will
also be in the object. It doesn't do writing though. But I hope Thomas
will clear that for us soon with his own library.

> (- playlist functionality?)

Something like TotemPlaylist (ex-GtkPlaylist, as used in gst-player), or
something different? I don't see the point here.

> There's a bunch of things that I think are problematic with the current Bacon 
> approach (I have never looked at the code though):
> - I don't know how easy an abstraction of media frameworks is. Some things 
> might be solved completely different in different frameworks and you might have 
> to go along way to mimic the feature bit by bit in another one. I personally 
> prefer a lib that mimics the GStreamer way (what a surprise, eh? ;)) but bacon 
> is engineered to work with xine.

The BaconVideo stuff tries to be an easy-to-use media playback tool. It
will not be as featureful as xine is, or even as much as GStreamer is,
that's not the goal.

I try to have the API as Gtk-ish/Glib-ish as possible, maybe I failed
sometimes, that's why I'm asking for comments.

> - The bacon stuff is a video generalization. So it has a lot of overhead and 
> bugs from the video part that Rhythmbox doesn't need.

bugs from the video part? which ones? :)
And I think that we want a visualisation part in rhythmbox, so we will
need video in some way. Overhead is negligeable.

> - A lot of the functionality of the current bacon stuff is in libgstplay (at 
> least for the GStreamer part). There is no need in duplicating those 
> functionality so I would prefer if those two were merged. Especially from the 
> bugfixing and release standpoint.

Yes, it's only that libgstplay is even lowerlevel than the bacon widget.

> And a last personal point:
> - I wanted to test new Gstreamer HEAD functionality in Rb. (That's why I'm 
> coding it anyway) If there's a lib in between I would have to implement those 
> features there first and I'm obviously neither a dev of libbacon nor do I know 
> whether there is a desire to develop against unstable and new features.

What sort of functionality do you want in there that wouldn't be
available in the current API?

> So, in short: I think it depends on the scope and design of libbacon if it 
> makes sense to use it.

You can influence the design. The scope is simple: "Media playback". Not
do-it-all media framework.

> A last question: Are there any design docs (I'll take .h files, too) for the 
> new design somewhere?

totem/src/bacon-video-widget.h

The main point of the "new design" is to:
- remove X deps when not needed (no visible video output, music playback
without visualisation) -> Object
- headers/API cleanups

Let us know what you think.

Cheers

-- 
/Bastien Nocera
http://hadess.net

#2  0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
Segmentation fault

_______________________________________________
rhythmbox-devel mailing list
rhythmbox-devel gnome org
http://mail.gnome.org/mailman/listinfo/rhythmbox-devel

--- End Message ---