From kde-multimedia Mon Sep 06 15:04:40 2004 From: Christian Fredrik Kalager Schaller Date: Mon, 06 Sep 2004 15:04:40 +0000 To: kde-multimedia Subject: KDE multimedia backend - GStreamer viewpoint Message-Id: <1094483080.11353.38.camel () cschalle ! fluendo ! com> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109448309020478 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 _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia