GNOME Bugzilla – Bug 747801
rtsp server does not send BYE on EOS
Last modified: 2018-11-03 15:38:29 UTC
I'm not sure this is a bug or if I'm doing something wrong. What I want to achieve is to close all streams of a media from server side so clients receive EOS event. To test it, I've been adding this code into test-mp4.c example, called after a 10s timeout: static GstRTSPFilterResult filter_cb (GstRTSPStream *stream, GstRTSPStreamTransport *trans, gpointer user_data) { return GST_RTSP_FILTER_REMOVE; } static gboolean close_cb (gpointer user_data) { GstRTSPMedia *media = user_data; guint i, n_streams; gst_rtsp_media_set_eos_shutdown (media, TRUE); n_streams = gst_rtsp_media_n_streams (media); for (i = 0; i < n_streams; i++) { GstRTSPStream *stream; stream = gst_rtsp_media_get_stream (media, i); if (stream == NULL) continue; gst_rtsp_stream_transport_filter (stream, filter_cb, NULL); } gst_rtsp_media_unprepare (media); return G_SOURCE_REMOVE; } The client side a this simple command: gst-launch-1.0 playbin uri=rtsp://127.0.0.1:8554/test After close_cb() is called on server, client still play for 2s (normal, it plays the cached frames). After that, image stay still for ~10s seconds, then gst-launch quits. On client side I see this message: 0:00:36.175185642 12301 0x7f8ac003a2d0 WARN rtspsrc gstrtspsrc.c:3004:on_timeout:<source> source c8dbd16b, stream c8dbd16b in session 0 timed out So that's not a clean stop of the client, it's a timeout because it doesn't receive new packets. I believe the server is supposed to send BYE command, but reading rtsp-stream.c, it does not handle the eos event in the GstAppSinkCallbacks struct. Is that a bug?
This looks like a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=739265
(In reply to Nicolas Dufresne (stormer) from comment #1) > This looks like a duplicate of > https://bugzilla.gnome.org/show_bug.cgi?id=739265 Not really. This bug is about not being able to force a client to stop with EOS, rather than receiving a TEARDOWN from the client (which is the other bug). I tracked down this one and it seems that gst_rtsp_media_set_eos_shutdown() sends an EOS to the pipeline of the media. What one expects from this is that EOS will be translated to RTCP BYE by rtpsession and BYE will be translated back to EOS in rtspsrc. However, this never happens. The reason is that if you send an EOS to the pipeline, somehow this EOS manages to reach the multiudpsink elements before rtpsession queues the BYE packet. Because in the rtp part of the pipeline there are queue elements plugged before the multiudpsink ones, the threads of the queues stop as soon as EOS gets through and after that it is impossible to send any other packet (including BYE). The solution to this problem is not to use gst_rtsp_media_set_eos_shutdown(). Simply send EOS inside the audio/video streams, which can be done by sending EOS to the "element" of the media instead of the pipeline. This ensures that the EOS will reach rtpsession first, and rtpsession will forward it downstream together with the BYE packet. I consider this a bug, since gst_rtsp_media_set_eos_shutdown() is unusable for this purpose.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/8.