GNOME Bugzilla – Bug 721310
GstBin: consider allowing option to block propagation of EOS
Last modified: 2014-02-04 13:31:51 UTC
Currently, when a GstBin detects that its sink elements have handled an EOS, it forwards the EOS to its parent. This is generally what ought to happen for a GstBin that operates as a sink. But there are a variety of use cases where this is inconvenient. In particular, there are applications that want to be notified of an EOS happening in a bin without that EOS getting forwarded to the pipeline and affecting other elements outside the bin. There are several ways to accomplish this. One would be to subclass GstBin just provide this functionality. Another would be to offer a property on GstBin that accepts a custom event. When set, the GstBin forwards the custom event instead of the EOS so that applications can catch it without its triggering the standard EOS response.
How does an EOS getting forwarded up the pipeline hierarchy affect other elements? There's a "forward-messages" property that forwards EOS messages (and others) from individual bins to the app without aggregating them at the pipeline level. The app just has to be aware of that then, which it will be anyway, and check for the message's source element.
Not sure either but the potential problem I see here is if you have multiple sinks and just want to drain one of them. You'll never get the EOS message in your application unless the other sink goes EOS too. The forward-message property does not seem like a solution for this as you have to set it on all bins in the hierarchy and it's rather inconvenient if all you want is to drain one sink. I think something like a sync message handler would be good to have here (which can't be used because the parent bin installs one), some signal that hooks into GstElement::post_message() or something like that. I currently don't see a clean solution other than subclassing GstBin (not convenient), forward-message on *all* bins (not convenient) or adding some new API. All this child-parent message handling should be rewritten to use GstElement::post_message() too instead of child busses, but that's a separate issue.
Maybe a gboolean post-message(GstElement *element, GstMessage *message) on GstElement, where a TRUE return value would stop emission of further handlers (like the default handler, which does gst_element_post_message() as it does now). Not sure yet if I like that API :) Also one signal emission per message might not be very clever.
Is there really a need for a sync handler for this use case? If you want to make things easier for the application, a sync handler doesn't seem the best way to me.
There is, yes. You also want to prevent the message from travelling to the higher level bins as the EOS message will confuse them.
(In reply to comment #5) > There is, yes. You also want to prevent the message from travelling to the > higher level bins as the EOS message will confuse them. This was my motivation for filing the bug, but Tim has disabused me of it, here and on IRC. For my intended use, at least, the eos bubbling up to the higher levels (for me, the pipeline and then the app), doesn't actually cause any trouble. I thought it did, but I was mistaken. Certainly all the available examples show the bus listener in the app responding to the eos by quitting, but that's not mandated, and it's easy enough to ignore the eos in the bus handler. I don't understand whether the multiple-sink use-case still justifies this bug, but my use case doesn't actually require it.
What should we do about this? I think we can just close this as WONTFIX, right? A simple bin subclass for this would look basically like this: https://git.enlightenment.org/core/efl.git/tree/src/modules/emotion/gstreamer/emotion_fakeeos.c (0.10 version, 1.x is almost the same)
(In reply to comment #7) > What should we do about this? I think we can just close this as WONTFIX, right? > No complaints from me. It turns out that the use cases for this feature are more obscure than I had thought (it turns out even I don't need it), and, as you pointed out, creating a subclass of GstBin isn't too hard. For me, the only thing that remains of this now that the dust has settled is to suggest a centralized bit of documentation on EOS handling: how common elements like GstBin, GstPipeline, and GstBaseSink handle it, that some sink elements need to see it to complete their processing, how you can go about changing default behavior should that be necessary, etc. The comments around gst_event_new_eos () probably provide the most detailed description, but, speaking as a newbie, it was hard to put the disparate pieces together into a coherent picture.