[gst-devel] LiveSupport 1.0 released - based on gstreamer, including a SMIL gst element

[Ákos Maróy]

I'd just like to draw your attention to the 1.0 release of LiveSupport,
a radio broadcast support tool. The generic home page for LiveSupport is
http://www.campware.org/en/camp/livesupport_news/, while the
developer-oriented page can be found at
http://code.campware.org/projects/livesupport/


LiveSupport uses gstreamer as it's audio playing library, and supports
mp3, ogg vorbis audio files, and playlists. Playlists are played in a
subset of the SMIL format.


We've developed our own minimal audio SMIL gstreamer element, as there
was no SMIL element as yet for gstreamer. We also had to write a couple
of other elements, and patch a number of existing gstreamer elements.
You can find the our gstreamer element sources under the
modules/gstreamerElements directory in the LiveSupport source tarball,
or browse our subversion repository here:
http://code.campware.org/projects/livesupport/browser/trunk/livesupport/modules/gstreamerElements/src/


our patches against the gstreamer sources can be found here:
http://code.campware.org/projects/livesupport/browser/trunk/livesupport/tools/gstreamer/gstreamer-0.8.10/etc/
all of witch have been submitted to the gstreamer bugzilla as proposed
bugfixes.


I'd like to thank the gstreamer team for all their efforts in developing
this project. I wonder if the LiveSupport project could get on the
GStreamer applications page among other projects that use gstreamer:
http://gstreamer.freedesktop.org/apps/


I also have a few questions and issues I'd like to raise, and maybe get
some input on how to carry on.


- capability negotiation efficiency

during performance testing, we've found that more than 50% of the time
was used for capability negotiation, and handling capabilities lists
when using a bit elaborate structure of gstreamer elements. this
sometimes resulted in negotiation times of over 10 seconds!

this kind of lag was just simply not acceptable in a live radio studio
environment. I had to spend considerable time trying to optimize the
process, while I was told on IRC that caps nego on gstreamer 0.8 is
borked, and I should wait for 0.9.

while capabilities negotiation time is now generally below .5 seconds,
it would still be better if it was lower than this. which way should we
go? should we try to be early adopters of 0.9, or try to do some more
optimization in 0.8?


- typefind fixation

one problem I bumped into was that while using typefind elements to
connect sources to (eventually) the sound card, whenever I set the
elements out of PLAYING/PAUSED state, they would lose their knowledge,
and would start typefinding again when setting back to READY.

as a workaround, I simply traverse the tree and remove all typefind
elements, and just connect the elements 'around' the typefind I don't
need anymore.

this unfortunately has some side-effects, as it seems that some elements
don't handle reconnecting quite well, see
http://bugzilla.gnome.org/show_bug.cgi?id=308619

I was wondering what our approach should be / how can the typefinding be
fixated? should I patch typefind to include a flag that would make it
'fix', and not try to typefind anymore?


- SMIL: how to read while being paused?

one problem with handling SMIL playlists is that one has to read before
being in PLAYING. as I understand, as an element gets into PAUSED state,
it should have everything set up for playing.

but for SMIL, one has to read the playlist first to know what and how to
set up. I've implemented an element called the oneshotreader, that reads
everything on its source using a bytestream. this is how a playlist is
being read, and it is processed afterwards.

but, unfortunately one can't read into the bytestream before being set
to PLAY. thus, one can't actually set up the resources needed for
playing before being set to PLAY. (as a workaround I usually open for
playing beforehand, wait for the first sample to come out, and set back
to pause. but this is quite ugly.)

I wonder how one should get around this problem? and this is not
SMIL-related, basically all playlist formats would have the same issue,
the major difference being that these are just playlist that describe
what to play, and not the actual media bytestreams.


- 0.8 or 0.9?

I see that most of the activity is going on around 0.9 nowdays. what do
you suggest us to do? try to stick with 0.8 for the moment, or try to be
an early adopter of 0.9? I see that plugins have to update for 0.9 - is
there a list of already available plugins, and / or an update guide?


I'd really appreciate all your input on the above,


Akos