[gst-devel] GStreamer as Google Summer of Code project

Christian Fredrik Kalager Schaller uraeus at gnome.org
Wed Apr 19 04:56:01 CEST 2006

On Tue, 2006-04-18 at 17:03 +0200, Stefan de Konink wrote:
> On Tue, 18 Apr 2006, Christian Fredrik Kalager Schaller wrote:
> > My idea was the second, but it could be my description needs more
> > thought and the implementation path should be different. Wim just told
> > me that making this into a gnonlin element would make more sense
> > probably.
> >From a chat with one of the authors of Ambulant, the current
> implementation has got a 'dump' function. So technically it would be
> rather simple to 'sample' output from the library and place it into a
> pipeline.
> Some additional subjects were; SVG support (based on Inkscape) into the
> Ambulant player and using Gstreamer as 'backend' like FFMPEG is now. Then
> again; Ambulant claims it is feature rich, but from my own experience it
> is far from bugfree and has some very basic design difficulties.
> (Design problem is for example rendering alpha channels on the
> backend instead of keeping them transparent, transitions look funny then)
I guess my goal would be that we end up with something that enabled SMIL to be playing
in Totem without any changes to Totem itself.

> IMHO it would be a great idea to use gstreamer as the backend for
> Ambulant and thus getting the SMIL2 part into a parser element.
> The point I personally got stuck with Gstreamer was prototyping my SMIL
> application into a gst-lauch pipeline. Incompare to for example
> Real-Helix-memleak-player, gstreamer was so slow/cpu intensive with
> overlaying multiple video streams. Maybe a chat on IRC/Jabber would be
> good over this topic.
The videomixer element could probably do with some optimization work 
according to Wim. Maybe something else to try to make a SoC project
of :)


More information about the gstreamer-devel mailing list