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 767461 - splitmuxsink: Deadlock on serialized queries
splitmuxsink: Deadlock on serialized queries
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-09 16:03 UTC by Xavier Claessens
Modified: 2018-11-03 15:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
splitmuxsink: Avoid deadlock by droping some serialized queries (2.27 KB, patch)
2016-06-09 16:05 UTC, Xavier Claessens
none Details | Review
splitmuxsink: Avoid deadlock by droping some serialized queries (2.34 KB, patch)
2016-06-09 18:12 UTC, Xavier Claessens
none Details | Review

Description Xavier Claessens 2016-06-09 16:03:07 UTC
If a serialized query arrives into the splitmuxsink on the reference pad while buffers are queued, it will deadlock because the source is blocked and the query will never go out.
Comment 1 Xavier Claessens 2016-06-09 16:05:57 UTC
Created attachment 329483 [details] [review]
splitmuxsink: Avoid deadlock by droping some serialized queries

If the reference pad received some buffers but needs more buffers to
complete the GOP and a serialized query arrives, that query will never
leave the multiqueue because the source won't complete that GOP until
the query returns.
Comment 2 Xavier Claessens 2016-06-09 17:26:16 UTC
Forgot to tell: I didn't test this patch yet properly.
Comment 3 Xavier Claessens 2016-06-09 18:12:08 UTC
Created attachment 329496 [details] [review]
splitmuxsink: Avoid deadlock by droping some serialized queries

If the reference pad received some buffers but needs more buffers to
complete the GOP and a serialized query arrives, that query will never
leave the multiqueue because the source won't complete that GOP until
the query returns.
Comment 4 Xavier Claessens 2016-06-09 18:23:42 UTC
Ok, this time the condition works. The condition is a bit tricky in the case ctx->in_running_time == splitmux->max_out_running_time. That can mean many things:

1) No buffer ever got received, in that case they are both 0. That's the principal case where allocation queries could happen. In that case we must PASS the query.

2) We received only the first buffer and it has a running_time of 0 (that's valid, AFAIK, right?). In that case we must DROP the query.

3) The last buffer received was a keyframe and it won't be allowed to leave the queue until we received an 2nd keyframe. In that case we must DROP the query.

In case 2 and 3 ctx->queued_bufs could be empty if previous GOP already had time to leave the queue and the first buffer of next GOP (a keyframe) already got popped and it waits in complete_or_wait_on_out().
Comment 5 GStreamer system administrator 2018-11-03 15:09:49 UTC
-- 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-plugins-good/issues/279.