From kde-multimedia Tue Sep 07 06:28:00 2004 From: Marco Lohse Date: Tue, 07 Sep 2004 06:28:00 +0000 To: kde-multimedia Subject: Re: summary of the aKademy meetings Message-Id: <413D54F0.8080308 () cs ! uni-sb ! de> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109453827509123 Scott Wheeler wrote: >On Monday 06 September 2004 19:20, Marco Lohse wrote: > [..] >>- About the C++ bindings for Gstreamer: Where can I actually find these >>bindings? At the Gstreamer page it says: 'The bindings are still under >>development and not yet released.' >> >> > >Those are probably the GTKMM bindings. The KDE bindings are under >kdenonbeta/gst in KDE's CVS. They're still presently for the 0.6 API, but >I've told the GStreamer guys that I'll update them once the API stabalizes >(as I don't have time to update them every few months). > > ok, I have quickly looked at the code. It's basically a 'one-to-one' binding, right? The idea was to provide every single feature of Gstreamer for C++, right? However, it seems that these bindings were never really completed, right? Now, I am not sure if this was already discussed before, but when looking at the bindings, several questions arise: I suppose that the 'new' bindings for the current version of Gstreamer will have to be (re-)written completely by a human. And, they will have to be maintained and updated by a human. And, - since all this is done by human beings - someone will have to fix the bugs introduced in these processes (and you will have bugs, since writing such, well, 'repetitive' code usually leads to a lot of bugs!). And, you will have to provide documentation for the bindings (do not assume that C++ developers are willing to read the documentation for the C API!). And, you will have to provide some examples/helloworlds. At least, if you want to establish this API as some sort of 'standard'. At least, if you want to support the development of all these more advanced applications mentioned (e.g. audio recording/mixing) So, to summarize, this will be a huge effort - I wonder why people are willing to invest so much effort into this and not into some sort of 'meta-architecture', something on-top of other frameworks, something that adds some more value through abstraction. Another question comes to my mind: Some people have stated that the meta-architecture proposed so far (the 'abstract player interface') will not be able to handle more advanced applications. However, let us reconsider what we are talking about. A wrapper for different multimedia architectures. All these multimedia architectures use the same basic principles: you have some sort of plug-ins and you connect these plug-ins to a flow graph (e.g. filereader->decoder->output). You can control these plug-ins (e.g. set a filename to be read). That is basically all. So, there is no reason why we shouldn't be able to provide a meta-architecture (plus a number of backends, e.g. for Gstreamer, NMM, xine, and so on) for exaclty this functionality. And, yes, there will be the possibility to add some plug-ins for visualization to your player. And, yes, you will be able to add some audio effects to your application using this meta-architecture. Remember, it is all about setting up and controlling flow graphs. I am not saying that all applications out there will be supported with this meta-architecture. However, for these advanced applications, developers will pick the multimedia framework they like best anyway. That is how it works right now, isn't it? So, to add some more 'political' statement: choice is good. I do not see the need for only having a single solution for solving a problem. Every solution has its strengths, every problem is different. I am always wondering, if people who try to force their project to become 'the standard' are willing to apply this argument to other areas as well. At least in everyday life, people are quite happy that they do have choices. And also, this worked quite well in the past for software. Just look at mplayer/xine/... , libxml2/xerces-c, ... Have fun, Marco. _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia