KDE multimedia backend - GStreamer viewpoint

[Christian Fredrik Kalager Schaller]

Hi,
After reading through the thread caused by Scott´s summary I thought I
should chime in with my opinion from a GStreamer viewpoint. 

People can disregard this a ´the GStreamer salespitch' if they want :)

I think KDE should choose to select GStreamer as their multimedia
framework for a variety of reasons, and by choose I mean choose not just
make it the default among a variety of frameworks. 

1. GStreamer have been subject to real-world usage and testing for a
couple of years now. In that time a lot of issues have been addressed
especially when it comes to handling of corner-case media files. I am
not saying that everything is done and perfect, but what I know is that
these things take a lot of time and testcases to fix and that we are
closer than the other options you have listed here. Fluendo are also in
the process of hiring an extra developer through a subsidiary who will
work full time on playback issues for the next months.

2. KDE choosing GStreamer will establish a shared standard media
handling library for Linux/Unix. This means that anyone wanting to add
support for their media format of choice to the desktop just needs to
write one plugin and the applications in both desktops will
automatically support them. Thanks to GStreamers autoplugging features
no code will be needed to add to the applications. In my opinion the
establishment of such a shared standard will increase the quality and
feature completeness of both desktops quickly. Sharing such a framework
will also make it easier to address issues caused by hardware in this
area as there naturally will be less unknowns that needs to be taken
into consideration.

3. Tim Janssen created a set of Qt-style bindings for GStreamer. Scott
Wheeler has offered to maintain them. This gives you IMHO a nice and
clean Qt style API for developing against GStreamer no different from
other functionality Qt pulls in from the system libraries.

4. We are currently aiming towards fixing the last remaining big issues
in GStreamer in order to be able to provide the world with a long time
API stable 1.0 release. Wim Taymans is currently writing a document
outlining our remaining issues and providing detailed explanations on
how we should/could fix them. This document will be proposed to the
GStreamer list before Christmas this year and hopefully lead to a
roadmap towards 1.0 being established and work on as a result. Both
GNOME and KDE wants and demands a long term stable API, we understand
this and are working hard to make it happen.

5. I work for a company called Fluendo which develops commercial
products based on GStreamer. One of the things we are going to provide
are commercial plugins for US patented formats. This means that
distribution makers can license our plugins in order for having their
GNOME and KDE desktops support playing such formats out of the box.
Currently distribution makers are looking at 3rd party options for
getting that support. That said we are no bigger fans of software
patents than anyone else here, but they are there for the near future
and needs to be taken into account. Of course in the meantime we are
doing things like sponsoring Xiph.org to help the development of free
formats.

Sincerely,
Christian