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

[Martin Soto]

On Tue, 2004-03-09 at 16:26, Benjamin Otte wrote:
> 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.

Well, as I explained, I'm usually sending sound, so I really need and
audio sink. It is just that every now and then there are passages
without sound, and I have to handle them as well. My older player tries
to modify the pipeline in such cases to disconnect the audio component,
and believe me, doing that raises more issues than it solves. The main
problem is that it is very hard to touch the pipeline without disrupting
the data flow. You unlink a pad a bit too early, and you may prevent
some important data from reaching its intended destination. This may
result in all sorts of funny behavior, specially in DVD menus.

I'm not meaning that your fixes to the clock subsystem are wrong.
Indeed, they improved the situation quite a bit. But we still need work
to have a really generic behavior.

> > 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..

Among many other issues. I'm convinced that one of the main problems is
that scheduling in GStreamer doesn't have defined semantics. It seems to
me that all existing schedulers were implemented based on implicit sets
of assumptions, that are slightly different from each other. So you
never know what to expect from a scheduler, because they all behave
somewhat differently. IMO, we should start by clearly defining the
minimal expected behavior of a scheduler.

> > 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.)

Well, I'm not speaking of design documents, but rather of
specifications, and those are created and used very often by the free
software community. Four examples out of my head:

- Python Enhancement Proposals (http://www.python.org/peps/)
- Debian policy documents (http://www.debian.org/devel/)
- The FreeDesktop standards (http://www.freedesktop.org/Standards/Home)
- Gnome Enhancement Proposals (http://developer.gnome.org/gep/).

My point is that some areas of GStreamer need to be specified that way. 
The beauty of GStreamer is that you can mix elements freely, but in
practice, you end up very often with a non-working pipeline, because of
small inconsistencies between the various components.

> 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.

I agree, David did a great work with the caps negotiation subsystem. And
one of the good things he did was putting together a text document
explaining how the whole thing works. You certainly know what to expect
of capsnego one you use it.

> 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.

Reading the code works in many cases, but there are also situations in
which some additional documentation comes handy. For example try to tell
how schedulers work in GStreamer by reading the code from the opt
scheduler. First, it will take you a fair amount of time and a lot of
hair pulling to make yourself an idea of how it works. And second, at
the end you will only know how opt works, because the other schedulers
behave differently and you don't know where the differences are. I guess
a concise text document telling you how schedulers are supposed to
behave wouldn't be that bad, after all.

Cheers,

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>