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

Christian Fredrik Kalager Schaller Uraeus at linuxrising.org
Sat Apr 19 09:05:04 CEST 2003


On Sat, 2003-04-19 at 15:34, Bastien Nocera wrote:

> Happy to see that Totem is on the map now :)
My pleasure, just do the job to keep it there ;)

> > 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.
No, nautilus-media do not use spider it uses fixed pipelines afaik.

> > 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.
Can I mark you down as doing the port of this plugin? ;)

> > 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.
Yes, along as the Xine backend isn't used as an excuse to not get something
done in GStreamer.

> > 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")
Some autodetection is ok, but there is nothing better than a working
default :)

-- 
Christian Fredrik Kalager Schaller <Uraeus at linuxrising.org>





More information about the gstreamer-devel mailing list