[gst-devel] Re: Comparison: MAS, GStreamer, NMM

[Thomas Vander Stichele]

Hi Marco,

> Sure, there are a lot of users that simply want to play back files. But 
> as stated in my first email, this comparison is intended to compare the 
> programming model and the APIs to be used by programmers.

... but it's worth seeing what you have to do, API-wise, with a
framework, to get it to play back more than one format.  It's quite easy
to play only one format statically; with a requirement like that even
libmad can participate in this test :)

As soon as you want to play *two* formats, though, it's a lot more
interesting to see how you need to use the API to be able to do that. 
Especially since the actual code you'll have to write for your
application will need to use this code, no ?

> Automatic setup of flow graphs is definitely a nice feature. However, a 
> programmer will have to use the API to develop such a feature. Providing 
> some "feeling" for that was the idea of this first example.

It depends on the framework.  I'd say that a framework that does this
for you is easier to use than one that doesn't.

>  Furthermore, 
> such a feature is definitely not something that belongs to the core API 
> of any multimedia framework; it's an extension built on top of the core.

Matter of opinion.  FWIW, in GStreamer, that's exactly how it's done. 
No autoplugging in the core, but there is autoplugging available,
accessible through the same API as for "static" pipelines, more or less.

> >Also, I don't think it's smart to do this for audio only.  We all know
> >audio is the easiest to get right anyway, and audio presents a lot less
> >challenge to frameworks.
> >  
> yes, there might be other examples. However, the idea was to compare the 
> basic programming model and API of the frameworks.

Agreed.  The point is, you can't do a valid comparison between
*multimedia* frameworks if you don't throw *multi*media at the tests. 
What good is a framework that is really nice for audio-only stuff, but
falls apart for video ? What good is an API that's really nice for audio
stuff, but can't handle video ?

> Yes, sure. However, before everyone comes up with some more things to 
> compare, I think it would be great if we could first finish this comparison.

Heh :) To get an objective comparison, you first need to have the
"contestants" agree on the premises of the comparison.  If you want to
do this right, you need to get the foundation right as well.  Otherwise
we might as well do a comparison based on a set of helloworld examples
that did focus on autoplugging and didn't focus on networking :) 

I'm not at all saying we should, because that would be biased as well -
I'm just saying, we need to agree on the rules before playing by them,
if we want to give a good comparison to the people that matter here,
which are the KDE multimedia guys.

> Again: together, the idea was to compare the basic programming model and 
> API of the frameworks. We think that the provided examples are very 
> suitable for that.

I respectfully disagree, they are not broad enough to give a good idea
of what code would need to be written for a playback application.  Let's
iterate the playing field some more before starting :)

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
They say if you love somebody
you have got to set them free
but I would rather be locked to you
than living in this pain and misery
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/