GitLab

Submitted by Xavier Claessens @xclaesse

Link to original bug (#747801)

Description

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?