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 767413 - tee: Properly handle return value when only 1 pad
tee: Properly handle return value when only 1 pad
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: 1.8.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-08 17:46 UTC by Nicolas Dufresne (ndufresne)
Modified: 2016-06-27 06:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tee: Properly handle return value when only 1 pad (1.21 KB, patch)
2016-06-08 17:46 UTC, Nicolas Dufresne (ndufresne)
committed Details | Review

Description Nicolas Dufresne (ndufresne) 2016-06-08 17:46:17 UTC
See commit.
Comment 1 Nicolas Dufresne (ndufresne) 2016-06-08 17:46:20 UTC
Created attachment 329416 [details] [review]
tee: Properly handle return value when only 1 pad

This patch handle the case when you have 1 pad (so the fast path is
being used) but this pad is removed. If we are in allow-not-linked, we
should return GST_FLOW_OK, otherwise, we should return GST_FLOW_UNLINKED
and ignore the meaningless return value obtained from pushing.
Comment 2 Xavier Claessens 2016-06-08 17:50:41 UTC
While at it, can we document this behaviour, please ?
Comment 3 Tim-Philipp Müller 2016-06-15 11:16:31 UTC
ooc, what's the meaningless flow return value we get without this?

What behaviour do you want to see documented Xavier?
Comment 4 Nicolas Dufresne (ndufresne) 2016-06-15 11:28:05 UTC
The flow return of a pad that is no longer there (released) has no meaning for the remaining pipeline. Before the fast path was added, that is the behaviour we had and what the patch fixes. This behaviour let you release a pad at any moment without pad probe and is neither documented or unit tested. I'm not actively working on that one this week, but I wanted to do both. This is a minor bug since we have told everyone to always use a pad probe callback.
Comment 5 Xavier Claessens 2016-06-15 14:16:56 UTC
Tim: the nice trick here is we can remove a "branch" from a tee without idle pad probe:

  gst_element_release_request_pad (tee, pad);
  gst_bin_remove (parent, sink);
  gst_element_set_state (sink, GST_STATE_NULL);

That sequence is safe (with the patch attached here), because if a buffer was in the sink element, setting its state to NULL will return GST_FLOW_FLUSHING, but since the pad was already removed from the tee, that return value is ignored and GST_FLOW_OK (or GST_FLOW_UNLINKED if that was last pad and allow-not-linked==FALSE) is propagated to the source.
Comment 6 Tim-Philipp Müller 2016-06-15 14:26:34 UTC
Ok, what I thought then, just checking I understood it right.

I've been telling people this should work without a probe, so would definitely be good to fix it if that's not the case ;)

Patch looks fine of course.
Comment 7 Sebastian Dröge (slomo) 2016-06-17 10:03:34 UTC
Attachment 329416 [details] pushed as 4603722 - tee: Properly handle return value when only 1 pad