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

[Thomas Vander Stichele]

Hi,

> > I'm curious about (3) - why should it not be done automatically ?
> 
> Both should be possible. In case you don't want it to be done behind your 
> back, when you want to have a special setup...

Sure.  But automatic is more important than manual, since you have to
write less code then :) I agree that both should be possible, so I'm
fine with having both.  But let's not pretend we can measure an API for
media playback without having it work automatically.


> This not about writing an especially usefull app but about looking how the API 
> "feels". While I find it interesting to see how to set up the framework to 
> play a mp3 file it's of course also interesting how much the framework can do 
> on it's own.
> But... this is not really about comparing features, it's more about comparing 
> APIs.

I guess that depends on point-of-view.  API is volatile in the sense
that API can be added, or libraries added on top, for easier
manipulation.  In fact, I'd say that a more useful exercise to evaluate
frameworks would be for *someone else* to write an application with an
as-yet not existing API, and then the frameworks should implement the
API.  But that's just my opinion.


> > > In a final step, we would like to extened the helloworld program
> > > (helloworld I) to allow for distributed playback (helloworld III):
> > >
> > > (1) The component for reading data from a file should be located on the
> > > local host. The component for decoding, and playing the audio data should
> > > be located on remote host.
> > >
> > > Notice that this third example should also demonstrate how easy (or
> > > painful) it is to develop networked multimedia applications using the
> > > particular framework. We hope that this will finally show that
> > > developing distributed multimedia applications means more than "well,
> > > simply write a component for streaming data and put that into your
> > > pipeline".
> >
> > Not sure why the third is important.  While it's important for
> > multimedia frameworks to be able to do things like this, I don't see the
> > value of this for a desktop environment.  Can you provide a use case
> > where this makes sense ?
> 
> Thin clients, conferencing, cool stuff like shown in the NMM talk at 
> aKademy ;-)

We all love cool stuff :) But I'm not sure I follow the description of
helloworld III as it is currently stated.  At the very least there'd
need to be two programs, no ?

> > 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.
> 
> Uh, I don't agree that audio is the easier part. Video is easier. 
> Synchronization isn't easy, though.

Maybe I didn't make myself clear.  Since video most of the time also
contains audio, video is more difficult than audio, since it contains
audio plus something else.  For example, take into account the fact that
you all of a sudden need demuxers, that there is a wealth of additional
formats that need to be supported, all with particular quirks, ...

Unless you feel that a framework that can play mp3's wonderfully well,
but blows up when you hand it an .avi file, is an acceptable framework
for KDE :)

> > I'm sure I could come up with other things that are important to be
> > tested, I'll think about it some more.
> 
> Again, it's not about a testsuite or features but about the API.

Same here.  I'm also talking about the API.  But you need to make sure
that you can evaluate the framework through the API you give; for
example, KDE people have said they want to be able to record as well. 
No point in evaluating API's on playback API only then, IMO.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Even bums don't not got a car
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/