GNOME Bugzilla – Bug 706387
rtpbin: Can not stop pipe with EOS event
Last modified: 2018-05-06 12:26:20 UTC
A pipeline that contains a rtpbin can not be stopped by sending an EOS event to the pipe. For example: gst-launch-1.0 -ve rtpbin name=rtpbin udpsrc ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! h264parse ! matroskamux ! filesink location=test.mkv If ctrl-c is pressed to stop the pipe, gst-launch just outputs "Waiting for EOS..." but nothing happens.
For git: commit 587dc055e94abd31a5abdafd9859ba2733a952d9 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Aug 20 14:36:59 2013 +0200 jitterbuffer: handle EOS When the queue is empty, and we received EOS, pause and push an EOS event downstream. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=706387
That pipeline generates an error for me, maybe that's what you see? can you paste the output you see in the console here? If I fix the caps of matroskamux, it works for me.
I simply tried: gst-launch-1.0 -ve rtpbin name=rtpbin udpsrc ! identity silent=false ! rtpbin.recv_rtp_sink_0 rtpbin. ! fakesink without any udp input.
Yes, if I set the caps (with framerate) and the sender is active, it works for me too. But if the sender is not active (no data arrives at the receiver's UDP port), rtpbin seems to ignore the EOS event. Is that behavior intended? For example, this pipe stops on EOS, even if no data is received: gst-launch-1.0 -ve udpsrc port=5000 ! $VCAPS ! fakesink -ve Whereas this pipe keeps waiting on EOS: gst-launch-1.0 -ve rtpbin name=rtpbin udpsrc port=5000 ! $VCAPS ! rtpbin.recv_rtp_sink_0 rtpbin. ! fakesink -ve VCAPS="application/x-rtp,clock-rate=90000,payload=96,encoding-name=H264, media=video"
(In reply to comment #4) > Yes, if I set the caps (with framerate) and the sender is active, it works for > me too. > > But if the sender is not active (no data arrives at the receiver's UDP port), > rtpbin seems to ignore the EOS event. Is that behavior intended? Yes, that's expected, the sink is not linked at that time, so no EOS can go on the bus.
Ok, but I still have a problem with rtpbin and EOS. This pipe ignores EOS events, even if data is flowing: gst-launch-1.0 -ve rtpbin name=rtpbin udpsrc port=5000 ! $VCAPS ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! avdec_h264 ! xvimagesink rtpbin.send_rtcp_src_0 ! fakesink sync=false async=false VCAPS="application/x-rtp,clock-rate=90000,payload=96,encoding-name=H264, media=video" The video is displayed correct, but if I press ctrl-c I only get "Waiting for EOS...". If I remove rtpbin.send_rtcp_src_0 and the fakesink from the pipe, EOS works correct. Do I have to do something special if I use rtpbin.send_rtcp_src_0 in a pipe?
(In reply to comment #6) > Ok, but I still have a problem with rtpbin and EOS. > > This pipe ignores EOS events, even if data is flowing: > > gst-launch-1.0 -ve rtpbin name=rtpbin udpsrc port=5000 ! $VCAPS ! > rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! avdec_h264 ! xvimagesink > rtpbin.send_rtcp_src_0 ! fakesink sync=false async=false > > VCAPS="application/x-rtp,clock-rate=90000,payload=96,encoding-name=H264, > media=video" > > The video is displayed correct, but if I press ctrl-c I only get "Waiting for > EOS...". If I remove rtpbin.send_rtcp_src_0 and the fakesink from the pipe, EOS > works correct. > > Do I have to do something special if I use rtpbin.send_rtcp_src_0 in a pipe? Nothing special. This is a bug, the EOS should also be sent on the RTCP pad when requested.
A bit more complicated than just forwarding EOS: When EOS is received on the session recv_rtp_sink, it means the receiver part is stopping, it's still possible that we want to send RTCP, so we can't really send EOS on the send_rtcp_src pad, we need to wait until all sources time out and we have an empty session. We could assume that when we also get EOS on the recv_rtcp_sink pad, we are never going to hear anything from the sources anymore and we can time them out immediately and send EOS on the send_rtcp_src pad.
Maybe fixed by this? https://github.com/GStreamer/gst-plugins-good/commit/3e11ce43b9e83aff5d92e6209e38d268d564edcf https://bugzilla.gnome.org/show_bug.cgi?id=728017
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!