[gst-devel] media-info, and old streaminfo tags

[Thomas Vander Stichele]

Hi,

> Resource acquisition definately shouldn't move. I don't like a new
> state. What should be so special about it?

It is clear that there should be a way to "release" devices without
setting the element to NULL.  This is not only for audio sinks.

> [intermezzo]
> If you want to open multiple applications with your soundcard, shouldn't
> you use a sound server? That's what they're there for. Esdsink works.
> Is it our job (GStreamer) to hack around OSS drivers that only want to
> be open(2)'ed once?
> [/intermezzo]

Let's not use the strawman argument of telling people to use a sound
server.  Nobody uses them because they tend to suck.  The people that
use them do so because they haven't realized yet.


> So let's say that it *is* our job to hack around all this; do we (for
> this one, little, tiny, specific case)

You're downplaying the issue; there's nothing little or tiny about it,
it's the first request users make, and it has been reported to us quite
a few times already.

>  need to re-design the whole
> framework by adding new states (which I consider a huge change) or
> something? I, for one, would rather have this hack then add a new state.

Consider this.  Apps want to be able to pause playback in a way that
releases the device.  THey want playback to pick up immediately where it
left off when unpausing (or throw an error if another app took over :))
These apps want this because the users ask for it.  Especially if the
apps don't provide a "stop" button :)

Now, if our design forbids us to give this to the apps, then I consider
our design broken.  Especially since it isn't very hard to allow this;
the only reason why we don't is because we try to convince people it is
bad.  The only reason why we think it's bad is because it doesn't fit
our current idealistic model.  To me this seems like an elitist view of
things: "we're right, the rest of the world is wrong."


> As said, I'll think about possible solutions, and you guys can go ahead
> and add this for 0.8.0. I hope I can think of something elegant for
> 0.9.x.

I would love that, but I'm not yet holding my breath for it :) anyway,
states and how they are managed is really something that should be well
thought out and written down based on actual examples, use cases, and
pipeline descriptions.  It is very easy to "prove" that the current way
is wrong wrt. what apps want to do.

We can either go on pretending that the apps are wrong and we are right,
or we can accept that if we want apps to use us, we might try and cater
for what they want to use us for :)

We can always fork gstreamer-no-use if we really want a perfect
internally consistent design that nobody can use, however :)

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If I could be who you wanted
all the time
then I would
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/