summary of the aKademy meetings

[Scott Wheeler]

On Monday 06 September 2004 19:20, Marco Lohse wrote:
> I would just like to add some points as seen from the NMM viewpoint:
> 
> - Gstreamer autoplugging: The upcoming release of NMM will provide a new 
> GraphBuilder that automatically creates a flow graph from a given URL. 
> Furthermore, it will also allow to create a distributed flow graph, e.g. 
> having audio/video output on remote hosts, or, access remote data 
> sources. We hope to finish the release this week.

It'll be interesting to see how this pans out as it's generally a pretty 
difficult problem; I'll certainly take a look at the implementation once it 
shows up.  I assume you'll CC the release announcement here.

> - 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).

> Also, I do not understand why people that are strictly against the 
> abstract player interface that supports various backends (such as 
> Gstreamer, NMM, xine, and so on) vote for the C++ bindings of Gstreamer 
> to be used. Just imagine: say, you create one-to-one bindings first (by 
> the way, a huge effort, I would say). Then, you decide to make these 
> bindings, well, a little bit more 'high-level'. Then, again, a little 
> bit more. Well, then finally you will be at the point where you 
> 're-invented' the abstract player interface (of course, you might want 
> to add other abstract interfaces, too).

That's basically my thinking too.  While there's a "simple" KDE GStreamer API 
in kdenonbeta/gst/kde/gstplay it's basically just a stripped down version of 
what we've got in kdelibs/kdemm now.  I don't see any reason to continue to 
support that interface in future bindings rather than just using the kdelibs 
API.

-Scott