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

[Benjamin Otte]

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

> > 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.
> 
> Agreed.  OTOH, it was in the design and functionality in 0.6
> 
No it wasn't. It worked because no output sink cared about timestamp.

> > Luckily we even have it in our design. Rhythmbox even behaves exactly like
> a 
> > player should behave.
> 
> Now you lost me again - are you saying it is correct for apps to set the
> output sink to NULL to pause it ?
>  
No, I'm saying they should set the output sink to NULL to release ressources 
asociated with it.

> > You would have had enough time to fix those issues earlier, if you had
> cared. 
> 
> The issue, to be clear, is not that the fact that Gst locks the device. 
> We all knew that was what we were doing, and there were some who said
> this was going to be a problem for apps.  The real issue is that app
> developers find this so bad to live with that they chose to work around
> it, triggering more important user-visible brokenness.
> 
> It's this second issue that is relatively new, I only know about it
> since the last month.
> 
Same here. Which is why it isn't fixed.
Sorry, but I can't fix everything right now.

> I'm not sure why you're trying to make it personal.  I respect your
> desire to deliver the ultimate ideal perfect framework.  I don't think
> it's wrong for me to ask you to respect my (and other people's) desire
> to deliver features, try and stick to releases, and generally keep the
> interest going.  I know you disagree with the opinion that GStreamer
> needs users today to survive.  That doesn't mean it doesn't need users
> today to survive.
> 
You're twisting arguments.
I never said we don't need users. I said users will live with it better than 
when we break something by introducing buggy "release-device" properties. And 
believe me, they will be buggy. Everything new and untested is buggy, 
especially if it breaks the design.

> And on the other hand, there is work that needs doing that nobody else
> seems to want to do.  This includes maintaining builds, fixing those
> issues, fixing the website, making the release process go smoother, and
> so on.  I don't mind you not respecting any of the work I do on
> GStreamer, people are allowed differing opinions.
> 
Yes, I respect that work.
It's just funny that you show up 2 weeks before release starting to write code 
insisting that this one stupid bug is so important that it must be fixed right 
now.

> To wit, it would also be nice if the people that call themselves the
> designers share enough of the information so that they can use the
> resources of all the satellite hackers at large to actually implement
> and fix stuff.  It would surely prevent them from doing it half-assed a
> week before release.
> 
> OTOH, They could also just proclaim themselves core hackers, pick a
> favourite problem, and hack it in so that it works the way they want it.
> 
Everything I do is documented. The files documenting how stuff works end in .c 
and .h as is common everywhere in the Open Source world - I expect everyone 
hacking on GStreamer and talking about design to be able to understand them 
and to read them.
You're autotooling doesn't do it in a different way.

Benjamin