Broadcasting events?

[aag]

What would be the easiest way to broadcast an event from an element to the entire pipeline? Specifically, send an event from an element in a tee branch so it'd reach the elements in another branch of the same tee?

[Sebastian Dröge-3]

On Di, 2016-04-26 at 08:04 -0700, aag wrote:
> What would be the easiest way to broadcast an event from an element
> to the entire pipeline? Specifically, send an event from an element
> in a tee branch so it'd reach the elements in another branch of the
> same tee?

That's not possible without either code change in tee or giving those
elements knowledge about the pipeline topology, which is unclean.

For the latter, you could walk the pipeline graph from that element up
to the tee, and then send the event to the sinkpad of the tee.


What's the bigger picture of what you're trying to do here?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[aag]

The general use case is to run analytics on media in one branch of the tee, and produce output (using the  feedback from analytics) in the other. Running analytics in the same branch isn't an option, because media quality may need to be degraded before passing it on.

[Sebastian Dröge-3]

On Mi, 2016-04-27 at 07:27 -0700, aag wrote:
> The general use case is to run analytics on media in one branch of the tee,
> and produce output (using the  feedback from analytics) in the other.
> Running analytics in the same branch isn't an option, because media quality
> may need to be degraded before passing it on.

You could put the analytics element before the place where you degrade
quality, I'm not sure I understand why they couldn't be in the same
branch.

But what you want to do there sounds like it is better solved with one
of these two options:

a) you put the tee, analytics and the element that does something with
the analytics results into a single GstBin subclass. analytics would
post messages with the results, the GstBin subclass would catch those
in GstBin::handle_message(), handle them and pass whatever is needed to
the element(s) that are doing something with the analytics

b) analytics and the elements that do something with the results have
to share some kind of context object over which they communicate, e.g.
some kind of message queue or similar that the application is setting
on both of them via properties for example.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[aag]

Do you think there'd be a value in adding a parameter-controlled behavior to the stock tee, which if enabled, would forward all the events received on src pads to all the other src pads? I think there could be a utility for that outside of my use case.

One more question is -- are all sinkpad events in tee forwarded to each srcpad by default?

[aag]

One other possibility -- is using bus/messages a suitable approach for something like this? Or is it too expensive for broadcasting high frequency events?

[Sebastian Dröge-3]

On Fr, 2016-04-29 at 07:39 -0700, aag wrote:
> Do you think there'd be a value in adding a parameter-controlled behavior to
> the stock tee, which if enabled, would forward all the events received on
> src pads to all the other src pads? I think there could be a utility for
> that outside of my use case.
>
> One more question is -- are all sinkpad events in tee forwarded to each
> srcpad by default? 

Events have a direction, you can forward an event that arrives on a
srcpad (goes upstream) to a srcpad (goes downstream). It is also a very
specific use case that you have here, which can be implemented in a
cleaner way how I described in the previous mail.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Fr, 2016-04-29 at 11:35 -0700, aag wrote:
> One other possibility -- is using bus/messages a suitable approach
> for something like this? Or is it too expensive for broadcasting high
> frequency events?

messages are as expense as events, but you'll have to see if they are
too expensive for what you're doing.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel