[gst-devel] media-info, and old streaminfo tags
in7y118 at public.uni-hamburg.de
Tue Mar 9 07:27:11 CET 2004
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
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.
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.
More information about the gstreamer-devel