[livesupport-dev] the state of gstreamer in LiveSupport - Airtime Development Discussions on Sourcefabric Forum

import

after such a log wait, here's an update on the state of gstreamer
support in LiveSupport.

I've created a gstreamerElements module, which include some module I
wrote that needed for us. the most important one is a minimal audio SMIL
player gstreamer element, that is supposed to support the audio-related
subset of SMIL that we need in LiveSupport.

currently the elements are capable of the following:

- automatically recognizing and playing the following ifle formats:
- mp3
- ogg vorbis
- smil (our subset, of course)

- playing this on any ALSA device, on multiple devices simultaniously

- support for cue points (e.g. not starting at the beginning of the file
but later, not ending at the end but sooner)

- playing files parallely

- playing a file after some silence (say, 3 sec silence, then start)

our SMIL support so far goes to the following:

- playing the following file formats inside SMIL files:
- mp3
- ogg vorbis
- playing files parallely
- playing files at an offset

this enables our basic use of playlists. functionality that's missing:

- volume envelope, for fading
- embedded (recursive) SMIL playlists

during my struggle with gstreamer, a number of bugs have been found in
the library itself. I've posted these to the gnome bugzilla, mostly with
patches. hopefully they'll include these patches eventually in
gstreamer. the bugs filed are:

http://bugzilla.gnome.org/show_bug.cgi?id=304993
http://bugzilla.gnome.org/show_bug.cgi?id=305658
http://bugzilla.gnome.org/show_bug.cgi?id=308049
http://bugzilla.gnome.org/show_bug.cgi?id=308167
http://bugzilla.gnome.org/show_bug.cgi?id=308193
http://bugzilla.gnome.org/show_bug.cgi?id=308312
http://bugzilla.gnome.org/show_bug.cgi?id=308619
http://bugzilla.gnome.org/show_bug.cgi?id=308663
http://bugzilla.gnome.org/show_bug.cgi?id=308766

currently there's one nasty hack in the code, it involves some wierd
thing I don't necessarrily understand about different states of
gstreamer elements.

as compilation of gstreamer was quite a big challange on Mandrake and
Debian, I've remove the gstreamer dependencies while still at Prague
from our build system. the question now is if I should add it back, as
Ferenc seem to have succeeded in compilation.

Akos

------------------------------------------
Posted to Phorum via PhorumMail

import

If the gentoo ebuild for gstreamer is any indication, the dependencies
don't look that bad, I see the following dependencies &
subdependencies:

gstreamer-0.8.9
|_glib-2.2
|_libc
|_libxml2-2.4.9
|_zlib
|_python (optional)
|_readline (optional)
|_popt - 1.6.3
|_gettext

I don't think glib/libc, libxml2, zlib, gettext, and popt (whatever it
is) are too much to ask... Don't most distributions include libxml2,
zlib, gettext, and glib? ...if not, they all at least have the option
(ie, it's in their package repositories, readily available).

Also, how will these gstreamer modifications affect those of us with
existing gstreamer installations? Just curious...

------------------------------------------
Posted to Phorum via PhorumMail

import

jxn sly wrote:
> popt (whatever it is)

http://directory.fsf.org/libs/popt.html

Popt - Library for parsing command line options
The popt library exists essentially for parsing command line options.

--
-------------------------------
Michael Schultheiss
E-mail: livesupport@amellus.com

------------------------------------------
Posted to Phorum via PhorumMail

import

jxn sly wrote:
> If the gentoo ebuild for gstreamer is any indication, the dependencies
> don't look that bad, I see the following dependencies &
> subdependencies:
>
> gstreamer-0.8.9
> |_glib-2.2
> |_libc
> |_libxml2-2.4.9
> |_zlib
> |_python (optional)
> |_readline (optional)
> |_popt - 1.6.3
> |_gettext
>
> I don't think glib/libc, libxml2, zlib, gettext, and popt (whatever it
> is) are too much to ask... Don't most distributions include libxml2,

popt is a command line parameter parser, like an advanced version of
getopt()

> zlib, gettext, and glib? ...if not, they all at least have the option
> (ie, it's in their package repositories, readily available).

yes, that's true. on top of these, we'll need libraries for gstreamer
plugins we rely on, like mad for mp3 playback, ogg vorbis for ogg
vorbis. but that's all.

> Also, how will these gstreamer modifications affect those of us with
> existing gstreamer installations? Just curious...

at first we'll be using our own from our tools directory, as I had to
make patches to make it work, which are not yet included in the official
gstreamer distribution. but as they accept our patches, we can change to
the official version later..

Akos

------------------------------------------
Posted to Phorum via PhorumMail

import

Ákos Maróy wrote:
> as compilation of gstreamer was quite a big challange on Mandrake and
> Debian, I've remove the gstreamer dependencies while still at Prague
> from our build system. the question now is if I should add it back, as
> Ferenc seem to have succeeded in compilation.

Well... I wouldn't say that exactly. Apparently some plugin makefiles
hard-code the location of some libraries, eg. /usr/lib/libglib-2.0.so.
I don't know if this only happens when there is a version of glib on the
system (different from livesupport's), or always. I managed to compile
by changing my /usr/lib/libglib-2.0.so link to point to
/home/fgerlits/livesupport/usr/lib/libglib-2.0.so during compilation,
which is quite nasty, and I'm not even sure if it won't lead to a crash
later, when the link is changed back.

Ferenc

------------------------------------------
Posted to Phorum via PhorumMail

import

import

Ferenc Gerlits wrote:
> Well... I wouldn't say that exactly. Apparently some plugin makefiles
> hard-code the location of some libraries, eg. /usr/lib/libglib-2.0.so. I
> don't know if this only happens when there is a version of glib on the
> system (different from livesupport's), or always. I managed to compile
> by changing my /usr/lib/libglib-2.0.so link to point to
> /home/fgerlits/livesupport/usr/lib/libglib-2.0.so during compilation,
> which is quite nasty, and I'm not even sure if it won't lead to a crash
> later, when the link is changed back.

yes, this is quite nasty, and can only be done by root anyway.

we have to find a way to compile it properly on systems that have
earlier versions of related libraries installed...

------------------------------------------
Posted to Phorum via PhorumMail

import

Ákos Maróy wrote:
> yes, this is quite nasty, and can only be done by root anyway.
>
> we have to find a way to compile it properly on systems that have
> earlier versions of related libraries installed...

Yes. I know this so far: gst-plugins has a linker-preprocessor script
called libtool (confusingly; has nothing to do with the "real" libtool),
which takes this:

/bin/sh ../../../libtool --mode=link --tag=CC gcc -g -O2
-L/home/fgerlits/livesupport/usr/lib -o test-gconf
test_gconf-test-gconf.o -Wl,--export-dynamic -pthread
-L/home/fgerlits/livesupport/usr/lib -lgstreamer-0.8 -lgobject-2.0
-lgmodule-2.0 -ldl -lgthread-2.0 -lxml2 -lpthread -lz -lm -lglib-2.0
-Wl,--export-dynamic -pthread -L/home/fgerlits/livesupport/usr/lib
-lgconf-2 -lORBit-2 -lgobject-2.0 -lgthread-2.0 -lm -lgmodule-2.0 -ldl
-lglib-2.0 libgstgconf-0.8.la

and turns it into this:

gcc -g -O2 -o .libs/test-gconf test_gconf-test-gconf.o
-Wl,--export-dynamic -Wl,--export-dynamic
-L/home/fgerlits/livesupport/usr/lib -pthread ./.libs/libgstgconf-0.8.so
/home/fgerlits/livesupport/usr/lib/libgstreamer-0.8.so
/usr/lib/libxml2.so -lz /usr/lib/libgconf-2.so /usr/lib/libORBit-2.so
/usr/lib/libgmodule-2.0.so /usr/lib/libpopt.so
/usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so
/usr/lib/libglib-2.0.so
/home/fgerlits/livesupport/usr/lib/libgobject-2.0.so
/home/fgerlits/livesupport/usr/lib/libgthread-2.0.so -lpthread -lm
/home/fgerlits/livesupport/usr/lib/libgmodule-2.0.so -ldl
/home/fgerlits/livesupport/usr/lib/libglib-2.0.so -Wl,--rpath
-Wl,/home/fgerlits/livesupport/usr/lib

The gstreamer package itself has this libtool thing, too, but it doesn't
seem to cause any damage there. The libtool script is generated from
ltmain.sh (in the root of the gst-plugins-0.8.9 directory) by configure.

Ferenc

------------------------------------------
Posted to Phorum via PhorumMail

import

Ákos Maróy wrote:
> after such a log wait, here's an update on the state of gstreamer
> support in LiveSupport.

I made some progres in ebuilding. Currently I'm targetting the Gstreamer
implementation straight from CVS. Some makefiles get altered on the way,
because they use the ${USR_*} too often for stuff that should already be
on the system (or should be in ./configure).

There is now an ebuild for xmlrpc++ and if needed I'll make a new odbc
ebuild too, I first need to know what has changed on the -mt branch anyway.

If someone could help me with the following:
-Default gentoofied (working) configurations
(ebuild livesupport-20050525.ebuild config)

If this is done, we basically have a decent ebuild ready for 1.0.

Stefan

------------------------------------------
Posted to Phorum via PhorumMail

import

OK I have managed to build the beast, now I'm wondering what the XML
syntax is for the Gstreamer player Smile

Stefan

------------------------------------------
Posted to Phorum via PhorumMail

import

Stefan de Konink wrote:
> OK I have managed to build the beast, now I'm wondering what the XML
> syntax is for the Gstreamer player Smile

see modules/playlistExecutor/etc/gstreamerPlayer.xml:

]>
/>

------------------------------------------
Posted to Phorum via PhorumMail

import

On Thu, 2005-06-23 at 22:14, Ákos Maróy wrote:
> after such a log wait, here's an update on the state of gstreamer
> support in LiveSupport.
>
> I've created a gstreamerElements module, which include some module I
> wrote that needed for us. the most important one is a minimal audio SMIL
> player gstreamer element, that is supposed to support the audio-related
> subset of SMIL that we need in LiveSupport.

Because of the gstreamerElements is not yet be in the Makefile.in what
do i need to run for a test compile. Is it just a bin/autogen.sh a make
and make test?

Thanks,

Frans van Berckel

------------------------------------------
Posted to Phorum via PhorumMail

import

Frans van Berckel wrote:
> Because of the gstreamerElements is not yet be in the Makefile.in what
> do i need to run for a test compile. Is it just a bin/autogen.sh a make
> and make test?

I've got some patches for it. Basically it removes Helix from the
Makefiles and includes. And removes the comments around the gstreamer code.

Stefan

------------------------------------------
Posted to Phorum via PhorumMail

import

Frans van Berckel wrote:
> Because of the gstreamerElements is not yet be in the Makefile.in what
> do i need to run for a test compile. Is it just a bin/autogen.sh a make
> and make test?

cd modules/gstreamerElements
./bin/autogen.sh
make
make check

------------------------------------------
Posted to Phorum via PhorumMail

Howdy, Stranger!

Categories

Poll

Top Posters