[Bug 794966] New: rtsp-stream: avoid deadlock when playing a media where some streams are inactive

["GStreamer" (GNOME Bugzilla)]

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

Bug ID: 794966
Summary: rtsp-stream: avoid deadlock when playing a media where
some streams are inactive
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@axis.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

If playing a media with multiple streams, all originating from the same single
threaded source, such as a a matroska demuxer, the streaming will be blocked
when the inactive parts of the pipeline are filled. This is because there are
blocking probes attached to those streams.
We can avoid that by letting the probes drop buffers when playing.

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #1 from Branko Subasic <***@axis.com> ---
Created attachment 370516
--> https://bugzilla.gnome.org/attachment.cgi?id=370516&action=edit
Drop buffers in blocking probe attached to inactive streams

["GStreamer" (GNOME Bugzilla)]

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

Sebastian Dröge (slomo) <***@coaxion.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@coaxion.net

--- Comment #2 from Sebastian Dröge (slomo) <***@coaxion.net> ---
Instead of keeping the pad probe and dropping buffers, why don't we just
unblock and let buffers disappear by themselves?

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #3 from Sebastian Dröge (slomo) <***@coaxion.net> ---
Also if the stream is already blocked, setting it to drop buffers won't have
any effect because the probe would not be called again, or am I missing
something?

["GStreamer" (GNOME Bugzilla)]

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

Sebastian Dröge (slomo) <***@coaxion.net> changed:

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

--- Comment #4 from Sebastian Dröge (slomo) <***@coaxion.net> ---
Review of attachment 370516:
--> (https://bugzilla.gnome.org/review?bug=794966&attachment=370516)

::: gst/rtsp-server/rtsp-media.c
@@ +4385,2 @@
+ /* a stream transport is connected to a stream from it's creation to it's
+ * destruction and thus it must be possible to obtain "it's" stream while

its not it's :)

::: gst/rtsp-server/rtsp-stream.c
@@ +4686,3 @@
+ g_mutex_lock (&priv->lock);
+ if (!priv->is_complete) {
+ priv->drop_buffers = TRUE;

This seems a bit unintuitive. If setting it to dropping it should probably
always do that.

["GStreamer" (GNOME Bugzilla)]

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

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

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

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