Killing Zombies - Unref-ing pipelines waiting for async change

[Wes Miller]

Michael, the code is in the note itself.  I didn't paste in all the unrelated
pipe building stuff and my first note said "I have a program with a receiver
pipeline (essentially, udpsrc->decodebin->autoaudiosinkl".  

This has turned into an interesting problem.  Michael and Nicola were
correct.  The use of:

created problems and isn't needed.

The part I left out of my explanation, apologies to all, the pipeline was
running in a separate thread from the class destructor that was trying to
kill off the "stuck", async, pipeline.   It was coded more or less as in all
the examples:


Here is what was happening: 
The destructor, in its separate thread, set the recvPipeline state to NULL
and unrefed the pipeline and loop.  
In the pipeline's thread, the gst_element_get_state() was no longer ASYNC so
the gst_element_get_state() returned and the code above resumed trying to
run the (unref-ed)pipeline and enter the (unref-ed)main loop.  This spit out
all sorts of CRITICAL messages and warnings about invalid objects and
refcounts > 0.

The fix was to, 
1. remove the unrefs from the destructor, letting the other thread handle
those operations.  Then  
2.fix the pipeline code thus:


Hope this helps the next guy and many thanks to Nicola and Michael.

Wes

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