Comparison: MAS, GStreamer, NMM

[Marco Lohse]

Christian Fredrik Kalager Schaller wrote:

[..]

>  
>
>I would think this is the least interesting thing to look at in this
>setting cause if the Qt style bindings to GStreamer (or if someone made
>Qt style bindings for MAS) isn't exactly what you want you can change
>them to fit what you want in the coming year. In his talk at the
>conference Mathias Ettrich said that in some was Qt was basically a
>binding to a lot of different C libraries, I remember he mentioned
>freetype as one. So basically you should be able to get a Qt binding
>that is just as good and comfortable as the rest of Qt for you to
>program in and with. The important things for KDE to evaluate IMHO,
>especially considering that KDE 4.0 is just a year a way is features,
>maturity, interoperability, viability and cross-platform support.
>
>  
>
It is interesting that you mention bindings, because one motivation for 
developing NMM was to provide high-level C++ bindings to all these 
multimedia C libraries that run inside our plug-ins, e.g. for encoding 
and decoding.

Concerning maturity, etc. : yes, these are certainly very important 
points for projects like KDE. And its up to the people from KDE to 
decide about this. However, to do such a decision, one has to develop 
some test programs. Getting familiar with the development using MAS, 
GStreamer, or NMM (and making life easier) was the intention of starting 
this comparison.

[..]

>  
>
>>    
>>
>Yes, but I am not so sure that in most of these cases having the media
>framework on both sides is the right solution. For the thin-client
>scenario for example I think having a lightweight limited functionality
>media server client is the better solution and then have the media
>framework on the other end do the needed transcodings and adaptions in
>order for that light client to be able to play/display what you are
>sending it. 
>
>My way of solving the exact demo done at the conference would be to have
>a deamon running which offered a rendevouz/zeroconf services which it
>broadcast over bluetooth/wlan. When you then arrive with your handheld
>which has bluetooth/wlan it would inform the owner that X number of
>services was available and ask if she/he wants to transfer the stream to
>any of them. I guess you don't really want to be playing from your PDA
>when you get home anyway, so I guess adding some functionality which
>transfered the playback to the sound collection on your central
>server/machine would be the final solution to the issue I guess.
>
>  
>
Yes, as I mentioned in my talk, you can use traditional client/server 
streaming approaches to develop such applications. However, it is not a 
question of if you can realize such applications with the client/server 
approach, it is a question of how easy (or painful) it is to do so.  Or 
if other programming models are better suited. Also, you mainly speak 
about service discovery, which is to some extent the easiest step, 
because there exist many working solutions out there that can be used. 
The 'services' you speak of are mainly black-boxes: you have to discover 
what kind of functionality they offer, what kind of media data they 
allow to receive and they will provide, ...

What you do not mention - and what also needs to be provided to develop 
demos like we showed at the KDE conference - is:
* Type-safe control interfaces for distributed components (e.g. for 
controlling the DVD menus conveniently)
* Type-safe connection between your application and the 'service'
* Sharing of parts of running applications (e.g. flow graphs)
* Distributed synchronization between different applications
* Seamless handover of media playback between different devices

To make this more clear:
First of all, for purely local DVD playback, you will have to write an 
application (the flow graph aka pipeline). Also for TV, you will have to 
do that. This work has to be done using whatever multimedia framework 
you use. Then, using your 'services' to provide distributed 
functionality you would need to write a service for remote access to TV 
and a service for remote access to DVD (e.g. because TV allows to change 
channels, DVDs allow to navigate within menus). You are also fixed to 
where work like transcoding is done (e.g. transcoding needed for the 
mobile client is done on the host the service runs on?). And you still 
need to solve all the other issues pointed out above.

NMM uses a completely different approach: You will only have to do the 
work needed for local DVD playback or TV once (e.g. provide the flow 
graph). Plus you need to add 2-3 lines of code to distribute that 
application (distributed flow graph). Or 2-3 more lines to share your 
application (shared distributed flow graph).

Have fun, Marco.