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

[Matthias Kretz]

On Wednesday 25 August 2004 15:58, Thomas Vander Stichele wrote:
> Hi Marco,
>
> > (1) Allow the playback of an encoded audio file (e.g. MP3). This will
> > result in similar setups: a component for reading data from a
> > file connected to a component for decoding connected to a component
> > for audio output. (Together, this is called "pipeline" or "flow
> > graph").
> > (2) Set the filename of the file to be read.
> > (3) Manually request/setup this functionality, i.e. no automatic setup
> > of flow graphs.
> > (4) Include some error handling.
>
> 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...

> So 
> you're saying you just want an application that can only play mp3's ?
> Personally I think a much better test would be to have a helloworld that
> can take a media file and just play it, whatever type it is.  That's
> what users care about, anyway.

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.

> > In a second step, we would like to extend the helloworld program with
> > following feature (helloworld II):
> >
> > (1) Add a listener that gets notified if the currently playing file
> > has ended, i.e. this listener is to be triggered after the last byte
> > was played by the audio device.
>
> What sort of thing is your listener ? An in-program function callback ?
> Another process ? Something else ?

Any kind of listener. If in C you do it with a callback just show the code how 
to do it.
In Qt/KDE you'd just want to connect a slot to a signal.

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

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

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

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040825/f4d9f3f5/attachment.pgp>