Discussion:
[Bug 747801] New: rtsp server does not send BYE on EOS
"GStreamer" (GNOME Bugzilla)
2015-04-13 21:19:48 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=747801

Bug ID: 747801
Summary: rtsp server does not send BYE on EOS
Classification: Platform
Product: GStreamer
Version: unspecified
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@gmail.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

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?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
"GStreamer" (GNOME Bugzilla)
2015-04-22 17:16:22 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=747801

Nicolas Dufresne (stormer) <***@collabora.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@collabora.
| |co.uk

--- Comment #1 from Nicolas Dufresne (stormer) <***@collabora.co.uk> ---
This looks like a duplicate of
https://bugzilla.gnome.org/show_bug.cgi?id=739265
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
"GStreamer" (GNOME Bugzilla)
2015-04-24 07:43:25 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=747801

George Kiagiadakis <***@collabora.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@collabor
| |a.com

--- Comment #2 from George Kiagiadakis <***@collabora.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #1)
Post by "GStreamer" (GNOME Bugzilla)
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
"GStreamer" (GNOME Bugzilla)
2015-04-28 18:55:47 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=747801

Heinrich Fink <***@toolsonair.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@toolsonair.com
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
"GStreamer" (GNOME Bugzilla)
2018-11-03 15:38:29 UTC
Permalink
https://bugzilla.gnome.org/show_bug.cgi?id=747801

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #3 from GStreamer system administrator <***@gstreamer.net> ---
-- 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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
Loading...