Re: Gnome Media Library

> # The first thing that SHOULD be done, is to settle or implement standard
> # file loading libraries for video and audio, like gdk-pixbuf is de facto
> # standard for images. It is extremely inconvenient, if every simple
> # requires different kind of libraries simply for loading .mod tunes.
> You might want to briefly skim over the way BeOS does things - a lot of
> its APIs are centered around A/V file handling and it has a very nice
> pluggable architecture. Perhaps there's some things in there that GNOME
> can learn from?

If you look at the homepages' links section, you will find a link to the
BeOS documentation. I read through it and really liked it.
> For example, there's a generic utility (its name escapes me) which
> converts from one digital media file format to another - say, for example,
> QuickTime movie to Intel Indeo-compressed AVI. The utility itself knows
> nothing about the various formats involved; it just knows how to
> read/write "multimedia" files. The libraries do the actual dirty work, and
> the capabilities (formats supported, codecs, etc), are all not a whole lot
> more than plug-ins.

This scalable architecture is a neccessity for extendability of the system
(e.g. If someone makes a DV codec, any application can immediately use it.

> I can't be the only one out there that thinks that this is:
> a) Pretty neat :-)

Microsoft does it the same way. However their interface is a bit - uhm -
> b) A very sensible way of doing things
Actually, there is something very much like it for Gnome - its called
Gstreamer and lives at
The only bad thing about it is that it is a bunch of Gtk classes rather than
a bunch of CORBA interfaces.

> This way, applications generally wouldn't have to know or care what format
> their audio or video files are in - so long as the libraries can handle
> them. As far as applications are concerned, they have a generic audio or
> video stream that can be manipulated in a standard way. So, if your game
> ships with 8-track MOD files for its background music, there'd be no real
> reason why you couldn't replace them with 32-track XM files a little while
> down the line, with no extra programming required, no modifications
> required to the application (except if it used hard-coded filenames,
> perhaps).
> This kind of flexibility is great from an application developer's point of
> view, and even better from the user's.
> Or am I off on one of my meaningless rants, again? :-)
No - this is exactly the kind of thinking I would like to get going...

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]