summary of the aKademy meetings

[Marco Lohse]

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.