Rtpbin dynamic pads question [update]

[William Salibrici]

Since my last post I reviewed the pad probe information more carefully from the following links:
https://coaxion.net/blog/2014/01/gstreamer-dynamic-pipelines/
https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html
Recall that I am using a C code pipeline to receive audio and video using rtpbin and to create an mp4 recording file. I have a pad-added callback attached to the rtpbin where I link the new dynamic pads as they are created.
Also recall that my sender side which generates the audio and video for a recording session occasionally stops sending data for the original rtp streams and creates new rtp streams instead [same destination ip address and ports but different SSRC id numbers] to continue the recording session. The old streams are dead, no more packets from them.
So this is basically a dynamic pipeline problem where I have to unlink the old rtpbin dynamic pads and relink the new ones while the pipeline is playing.
I have modified my pad added callback to use pad probes according to the articles above. In my pad added callback, I add a pad probe of type GST_PAD_PROBE_TYPE_IDLE to the new rtpbin dynamic pads of the second set of rtp streams.
In the pad probe callback I unlink the old rtpbin dynamic pad. Then I install an event probe on a downstream src pad of type
(GST_PAD_PROBE_TYPE_BLOCK | GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM).
Next I push EOS into the sinkpad that is now unlinked from the old rtpbin dynamic pad. The goal is to drain the downstream pipeline segment of all of its data.
Next I relink the sinkpad to the new rtpbin dynamic pad and the pad probe returns GST_PAD_PROBE_REMOVE.
The event probe callback passes everything except the GST_EVENT_EOS at which time the event probe is removed and returns GST_PAD_PROBE_DROP.
This all seems to work ok. I check all function returns for success and no errors are reported. The pipeline remains in the playing state the whole time and no pipeline errors are reported either.
I modified my pipeline [shown in my previous post] to insert identity elements between the depay and decode elements for audio and video. I connect to the handoff signals and I can confirm that once the rtpbin emits the second set of dynamic pads, no more data flows in the downstream pipeline elements for either audio or video even though I successfully complete the pad probe operations described above.
At the end of the recording session I try to stop the pipeline the in usual way [gst_element_send_event (pipeline, gst_event_new_eos());] but the pipeline never stops, it hangs. I see that the recording file has data but it's unreadable. The EOS never reaches the mux or filesink so the file does not finalize properly.

Any ideas on what I am doing wrong? I think I'm on the right track but I'm still missing something. The rtpbin is a very powerful element and I believe a popular one as well. The situation I have presented is a valid real-world use case. I hope someone can shed more light on this. It would help me as well as other rtpbin users. Thanks in advance for your help,


Bill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170828/45189144/attachment-0001.html>