GNOME Bugzilla – Bug 549409
gstrtpbin don't stop at the end of a stream
Last modified: 2008-08-28 15:21:54 UTC
Please describe the problem: When a file is send using gstrtpbin and when the end of it is reached, gstrtpbin don't stop and I have to send gstreamer a SIGTERM signal. Steps to reproduce: on th server side : gst-launch -v gstrtpbin name=rtpbin \ filesrc location=filesrc location=../../../partage/Videos/superman_originale.avi ! decodebin name=dec \ dec. ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! rtpbin.send_rtp_sink_0 \ rtpbin.send_rtp_src_0 ! udpsink port=5000 host=127.0.0.1 ts-offset=0 name=vrtpsink \ rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=127.0.0.1 sync=false async=false name=vrtcpsink \ udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0 \ dec. ! queue ! audioresample ! audioconvert ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_1 \ rtpbin.send_rtp_src_1 ! udpsink port=5002 host=127.0.0.1 ts-offset=0 name=artpsink \ rtpbin.send_rtcp_src_1 ! udpsink port=5003 host=127.0.0.1 sync=false async=false name=artcpsink \ udpsrc port=5007 name=artpsrc ! rtpbin.recv_rtcp_sink_1 on the client side : gst-launch -vvv playbin uri=file:///home/user/test/gstreamer/client.sdp with client.sdp: v=0 o=- 1188340656180883 1 IN IP4 127.0.0.1 s=Session streamed by GStreamer i=server.sh t=0 0 a=tool:GStreamer a=type:broadcast m=video 5000 RTP/AVP 96 c=IN IP4 127.0.0.1 a=rtpmap:96 H264/90000 m=audio 5002 RTP/AVP 8 c=IN IP4 127.0.0.1 Actual results: the server side don't stop Expected results: the server stop Does this happen every time? yes Other information:
* gst/rtpmanager/gstrtpsession.c: (gst_rtp_session_send_rtcp), (gst_rtp_session_event_send_rtp_sink): Send EOS when the session object instructs us to. * gst/rtpmanager/rtpsession.c: (rtp_session_on_timeout): * gst/rtpmanager/rtpsession.h: Make it possible for the session manager to instruct us to send EOS. We currently will EOS when the session is a sender and when the sender part goes EOS. This is not entirely correct behaviour because the session could still participate as a receiver. Fixes #549409.