I am sending a demo video via gst-launch-1.0 using the udpsink element to send it to the KMS, having previously negotiated the session and taking the port negotiated with Kurento and using it as a parameter in udpsink (similar to the rtp receiver example). So far so good, I am being able to receive the video without problems.
But, I'm doing some tests, and among them, one consists of canceling the transmission completely (emulating that the producer has internet connection problems / his computer was turned off, etc) and sending the video back to the same port after a few seconds. That's where I have problems.
To try to understand what happens, I tried to analyze the events of my rtpendpoint, specifically the events of "MediaFlowOutStateChange" arrive, first with state: FLOWING and then (when I stop streaming), I receive a NOT_FLOWING. So far, everything works as expected, but when trying to restart the streaming by executing the same command, I receive the same error, both in the pipeline and in the rtpendpoint events:
"'Internal data flow error. (Gstbasesrc.c (2948): gst_base_src_loop (): / GstPipeline: pipeline4 / KmsRtpEndpoint: kmsrtpendpoint4 / KmsRtpSession: kmsrtpsession4 / GstUDPSrc: udpsrc18: \ nstreaming reason-linked task () linked paused () '"
Any idea on what I'm doing wrong? Is it possible to use the same port or will I have to release the connection and negotiate a new port? I suspect that after receiving a "NOT_FLOWING", the SDP session is releasing, but I'm not sure.
Thanks in advance!
PS: I am using the following command to do the tests
gst-launch-1.0 videotestsrc ! videoconvert ! videoscale ! videorate rate=1 ! video/x-raw ! x264enc tune=zerolatency ! rtph264pay ! "application/x-rtp,payload=(int)103,clock-rate=(int)90000" ! udpsink host=x.x.x.x port=x