GNOME Bugzilla – Bug 308167
switch plugin goes berserk if it's src peer gets inactive
Last modified: 2005-07-02 23:01:28 UTC
if the element connected to a switch plugin goes to EOS state, the switch plugin itself doesn't recognize that, and tries to push data onto the inactive sink of the connected element. the result is a wast amount of gstreamer warnings like this: (process:10787): GStreamer-WARNING **: push on peer of pad switch:src but peer is not active
Created attachment 47948 [details] sample code demonstrating the problem this sample program demonstrates the issue: it will set the alsasink to EOS after 2 seconds of play, but the switch connected to it will still try to push data unto the alsa sink's sink pad.
Created attachment 47949 [details] [review] a patch solving the issue
Why do you EOS the sink? That function call is not supposed to be called by applications. Only switch itself can EOS its downstream peer elements. If you EOS the sink, you have to eos switch yourself, too. Or, rather, just stop iterating.
I eos the sink, because it turned out that playing has to stop. this is a short sample to demonstrate the problem. the real setup I found this problem was when an element, connected after a switch decides that playing has to stop. the only thing it can do is to EOS itself, which should propagate further upwards, finally making the outermost pipeline stop iterating. but this won't happen if switch mindlessly tries to push data unto an inactive sink - as the bin containing them will not EOS itself, as it will have at least one active element - the switch.
Your application should *never* EOS part of a pipeline and expect the rest to be OK with that. That's not how it works in 0.8. If you want EOS, just pause the pipeline.
pause? but what if I wanted it to stop....?
then you set it to GST_STATE_READY or even _NULL.