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 704441 - Preparing a media blocks the server thread
Preparing a media blocks the server thread
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-18 07:45 UTC by Sebastian Dröge (slomo)
Modified: 2013-10-04 04:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2013-07-18 07:45:48 UTC
gst_rtsp_media_prepare() currently is called from the main server thread, and does a g_cond_wait_until() until the media pipeline is pre-rolled. As this can take some time depending on the pipeline, the server thread will be blocked for some time. And especially a) can't take any new connections during that time (allowed backlog there is 5 currently, easy to drop connections) and b) can't send anything to already connected clients (creating bursts afterwards and potential fillup of the GstRTSPConnection backlog, or dropping of packets, or ...)


Instead of the GCond this should probably be done by stopping code flow for this media after the pipeline is set to PLAYING, at the place where the GCond is currently signaled add an idle callback to the main context and from there continue the code flow as before.
Comment 1 Wim Taymans 2013-07-18 07:49:56 UTC
Solotions to run the client and prepare in a different thread has been implementated a long time ago...
Comment 2 Sebastian Dröge (slomo) 2013-07-18 08:31:47 UTC
Also clients are now running in a separate thread by default anyway, and this behaviour can be controlled with the thread pool. So there's at least no risk to drop new connections with the default behaviour.

Marking as enhancement, not really an urgent need :)
Comment 3 Wim Taymans 2013-10-04 04:49:34 UTC
Closing, not sure what needs to be done more here.