GNOME Bugzilla – Bug 738279
rtsp-server : Async done message handling in pause and play case
Last modified: 2018-11-03 15:38:05 UTC
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.
currently I am working on this issue.
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.
Created attachment 289642 [details] [review] patch for pause and play Need to take the patch from suspend/unsuspend (bug 738567) before this patch.
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.
Any progress since ?
Currently there is no ongoing work from my side.
-- 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.