[gst-devel] Ogg, Spider, and Volume not working together

Benjamin Otte in7y118 at public.uni-hamburg.de
Fri Mar 5 06:42:09 CET 2004


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

> I looked into why vorbisdec ! osssink doesn't just error out, and I
> noticed the parsing code tries to unlock the sink and then sync the
> state to that of the parent, which then of course fails.
> 
> Benjamin, I added a check there and a GST_ELEMENT_ERROR, but I would
> rather find some way to make the error say, before that, that the caps
> nego failed.  Any idea how I should do that ?
> 
If both elements can connect (they shouldn't be able to, the caps don't match, 
you should get a "Error: could not link vorbisdec0 to osssink0, trying to run 
anyway" line with gst-launch) there is no way to figure out if they can find a 
fixed caps with the given pipeline until the pipeline actually runs. There's 
no way to figure this out ahead of time.
As an example, consider this pipeline: src ! mad ! mono2stereo ! fakesink
This pipeline works if you have a mono mp3, it fails if the mp3 is stereo. No 
way to figure this out before running it.


> Also, I then noticed that the rest of the pipeline happily tries to keep
> playing, so I added some code to the error handler that tries to pause
> the parents recursively.  If someone thinks this is a bad idea, let me
> know.
> 
> For now, it does what it should do; error out and stop running after
> that.
> 
*raises hand*

It's bad enough that errors and EOS change states, I certainly don't want 
elements messing with the state of totally unrelated elements (like the whole 
pipeline). If someone wants to have every element set to paused on an error, 
he's free to connect an error handler (I believe both Rb and GstPlay do that). 
State changes should be done explicitly by the app, not by the lib cde 
somewhere.
What about if someone wants it to go on? (like it happens to me more often 
then not when I test stuff - which is exactly what gst-launch is for)

Apart from that I dislike such a big change that shortly before release 
anyway...

Could we please revert that recursive state change?

Benjamin




More information about the gstreamer-devel mailing list