GNOME Bugzilla – Bug 602275
[API] Add new sink-message event
Last modified: 2012-07-07 07:19:59 UTC
Hi, attached patches add a new event type: sink-message. This event is to be used by elements, that want to post messages synchronized to the stream. Example would be the level/spectrum elements, that want their analysis messages to be posted at the time when the audio reached the sink and not earlier. Also I want to use this to fix bug #584987.
Created attachment 148021 [details] [review] event: API: Add sink-message event gst_event_new_sink_message() gst_event_parse_sink_message() This event is used for sending a GstMessage downstream and synchronized with the stream, to be posted by the sink once it reaches the sink.
Created attachment 148022 [details] [review] basesink: Handle the new sink-message event
Hrm. Unfortunately things like level/spectrum want to send these messages when the audio is _played_, not when it reaches the sink (hundreds or thousands of milliseconds later, depending on how the sink is configured). So this by itself doesn't help with getting synchronised messages for these sorts of elements.
Ok, what would you suggest then? :) Can we know in basesink when a buffer is really rendered?
Probably this is the right thing to do in basesink, and we want to override this behaviour in GstAudioSink or GstBaseAudioSink. I'm not immediately sure how to do that in the audio sink either - but it should be possible?
Right... (base)audiosink could override the behaviour in the event vfunc ;) But even for basesink this probably isn't the intended behaviour. The message would be posted synchronized to the stream but that would be immediately when it reaches the sink if I'm not mistaken. What is wanted is, that the message is posted right before the next buffer is rendered. Should be relatively easy to fix I guess (by caching the events in basesink and doing it all before the next buffer is there, flushing the event cache on flush events/state changes, etc). I'll do that later :)
Ok, committed this after a review by Wim. Handling of the events in the sinks can be improved later on demand ;)
What about message aggreation at the bin level, like done for EOS messages. In other words: do we maybe want/need a flag here as well to signal whether bins should aggregate the messages or not?
How should this be done in a generic way? Patch in bug #584987 does this btw