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

[Benjamin Otte]

Quoting Thomas Vander Stichele <thomas at apestaart.org>:

> While that's fine for us, it's not really how application developers see
> it.  I guess you'd have to be one to understand this argument.  I
> understand though why you consider this to be an invalid argument as a
> core hacker.
> 
I'd have told the application developers it worked by accident. But I didn't 
assume I was talking to one.

> I'm trying to believe here you're not running circles around the problem
> on purpose :) I'll rephrase the question - what should applications, in
> your opinion, do, given that they want to release the device, but
> consequently the whole app blocks for $x seconds (where $x is the amount
> of time it was playing before pressing pause) ? Ie, should applications
> continue setting the sink to NULL, and the bug needing to be fixed is
> clocking-related ? Or should applications be setting it to READY, and
> should something else be fixed somewhere else ?
> 
Apps should set the sink to NULL - when GStreamer properly supports it.

> Or, otherwise said - just as you seem to disagree a lot with the design
> Erik and Wim had on core issues, they might as well be disagreeing with
> yours.  What happens if you lose interest, and someone else gains
> interest ? Should he redo everything again to fit his idea of how it
> would work ?
> 
I'm pretty sure that other people would influence the design in other 
directions. They would probably even change semantics and redo a lot of stuff.
But that's normal if maintainers and developers cange.
Just look at Nautilus.

> Of course, if you feel we shouldn't even have this in an ideal
> situation, then the discussion is moot.  It does block other people from
> helping out though, with the usual results.  You would probably argue,
> and not be wrong about it, that anyone is free to study the code enough
> to participate in the design.  OTOH, you'd also say we only have 2
> people doing that currently.
> 
> For the long-term viability of GStreamer, it might be a good idea to
> find ways of expanding that number.
> 
Unfortunately we're busy ensuring short-term viability by making GStreamer 
release devices ;)
And in the end we just do what we like most, because we do this all for our 
own enjoyment.

> > You're autotooling doesn't do it in a different way.
> 
> The project is GStreamer, a streaming media framework.  autotools stuff
> is infrastructure work, and sufficiently documented outside of
> GStreamer.  Hardly something that needs a design within the context of
> GStreamer :)
> 
I was more talking about "why do we have sys/, ext/, gst/ and gst-libs/ 
directories?" and stuff like that.

Benjamin