Killing Zombies - Unref-ing pipelines waiting for async change

[Wes Miller]

Hi All,

I have a program with a receiver pipeline (essentially,
udpsrc->decodebin->autoaudiosinkl) that may or may not do any receiving
depending on if another program connects to it.  The pipe is set up and gets
to the point in the code where it is "hung" in async state waiting on the
external connection to send in some data.

Later on when it's time to shut the program down, I send an EOS to the
"hung" receiver pipe, but since the pipeline is not complete and, therefore,
not moving data down the pipe, the EOS has no effect.

So, what's the best way to handle this? I am sure there has to be a better
way than what I've considered:

1. Use a separate variable that is true only if the pipe is in "Running"
state and use that var to just not bother with the EOS.  If I do that, what
do I need to do besides unref the pipeline?  Will it unref while it is in
"async" state?  Can I move it to some other state, like "NULL" and then
deref it?

2.  Get the state of the pipe and just deref it if the state is async?  Can
I ask the same pipe for its state twice, i.e. will the
gst_element_get_state() functions collide?  Interfere with each other? 
Crash?

3. Hold off on linking the pads in the New-Decoded-Pad signal callback and
wait for a signal from udpsrc to say it has data before linking?  Would this
make it easier to move the pipeline back to "NULL" state?

4. Use a split src consisting of the udpsrc and a audiotestsrc connected to
a selector and send myself a burst of data to prime the pipe then change
inputs to the udssrc?  This one is going to require an example pipe spec. 

5. Is there an "interrupt state change" mechanism for the pipeline?

Thanks for any help.

Wes




--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Killing-Zombies-Unref-ing-pipelines-waiting-for-async-change-tp3732732p3732732.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.