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

[Thomas Vander Stichele]

> > 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.
> 
> No, it is not.

It is not clear if you keep arguing from a theoretical standpoint, ie
from the design to the app.  It is easy to be right about this from that
point of view, because this point of view basically says "if it's not in
my design then it is not clear we need this."

What I'm saying is, if you are designing so that apps can use us, then
it really is clear this should work.  Why is it clear ? Because all the
music player apps that use GStreamer atm want to be able to release the
device on pause.

Feel free to tell me I'm missing the point here.  But don't forget that,
from the app developer's point of view, it is us who are missing the
point.  They want to be able to do this, and all we can say is "sorry,
we don't do that (yet)", and in the back of our heads we think "and we
never will, suckers, because it doesn't fit our design, muhahah".

> You mention "setting an element to NULL",

I mention "setting an element to NULL" because that is what all these
apps are currently doing to work around this issue.  They are doing this
because, with the functionality they want, they have no other way.

>  but you don't actually mean
> that. You mean, an element not losing its internal state set. However,
> that's already lost when going to READY. States are documented in the
> PWG, and that reflects what I perceived as the conclusion from the last
> time we discussed this.

Yep - and the last time we discussed this we already KNEW that doing it
this way would make it impossible for devices to get released without
setting the sink to NULL.  What does that tell us ? That we designed it
wrong.

> About states: we don't need to discuss it, we don't need to document it.
> I've been working a lot on that lately (PWG), and I'm still intending to
> work more on it (chapter 4). Let's fix our apps.

That's like saying "we don't really need to write down any designs for
GStreamer, it's all in our head".  It's getting really tiring to switch
internal design stuff around only to find out that while it fixes the
problem we were having, it creates a whole bunch of new ones we weren't
having.  The only way to avoid that in the future is to start writing
down designs and prove *on paper* that apps will work this way.

If you install fedora core 1, and run rhythmbox, and pause, then play,
it works.  Currently, when you will install fedora core 2, and do the
same, it won't.  I'm not entirely sure how much you guys care about the
negative publicity this will get us, not to mention how hard it will be
to convince GNOME that we really are improving and that GNOME is making
the right choice to use GStreamer.

You also said "Let's fix our apps".  Seriously, I don't see how this is
a bug in the apps.  There is literally nothing I can think of that the
apps should do in this respect.  Feel free to say what they should be
doing.

Anyways, I can't bring it up more than I already do.  If you all think
that the current design is fine, and that we can continue sticking our
head in the sand saying everything outside of GStreamer is wrong, from
kernel to daemons to userspace apps up, go right ahead :) I'm just
getting worried about the message we're trying to send here.

Maybe we should quarantine development of GStreamer for a few years and
tell apps to come back after that ?

Thomas