[gst-devel] parsing problems
in7y118 at public.uni-hamburg.de
Wed Apr 23 11:17:12 CEST 2003
On Wed, 23 Apr 2003, Thomas Vander Stichele wrote:
> I'm getting increasingly confused and annoyed by the problems we're
> currently experiencing in HEAD wrt pipeline parsing.
This has to be going on for as long as 24 hours now. I'm not aware of that
bug much longer. You seem to be easily frustrated :)
> A simple gst-launch filesrc ! fakesink is running infinite loops without
> ever getting started.
> I've been told this is due to bison.
I currently think this is due to bison. I have success stories from people
upgrading bison to 1.875 who had that bug before. I have 1.875 and never
had that bug. Pipeline parsing works perfectly here.
> Firstly, I must honestly say I've never ran into bugs with the old parsing
> syntax. Company said there was something wrong with it, did a lot of work
> (for which we of course thank you), then came up with something new that
> has a different syntax which we probably don't fully get yet - but it is
> irritating that we have to force a change.
The old pipeline parsing only worked because of a bug that was
intentionally left in. Fixing that bug required fixing parsing which made
me so annoyed at what we had that I decided to rewrite it. Other things
the old parsing had were memory leaks (it never freed anything, just kept
on allocating) and a weird grammar, where spaces sometimes mattered and
As for differences I would say that you haven't really tried getting the
new concept. There's still the doc which you could have tried reading that
would have explained it to you.
But because people seem to be lazy, I will now tell you all of the
incopatible changes that I've made and that you definitely will have to
have a hard time learning:
1) explicit references (that is what you use to specify what pads to link)
require a dot now in any case. So you don't say "pipeline audiopad!
osssink" anymore but say "pipeline .audiopad! osssink".
This change is absolutely necessary because the new parser would try to
parse the pipeline as "pipeline audiopad ! osssink" and tell you that
there is no element of type "audiopad".
2) If you specify pads (you don't have to anymore) you specify them by
name, not by name of the padtemplate unless you use request pads, where
you have to use the padtemplate name (because only in that case there is
no pad yet). So you would use "filesink0.src" (normal pad) "tee0.src%d"
(request pad) or "mpegdemux0.audio_00" (sometimes pad). The last case
could be done differently before I think. (You can in all cases omit the
audio pad; "filesink0.", "tee0." and "mpegdemux0." should work, too.
This was done because I removed the AI to do padname->pad matching from
the pipeline parsing and moved it to gst_element_link_pads_filtered, which
is used for every gst_element_link_* function.
If that function should match padtemplate names in addition to pad names
when matching pad names this incompatibility would be gone, but I do not
know if that is desired or would break some applications using that
function. I would prefer it but didn'T get around to ask this question
> What's worse though is that apparently it does not work with my very
> recent rh9-included bison.
> So something is wrong, and I don't understand what it is.
> I see two options:
> - we revert back to the old parsing grammar, which I don't know what was
> wrong with, but worked fine
> - somebody does the work to properly make our new parsing stuff work on
> reasonably standard bison versions (I count rh8's and rh9's bison
> as "standard", and you all are welcome to declare some debian and
> other distro versions as standard).
I see a third option:
- we require bison 1.875 in HEAD and include the generated files in the
tarballs of releases for now - if bison really is the cause of the bug
and it's not me. In the case GStreamer is at fault we should fix it. And
afaik it's bison's fault.
> Basically I'm saying that we shouldn't start enforcing people to upgrade
> standard old development tools when chances are part of the problem is
> ours and it can be fixed more elegantly.
I remember a time where HEAD required cvs libtool.
> Also, this really tells us that we should work at getting some osort of
> regression testing going, because this is the sort of thing we really need
> to avoid. If the simplest of pipelines fails, we probably cannot begin to
> assess what else might go wrong.
There is a pipeline testsuite in testsuite/parse which gets updated as I
find new bugs.
If it currently does not work it might be because Wim broke GstAggregator
to not signal EOS anymore and hasn't fixed it yet. All other pipelines in
those tests should work fine, I tested them the last time I changed
> So, Leif, where you at ? :) Let's get together and set up a test suite.
More information about the gstreamer-devel