Rtpbin dynamic pads question

[William Salibrici]

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.
My development machine is windows 7 and I'm using GStreamer 1.10.4 with your windows pre-built binaries.



mp4mux name=mux ! filesink location=C:/my_dir/my_file.mp4

sync=true



rtpbin latency=6000 name=rtpbin_A



udpsrc address="192.168.1.101" port=5018

caps="application/x-rtp,media=video,clock-rate=90000,payload=97,encoding-name=VP8" !



rtpbin_A.recv_rtp_sink_0

rtpbin_A. ! rtpvp8depay ! avdec_vp8 output-corrupt=true ! videoconvert ! videorate ! videoscale !

capsfilter caps="video/x-raw,height=288,width=352,framerate=30/1" !

openh264enc ! h264parse ! queue ! mux.





udpsrc address="192.168.1.101" port=5020

caps="application/x-rtp,media=audio,clock-rate=48000,encoding-name=OPUS,payload=96" !



rtpbin_A.recv_rtp_sink_1

rtpbin_A. ! rtpopusdepay ! opusdec ! audiorate !

capsfilter caps="audio/x-raw,format=S16LE,rate=8000,channels=1" !

voaacenc ! queue ! mux.





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.
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.
>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.
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:

- Set pipeline to paused when the first new pad is received.

- Unlink the old dynamic pads for the old rtp streams.

- Re-link the new dynamic pads for the new changed rtp streams.

- Set pipeline to playing after both new pads are re-linked.


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.
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?
Thanks so much for your help,
Bill

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