After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758319 - rtsp-server: Seeking often hangs forever, waiting for prerolling to happen again
rtsp-server: Seeking often hangs forever, waiting for prerolling to happen again
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-19 08:26 UTC by Sebastian Dröge (slomo)
Modified: 2015-12-02 06:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
rtsp-stream: Only create RTP sending/receiving rtpbin pads if needed (15.19 KB, patch)
2015-11-19 13:04 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2015-11-19 08:26:09 UTC
After a seek, gst-rtsp-server waits for the media to preroll again... that is for async-done. However this is often not posted as there are some NO_PREROLL elements in the media pipeline (RTCP udpsrc for example) even if the media itself is not live (e.g. coming from a file). GstBin is going to ignore async-start in such cases and never post async-done, so gst-rtsp-server just waits forever.

This does not happen during the initial prerolling as the live elements seem to be all in locked-state, so their state is not changed yet, NO_PREROLL is not returned and GstBin thinks everything is not live.
Comment 1 Sebastian Dröge (slomo) 2015-11-19 13:04:37 UTC
Created attachment 315881 [details] [review]
rtsp-stream: Only create RTP sending/receiving rtpbin pads if needed

Adding them when not needed will start some logic inside rtpbin that might be
problematic. Also if e.g. for a sender media we suddenly receive RTP data, we
would start up a rtpjitterbuffer and behave in weird ways.

We still set up the UDP sources for RTP receiving for a sender media to be
able to receive any packets sent by the client for NAT traversal. They will
all go to a fakesink though.

Having an rtpjitterbuffer in the media pipeline will cause the pipeline to be
NO_PREROLL, which will cause deadlocks when seeking the media as it will never
receive ASYNC_DONE after a seek.
Comment 2 Olivier Crête 2015-11-19 20:18:58 UTC
Review of attachment 315881 [details] [review]:

::: gst/rtsp-server/rtsp-stream.c
@@ +2292,3 @@
+      priv->funnel_fakesink = gst_element_factory_make ("fakesink", NULL);
+      /* We don't want events and queries to be sent to this sink from GstBin */
+      GST_OBJECT_FLAG_UNSET (priv->funnel_fakesink, GST_ELEMENT_FLAG_SINK);

We don't really need RTP udpsrc->fakesink. We can just create the socket and let the kernel drop the packets once the buffer is full. Possibly event so g_socket_set_option(SO_RCVBUF, 1) to force the kernel to drop stuff early.... Yes I've been running rtsp-server on horribly RAM constrained hardware recently..
Comment 3 Sebastian Dröge (slomo) 2015-12-01 13:35:59 UTC
Attachment 315881 [details] pushed as 61772cb - rtsp-stream: Only create RTP sending/receiving rtpbin pads if needed
Comment 4 Sebastian Dröge (slomo) 2015-12-01 13:39:46 UTC
I updated the commit accordingly, thanks for your review :)