<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Since my last post I reviewed the pad probe information more carefully from the following links: <o:p></o:p> <a href="https://coaxion.net/blog/2014/01/gstreamer-dynamic-pipelines/">https://coaxion.net/blog/2014/01/gstreamer-dynamic-pipelines/</a> <o:p></o:p> <a href="https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html">https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html</a> <o:p></o:p> 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. <o:p></o:p> 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. <o:p></o:p> 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. <o:p></o:p> 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. <o:p></o:p> 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 <o:p></o:p> (GST_PAD_PROBE_TYPE_BLOCK | GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM). <o:p></o:p> 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. <o:p></o:p> Next I relink the sinkpad to the new rtpbin dynamic pad and the pad probe returns GST_PAD_PROBE_REMOVE. <o:p></o:p> 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. <o:p></o:p> 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. <o:p></o:p> 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. <o:p></o:p> 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. <o:p></o:p> 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, <o:p></o:p> <o:p> </o:p> Bill <o:p></o:p> <o:p></o:p> </div> </body> </html>