[Bug 738279] New: rtsp-server : Async done message handling in pause and play case

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738279
GStreamer | gst-rtsp-server | 1.4.3

Summary: rtsp-server : Async done message handling in pause and
play case
Classification: Platform
Product: GStreamer
Version: 1.4.3
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-rtsp-server
AssignedTo: gstreamer-***@lists.freedesktop.org
ReportedBy: ***@yahoo.co.in
QAContact: gstreamer-***@lists.freedesktop.org
GNOME version: ---


In scenario when server is loaded, if you perform pause and play, rtsp-server
play response contains range starting from 0.

The issue is basically when a pause carried out the multiudpsink perfroms the
asynchronous state change. This send s a ASYNC DONE message to the bus.

But if the pause and play is quick enough then play request (with range) tries
to do the rtsp_media_seek before the ASYNC DONE message is handled. But while
performing seek and flush stop event has executed, but not the new segment
event, in-between the async done is performed and query command fails because
have_segment of basesink is false and resets the rtsp-media range start value
to zero.

And because of that the server tries to send a reply back with incorrect range
which starts from zero because of the failed query during async done.

So overall the issue is media_seek should wait till the async done is
performed.

The other scenario to reproduce the issue is to send pause and play (with
range) multiple time simultaneously using a script.

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738279
GStreamer | gst-rtsp-server | 1.4.3

--- Comment #1 from Srimanta Panda <***@yahoo.co.in> 2014-10-10 09:31:27 UTC ---
currently I am working on this issue.

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738279
GStreamer | gst-rtsp-server | 1.4.3

--- Comment #2 from Srimanta Panda <***@yahoo.co.in> 2014-10-29 15:43:52 UTC ---
More explaination on the issue:

In scenario when server is loaded, if you perform pause and play (with range)
during playback mode , rtsp-server play response contains range starting from
0.


Reason:

During the pause, multiudpsink performs a async state change. And later after
the committing the state in basesink element it sends an async done message to
the bus.

But if pause and play is quick enough, before async message arrives to bus, the
play is executed. In rtsp-client.c file it tries to perform
gst_rtsp_media_seek(). And this seek event tries to perform flush-start and
flush-stop and segment events.

But suppose after flush-stop and before newsegment event, the async done
message arrives on rtsp-media bus. Then handle_message() tries to perform
collect_media_stat() and fails on query position because segment event is not
executed yet. This resets the range start to zero.
That's why the we get range starting from zero on play response.

Also inside rtsp_media_seek() the wait_preroll() ends because of the delayed
async done message from the pause (although it should wait for the second async
done from the seek event).

Solution:

Before returning from pause, we should wait for async done message.

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738279
GStreamer | gst-rtsp-server | 1.4.3

--- Comment #3 from Srimanta Panda <***@yahoo.co.in> 2014-10-30 11:15:33 UTC ---
Created an attachment (id=289642)
View: https://bugzilla.gnome.org/attachment.cgi?id=289642
Review: https://bugzilla.gnome.org/review?bug=738279&attachment=289642

patch for pause and play

Need to take the patch from suspend/unsuspend (bug 738567) before this patch.

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738279
GStreamer | gst-rtsp-server | 1.4.3

--- Comment #4 from Srimanta Panda <***@yahoo.co.in> 2014-10-30 11:27:50 UTC ---
After applying this patch, when I tested few times it waits for preroll and
times out.

The reason behind this issue is it doesn't get the async done message from
multiudpsink few times.

Reason for async done message from multiudpsink doesn't appears is explained
below:

Both gst_base_sink_change_state() and gst_base_sink_chain_main() are called
with preroll lock. gst_base_sink_chain_main() is needed to post a async done
message to the bus.

After the gst_base_sink_change_state () call it is supposed to call the
gst_base_sink_chain_main (). The change state from play to pause set the
need_prerolll and call_preroll to true. But in-between multiudpsink
gst_multiudpsink_render() goes to flusing and returns GST_FLOW_FLUSHING. And
then it doesn't call gst_base_sink_chain_main() anymore. Therefore it doesnot
post async done message to the bus.


Because of this unexpected behaviour of the multiudpsink, my patch doesnot work
sometimes. So please have a look and suggest if you have any solution how to
fix this issue.

["GStreamer" (GNOME Bugzilla)]

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

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

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

--- Comment #5 from Nicolas Dufresne (stormer) <***@collabora.co.uk> ---
Any progress since ?

["GStreamer" (GNOME Bugzilla)]

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

Hyunjun <***@samsung.com> changed:

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

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #6 from Srimanta Panda <***@yahoo.co.in> ---
Currently there is no ongoing work from my side.

["GStreamer" (GNOME Bugzilla)]

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

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

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

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