[gst-devel] Componentization

Bastien Nocera hadess at hadess.net
Wed Aug 15 00:53:04 CEST 2001


Erik Walthinsen wrote:

> I've read through the thread on componentization, and I have a couple
> comments:
> 
> First, the long term plan from my end is to create a better libgstplay.so.
> This already exists, and is used as the basis for the (very small)
> gstmediaplay program.  libgstplay.so is about 750 lines, and the player is
> another 750, not including a custom widget that seems to be of debatable
> necessity.
> 
> Arik Devens is the maintainer of the player, and has put out a call for
> discussion on writing a new libgstplay.  The idea is that it would handle
> all pipeline-related issues of the most common features of a player,
> including deal with autoplugging (handling arbitrary media types), seek
> control, ancillary information (id3, etc.) gathering, and so on.


Ah, that's interesting. I hit a problem with RhythmBox. All media 
playing goes through gnomevfssrc (hehe, that's why I wrote it in the 
first place <g>), but I have to use libcdaudio to gather CDDB 
information, libmp for id3 tags and libvorbisfile for the vorbis 
comments. And the 2 latter aren't even gnome-vfs aware so I will have to 
extend them at some point so I can actually have a fully compliant app.

mp3parse is there, and could provide info about id3 tags, the oggdec 
probably could as well (from what I've read of the ogg vorbis api anyway).

What I'd like to see is a well-defined (and full-featured) set of 
information that the decoder plugin can provide to the application.
For example for RhythmBox and Ogg/MP3 files I need:
- title of the song
- artist
- album
- genre
- comment
- size
- bitrate
- date of the record (year for mp3, full date with ogg)
- length (duration)

you can probably add codec, dimensions (for video streams), and probably 
even more.

Can you tell me what your ideas are for gathering metadata from streams ?

(Of course the problem is the same with video files, etc. Just talking 
about my personal experience in this case)


> What I see is that libgstplay (and other similar libs for things like
> media conversion, i.e. CD to Vorbis, or the infamous DVD to DiVX) would be
> the units that are shimmed into either Bonobo or XPCOM.  The key then is
> to make sure that the libgstplay.so interface is capable of what the
> mozstreamer and nautilus and other plugins require.  Among other things,
> this means explicit control over sources and sinks.
> 
> I'd like to see the interface requirements for libgstplay.so hammered out
> pretty soon, so progress can continue on the player.  Probably should be
> discussed in the gstreamer-devel list, copied to the mozstreamer list.
> The existing mozstreamer code would probably provide a very good basis for
> rebuilding libgstplay, as well.

Cheers





More information about the gstreamer-devel mailing list