GNOME Bugzilla – Bug 797195
gst_rtsp_media_seek fails after pipeline is playing
Last modified: 2018-11-03 15:42:52 UTC
There seems to be a seeking issue concerning gstreamer rtsp-server versions 1.13+. I want to play an existing h264-video file using the rtsp-server and seek to a specific timestamp after the pipeline has been completely set up. The initial connection is established correctly and the video is played correctly. When calling gst_rtsp_media_seek after a few (10) seconds on the stream media, the video gets stuck and stops playing. Using older gstreamer versions (1.12.5) the media_seek call is working fine. Checking the commits, the fix of Bug #788340 might have to do with this, but I'm not that deep into the code to be able to fix it.
Can you elaborate a bit more on the problem? You send a PAUSED request after 10 seconds, followed by a new PLAY range request, is it correct?
Hi Patricia and thank you for your response. Actually I'm not sending any PLAY or PAUSED requests. I play the video using any media player (e.g. vlc) and while it is playing, I try to seek the media to a specific position using gst_rtsp_media_seek(). The seek-call is executed by my server logic and independent from the current client. Do I have to make any PLAY or PAUSE calls within the server to be able to use gst_rtsp_media_seek() ?
Thanks for your answer Ben. Ok, so the seeking is triggered somehow internally by your server application while the media pipeline is in the PLAYING state, correct? Is it a flushing seek?
Yes, the seeking is triggered by calling the gst_rtsp_media_seek() method directly on the media while it is in the PLAYING state. I don't have any influence on flushing, as the method only takes the media and a GstRTSPTimeRange as parameters. As for the time range, I use the result of gst_rtsp_range_parse("npt=15.0-").
(In reply to Benjamin Kleine from comment #4) > Yes, the seeking is triggered by calling the gst_rtsp_media_seek() method > directly on the media while it is in the PLAYING state. > > I don't have any influence on flushing, as the method only takes the media > and a GstRTSPTimeRange as parameters. > There is a corresponding _full version (gst_rtsp_media_seek_full) with a possibility of controlling the seek operation by providing a set of flags. > As for the time range, I use the result of gst_rtsp_range_parse("npt=15.0-"). Is it possible to write a simple unit test that exposes the problem or alternatively, can you provide a core dump when the problem occurs?
Unfortunately I was not able to write a unit test, as there has to be an active rtsp connection, but I narrowed it down to a minimal example. I upload the source code and an example video, which you can try yourself. The seek works for gstreamer < 1.13 and breaks for newer versions. The example plays the 1 minute video. After 8 seconds it seeks to second 15 and keeps on playing. After you started the compiled code, you have to connect using some video player (I used VLC) on "rtsp://localhost:8554/test".
Created attachment 373897 [details] Example code
Created attachment 373898 [details] Example video
Thank you very much for the provided test application. I can actually reproduced the problem reported by you. The problem is that the media is blocked and there is no data flow after the seek operation is completed. Could you please verify if the suggested patch solves the problem?
Created attachment 373900 [details] [review] Don't block streams before seeking
It worked! Thank you for your efford! I tested an adapted Patch (just with different line numbers) as I am using gstreamer 1.14.1 in my project and was able to resolve the error.
Review of attachment 373900 [details] [review]: ::: gst/rtsp-server/rtsp-media.c @@ -2738,3 @@ } else { gst_rtsp_media_set_status (media, GST_RTSP_MEDIA_STATUS_PREPARING); - if (priv->blocked) Why is priv->blocked still TRUE at that point, if the media was playing?
(In reply to Mathieu Duponchelle from comment #12) > Why is priv->blocked still TRUE at that point, if the media was playing? Good point! priv->blocked is set in media_streams_set_blocked() and it means that all streams will be set to blocked. The active streams (<=> linked streams) are unblocked in media_unblock_linked() so I guess this function should as well reset priv->blocked. Do you agree?
(In reply to Patricia Muscalu from comment #13) > (In reply to Mathieu Duponchelle from comment #12) > > > Why is priv->blocked still TRUE at that point, if the media was playing? > > Good point! > priv->blocked is set in media_streams_set_blocked() and it means that all > streams will be set to blocked. The active streams (<=> linked streams) are > unblocked in > media_unblock_linked() so I guess this function should as well reset > priv->blocked. Do you agree? Yes, that's what I was wondering about, a patch addressing that would make sense to me :)
(In reply to Mathieu Duponchelle from comment #14) > (In reply to Patricia Muscalu from comment #13) > > (In reply to Mathieu Duponchelle from comment #12) > > > > > Why is priv->blocked still TRUE at that point, if the media was playing? > > > > Good point! > > priv->blocked is set in media_streams_set_blocked() and it means that all > > streams will be set to blocked. The active streams (<=> linked streams) are > > unblocked in > > media_unblock_linked() so I guess this function should as well reset > > priv->blocked. Do you agree? > > Yes, that's what I was wondering about, a patch addressing that would make > sense to me :) This patch already makes sense, as it's wrong to block the media at this point. Anyway, I'll provide a second patch, that solves the problem of the inconsistent updates of priv->blocked, not synchronized with the media state.
(In reply to Patricia Muscalu from comment #15) > > This patch already makes sense, as it's wrong to block the media at this > point. Is it? As far as I understand it the only requirement for this API is for media_prepare to have been called previously, which means the media is not necessarily unblocked at that point right? > > Anyway, I'll provide a second patch, that solves the problem of the > inconsistent updates of priv->blocked, not synchronized with the media state. Good :)
-- 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/49.