[gst-devel] Re: Comparison: MAS, GStreamer, NMM
kretz at kde.org
Wed Aug 25 08:35:18 CEST 2004
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...
> 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
> > 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
> 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.
Matthias Kretz (Germany) <><
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
Size: 189 bytes
Desc: not available
More information about the gstreamer-devel