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

[Benjamin Otte]

Quoting Martin Soto <soto at informatik.uni-kl.de>:

> The clocking system, even with the recent fixes from Benjamin, has still
> some serious issues. For example, as discussed this week, most audio
> clocks increase time only as the providing sink plays audio material.
> That means, if you have no audio, your clock stops. So, don't play any
> DVDs having animated menus with no audio. Or at least, don't go into
> such menus, or your GStreamer based DVD player will mysteriously freeze.
> 
Or don't make the pipeline tell everyone that there is audio by plugging an 
audio part and then not sending any.

> And that not to mention schedulers. At the moment, I can only say that
> my pipeline works. But I'd rather not try and change it. The other day I
> tried to put the video and subpicture output components in a single
> thread (it should work, the spu thing has very low throughput) but the
> scheduler froze. Basically, you know that schedulers work when they want
> to, and only when they want to. And having many of them doesn't help,
> because they all seem to be as temperamental as primadonnas.
> 
Fixing schedulers corectly depends on #112086..

> But enough ranting. GStreamer is a really cool project and it deserves
> as much success as possible. Please start discussing some of this stuff
> now. It is not that hard, just write a proposal, send it to the mailing
> list, wait for some feedback, correct, publish again. As soon as
> something is decided, we (or at least those with CVS access ;-) can help
> fixing elements until everything behaves consistently. And to put my
> work, it not my money, where my mouth is, I'll start with a proposal for
> clocking and discontinuity handling. You can expect it at some point
> this week.
> 
I don't think the approach with "design documents" works very well in the 
context of application development. (I've not witnessed it working anywhere in 
the open source scene for example, feel free to point me to examples proving 
the opposite.)
The best way to develop and improve subsytems IMO is to develop something in a 
branch monitored by peers. This has worked very well for the caps nego system 
for example.
Add to this that documentation is never as up to date as the code, it never 
explains how sth works as good as the code and it is never as exact.

Benjamin