Zombie bins

[Paddy]

Well I finally got to the bottom of this.

This was the symptom:
when recording many concurrent pipelines as described above - at the point
where the old matroskamux & filesink bin (which I called the muxsink) was
removed & the new one was added the contents of the old file was removed.
There was also an error mode where the new muxsink never wrote any data to
disk even though data was passing through it.
The old muxsink was removed by calling
gst_element_set_state(GST_ELEMENT(bin), GST_STATE_NULL) &
gst_bin_remove(parent, bin) after it was unlinked, as described above. Also
I believe my claim that gst_element_set_state(GST_ELEMENT(bin),
GST_STATE_NULL) was asynchronous may not be true.

The cause:
When the new muxsink is linked to the rest of the pipeline, the pipeline is
actually in the paused state (nothing I did, promise - I was surprised at
this). When the pad blocks are released the pipeline state changes to
playing & data is written to the new muxsink - however the muxsink's parent
bin still has the old muxsink as one of its children (the old muxsink has
parent element is NULL, but the parent bin hasn't yet got around to removing
the old child yet). When the pipeline goes to the playing state, all the
elements inside the parent bin are moved to the playing state - which means
that the old file is opened & the write pointer set to 0. The call to
gst_bin_remove() fails as the the old muxsink is no longer in the NULL state
(it gets as far as paused)

The fix:
lock the state of the old muxsink them moment it gets to NULL.

Hope this helps someone.



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Zombie-bins-tp4658588p4658698.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.