<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"> I am using the following 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> My development machine is windows 7 and I’m using GStreamer 1.10.4 with your windows pre-built binaries. <o:p></o:p> <o:p> </o:p> mp4mux name=mux ! filesink location=C:/my_dir/my_file.mp4 <o:p></o:p> sync=true <o:p></o:p> <o:p> </o:p> rtpbin latency=6000 name=rtpbin_A <o:p></o:p> <o:p> </o:p> udpsrc address="192.168.1.101" port=5018 <o:p></o:p> caps="application/x-rtp,media=video,clock-rate=90000,payload=97,encoding-name=VP8" ! <o:p></o:p> <o:p> </o:p> rtpbin_A.recv_rtp_sink_0 <o:p></o:p> rtpbin_A. ! rtpvp8depay ! avdec_vp8 output-corrupt=true ! videoconvert ! videorate ! videoscale ! <o:p></o:p> capsfilter caps="video/x-raw,height=288,width=352,framerate=30/1" ! <o:p></o:p> openh264enc ! h264parse ! queue ! mux. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> udpsrc address="192.168.1.101" port=5020 <o:p></o:p> caps="application/x-rtp,media=audio,clock-rate=48000,encoding-name=OPUS,payload=96" ! <o:p></o:p> <o:p> </o:p> rtpbin_A.recv_rtp_sink_1 <o:p></o:p> rtpbin_A. ! rtpopusdepay ! opusdec ! audiorate ! <o:p></o:p> capsfilter caps="audio/x-raw,format=S16LE,rate=8000,channels=1" ! <o:p></o:p> voaacenc ! queue ! mux.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> The pipeline runs without errors under normal conditions and I can play the resulting mp4 recording just fine using the standard Windows media player. So far so good. <o:p></o:p> However, here is the problem I’m having. The sender side that 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] to continue the recording session. The old stream is dead, no more packets from there. There’s a short gap in the data on the receiving side of about 3 seconds. <o:p></o:p> From your documentation for the rtpbin element, I see that each rtp stream is demuxed based on the SSRC [sync source] id in the rtp packet header. Each data stream [audio and video] must have a unique SSRC id. A new pad is created using the rtp session number, SSRC id and payload type respectively as the pad name. <o:p> </o:p> I see the first set of two dynamic pads for the original rtp streams come through ok in my pad-added callback. The new changed rtp streams will have different SSRC id numbers. When the rtpbin detects the new changed rtp streams, I also see the dynamic pads for the new streams in my pad-added callback. I take the following actions in my pad-added callback for the pads for the new changed rtp streams: <o:p></o:p> - Set pipeline to paused when the first new pad is received. <o:p></o:p> - Unlink the old dynamic pads for the old rtp streams. <o:p></o:p> - Re-link the new dynamic pads for the new changed rtp streams. <o:p></o:p> - Set pipeline to playing after both new pads are re-linked. <o:p></o:p> <o:p> </o:p> The pipeline appears to continue running ok in the playing state using the new pads for the new changed rtp streams. 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, probably because the EOS didn’t go all the way through for some reason so the file does not finalize properly. <o:p></o:p> I’m at a loss as to what to do next. Can anyone shed some more light on this problem? Do I have to do something more with the old pads either before or after unlinking them? Do I have to do anything for the downstream sink pads to which the new dynamic pads are being linked? <o:p></o:p> Thanks so much for your help, <o:p></o:p> Bill <o:p></o:p> <o:p> </o:p> </div> </body> </html>