"GStreamer" (GNOME Bugzilla)
2015-04-13 21:19:48 UTC
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?
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.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.