GNOME Bugzilla – Bug 504040
gst_element_send_event() does not pass events to default event handler if the overloaded handler did not handle them
Last modified: 2007-12-17 17:08:05 UTC
Please describe the problem: See summary. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 101123 [details] [review] Fix for gst_element_send_event(). If the GstElement subclass installed an event handler, and this event handler returns FALSE to indicate that the event was not handled, the event is discarded. Send the event to the default handler which will forward it to the appropriate pad instead.
Since we don't have flow returns for the event functions yet, the semantics of this are a bit screwy - it's hard to differentiate between 'baseclass wants to just drop the event' and 'baseclass pushed it, but downstream returned FALSE' etc. There are one or two similar bugs about this things in other contexts IIRC. I'm not really convinced changing the semantics of this now is a good idea. The derived class can always chain up in cases where we think it makes sense though. As far as the specific case of gst_element_send_event(source, gst_event_new_eos()) goes: I'm not sure if if letting the app push a serialised event from the app thread is a good idea, since this may block under some circumstances. I think it should be done like the FIXME in gstbasesrc.c suggests, ie. queued and then handled from the streaming thread (pushing an EOS event is not really the same as 'performing eos logic' in all cases).
The use case is the following. My pipeline is: souphttpsrc ! motion JPEG HTTP stream from camera multipartdemux ! metadataparse ! extract image size from JPEG, bug 503616 queue ! matroskamux ! patched to not require redundant framerate in caps filesink I need to be able to interrupt the pipeline and finish off the Matroska file cleanly. The only solution that does not result in filesink going to READY and refusing subsequent writes from matroskamux to close off the file cleanly (and write the duration header), is to send an EOS event to souphttpsrc. However, GstBaseSrc's event handler does not handle an EOS event and returns false. The event is then discarded and the pipeline continues.
We can't change the semantics now and the purpose of the custom element event handler is to handle the event or chain up to the parent (instead of chaining up to the parent by returning FALSE).