[Bug 797195] New: gst_rtsp_media_seek fails after pipeline is playing

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

Bug ID: 797195
Summary: gst_rtsp_media_seek fails after pipeline is playing
Classification: Platform
Product: GStreamer
Version: 1.14.x
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@b-kl.de
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

Patricia Muscalu <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@axis.com

--- Comment #1 from Patricia Muscalu <***@axis.com> ---
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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #2 from Ben <***@b-kl.de> ---
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() ?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #3 from Patricia Muscalu <***@axis.com> ---
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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #4 from Benjamin Kleine <***@b-kl.de> ---
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-").

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #5 from Patricia Muscalu <***@axis.com> ---
(In reply to Benjamin Kleine from comment #4)

Post by "GStreamer" (GNOME Bugzilla)
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.

Post by "GStreamer" (GNOME Bugzilla)
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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #6 from Benjamin Kleine <***@b-kl.de> ---
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".

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #7 from Benjamin Kleine <***@b-kl.de> ---
Created attachment 373897
--> https://bugzilla.gnome.org/attachment.cgi?id=373897&action=edit
Example code

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #8 from Benjamin Kleine <***@b-kl.de> ---
Created attachment 373898
--> https://bugzilla.gnome.org/attachment.cgi?id=373898&action=edit
Example video

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #9 from Patricia Muscalu <***@axis.com> ---
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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #10 from Patricia Muscalu <***@axis.com> ---
Created attachment 373900
--> https://bugzilla.gnome.org/attachment.cgi?id=373900&action=edit
Don't block streams before seeking

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #11 from Benjamin Kleine <***@b-kl.de> ---
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

Mathieu Duponchelle <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #373900|none |reviewed
status| |

--- Comment #12 from Mathieu Duponchelle <***@gmail.com> ---
Review of attachment 373900:
--> (https://bugzilla.gnome.org/review?bug=797195&attachment=373900)

::: 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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #13 from Patricia Muscalu <***@axis.com> ---
(In reply to Mathieu Duponchelle from comment #12)

Post by "GStreamer" (GNOME Bugzilla)
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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

Mathieu Duponchelle <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #14 from Mathieu Duponchelle <***@gmail.com> ---
(In reply to Patricia Muscalu from comment #13)

Post by "GStreamer" (GNOME Bugzilla)
(In reply to Mathieu Duponchelle from comment #12)

Post by "GStreamer" (GNOME Bugzilla)
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 :)

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #15 from Patricia Muscalu <***@axis.com> ---
(In reply to Mathieu Duponchelle from comment #14)

Post by "GStreamer" (GNOME Bugzilla)
(In reply to Patricia Muscalu from comment #13)

Post by "GStreamer" (GNOME Bugzilla)
(In reply to Mathieu Duponchelle from comment #12)

Post by "GStreamer" (GNOME Bugzilla)
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

--- Comment #16 from Mathieu Duponchelle <***@gmail.com> ---
(In reply to Patricia Muscalu from comment #15)

Post by "GStreamer" (GNOME Bugzilla)
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?

Post by "GStreamer" (GNOME Bugzilla)
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 :)

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797195

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

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

--- Comment #17 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/49.