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

[Benjamin Otte]

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

> 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."
> 
Making something possible requires fitting it into the design first. And if we 
haven't found a way to fit it into the design yet, we need to think about it.

> 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.
> 
Luckily we even have it in our design. Rhythmbox even behaves exactly like a 
player should behave. The problem is that GStreamer doesn't behave like it 
should. And this is because we decided to not fix all the bugs we have and 
release a perfect audio player, but because we wanted to do a release now.
Some things didn't get done yet. There's no new autoplugger, there's no proper 
discont handling and we don't do threading or scheduling perfectly yet, 
fixating is a mess, the video/raw caps are ugly, there's no subtitling, DVD 
playback isn't perfect, a lot of muxers don't work, I can't play back a good 
lot of Quicktime Trailers and there's certainly a lot more.

We'll have to live with it for now.

> 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".
> 
Oh, we will do this. But not now. The same goes for a lot of other things. But 
people understand that.
Some things are easy, some things are hard. The Gtk file selector sucked far 
longer than this and people still used Gnome. I'm not worried.

> 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.
> 
What it tells me is that you prefer trashing the design than actually thinking 
about ways to make it work with our current design. ;/

> 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 ?
> 
You would have had enough time to fix those issues earlier, if you had cared. 
The problem in this case is known to me since about 3 years. I had a lot of 
discussions with anyone in this project about it. But noone ever cared about 
it enough to fix it so we don't have it in 0.8.0.
We'll survive it.

Anyway, you know what I'm getting frustrated with? People showing up 2 weeks 
before release and well into freeze date accusing me of sticking my head in 
the sand. They come around, select their two to five favorite bugs and 
proclaim they need to be fixed _now_ or the project will be doomed. And since 
those people have cvs access they start messing around with our code trying to 
hack in a way that makes this work in a hacky way that breaks the next time 
someone changes something. But what do they care, they can show up on the next 
release when it is broken again and wield the even bigger "regression" hammer.

Now it would be nice if those people did some work in between releases so they 
knew how hard it was to get something right. But for some funny reason they 
never did that. 

It's certainly easier to do it half-assed a week before release.


Benjamin


PS: The correct way to solve it is to require a DISCONT event with the correct 
timestamp before any data gets sent. This fits nicely into the current design.