[gst-devel] Re: [gnome-love] GStreamer plans and TODO

[Bastien Nocera]

On Sat, 2003-04-19 at 11:19, Christian Fredrik Kalager Schaller wrote:
> Hi,
> So as mentioned this list is an attempt to put together the most
> important pieces we need to get into GStreamer 0.6.x and GNOME 2.x
> series for it to provide maximum service to the applications that people
> use with it. This list is put together with the needs of these
> applications in mind:
> Gst-player and Totem
> Sound Juicer
> GNOME Media
> Nautilus/Nautilus-Media
> Rhythmbox,Net-rhythmbox, Lymric
> Marlin

Happy to see that Totem is on the map now :)

> GStreamer plugins that needs fixing for gst-player/totem:
> Make auparse work in gst-player
> Make flxdec work in gst-player
> Make Make swfdec work in gst-player
> Make audiofile plugin work so it can provide aiff support to player, or
> make an aiffparse plugin
> 
> Hook up ffmpeg decoders for WMA, Quicktime, Real and ASF

That's an afternoon's job for a clueful person. Real and ASF would need
demuxer before they're actually any use.

<snip>

> New plugins that would be nice for Soundjuicer, Sound-recorder and maybe
> Marlin:
> an au encoder
> an aiff encoder

I don't actually think these would be any use to Sound Juicer.

> Fixes that would be nice for Rhythmbox and relatives
> Ape metadata/tag collection
> Flac metadata/tag collection
> Writing of metadata using GStreamer
> Make ape plugins work on PPC (non-Intel in general?) so it can be moved
> into 0.6.x series
> 
> Fixes needed in Nautilus-media:
> Better error handling of unsupported formats, for instance when people
> try using it to play mp3's under RH9 they should get a more intelligent
> message on why it can't.

Does nautilus-media use spider? I think it's a problem with the
autopluggers in general that they need better error handling.

> Portabiliy issues:
> Move to speciallib
> Maybe make a libao plugin to get a sound output option with
> autodetection and wider native platform support

Libao would help GStreamer work on other platforms, yes, but
autodetection is easier than that. You probably need some help from
either the autoplugger, or an helper library. And it would go like:
try OSS, if doesn't load/work (plugin not present, device busy)
use ALSA, if it doesn't load/work
use ESD, etc.

> GNOME 2.x and GStreamer integration opportunities:
> Audio CD playback.
> Moving the GNOME CD player and the cd player applet to using GStreamer
> would be nice, make sure however to not cause a regression for Sun etc.
> by this move.

I'll reiterate an idea I submitted during the Totem/Gst mails from
d-d-l. Port the CD plugin from xine. It supports plenty of different
platforms (*BSD, Linux and Sun, at least, afair), and it is more
suitable for playback than something like cdparanoia is.

The code is easy enough to understand, and all the hard work with
porting is done.

> Getting Nautilus to use GStreamer for the music preview would both give
> a nice boost in supported formats and potentially solve a lot of bug
> reports on Nautilus.
> 
> Make it possible to embed Beast/BSE into GStreamer pipelines. Probably a
> rather big task, but it should be rewarding.
> 
> There are both a Mozilla plugin and a Nautilus view/Bonobo component of
> the Gst-player, both needs love to actually work at a production level.

I would love it if the Mozilla plugin could go in Totem, rather than
being based directly on gstplay. That would mean that both Totem/xine
users and Totem/Gst users would benefit from the plugin.

In any case, if the move is not to happen, a Mozilla plugin is on my
TODO list (see README). So is a simple webcam application which would
allow live playback and periodic snapshots.

What this would allow us, is to have the reliable xine backend to help
us develop GStreamer and the applications. Is it the program's fault, or
is it the backend's would be an easier to answer question.

> Maybe the sound server capplet in GNOME should be made to update the
> gstreamer sound output gconf key. So when people choose to
> activate/deactivate the sound server then GStreamer follows that. Do
> give some audio/video sync issues however due to limitations in esd.
> Could be that this should be postponed til after MAS or similar is in
> place.

Output should be autodetected, and capplets scrapped. ("Just work")

-- 
Bastien Nocera <hadess at hadess.net>