When to use bus instead of element signals

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

When to use bus instead of element signals

Kai Wohlfahrt
Hi all,

The first chapters of the documentation say that the pipeline
communicates with the application through the bus (via messages and
events). However, a lot of the examples directly use signals on
individual elements. I'm specifically interested in the `webrtc` plugin,
and for example connect(elem, "on-negotiation-needed", ...) and
emit(elem, "create-offer", ...) signals, but "pad-added" comes up in the
tutorial for example.

For a beginner, in which cases would I listen for a bus message instead
of connecting to a signal on an element? Is it possible to turn a signal
on an element into a message on the bus? And similarly, when would I
send an event to an element instead of emitting a signal on it? I'm not
very familiar with GObject, so I might be missing something obvious.

The documentation is otherwise amazing, both in terms of thorough API
references and beginner tutorials - thank you very much :)

Kai
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: When to use bus instead of element signals

Mathieu Duponchelle
I think this mostly boils down to threading considerations:

With bus messages, you're guaranteed that your bus callback will always
be called from a single thread (unless you explicitly set a sync handler).

This means you can (mostly) avoid worrying about locks and thread
safety from your application perspective.

On the other hand, signals are useful for elements (such as webrtcbin)
that wish to either get information to the user without the overhead
of the thread marshalling (though GObject signals do involve some
overhead as well), or that need to make assumptions about their state
after they've called g_signal_emit(), for example if they rely on a return
value from the signal or on potential handlers to have performed
some action once g_signal_emit has returned.

I hope that was useful :)


On 4/9/20 11:53 AM, Kai Wohlfahrt wrote:

> Hi all,
>
> The first chapters of the documentation say that the pipeline communicates with the application through the bus (via messages and events). However, a lot of the examples directly use signals on individual elements. I'm specifically interested in the `webrtc` plugin, and for example connect(elem, "on-negotiation-needed", ...) and emit(elem, "create-offer", ...) signals, but "pad-added" comes up in the tutorial for example.
>
> For a beginner, in which cases would I listen for a bus message instead of connecting to a signal on an element? Is it possible to turn a signal on an element into a message on the bus? And similarly, when would I send an event to an element instead of emitting a signal on it? I'm not very familiar with GObject, so I might be missing something obvious.
>
> The documentation is otherwise amazing, both in terms of thorough API references and beginner tutorials - thank you very much :)
>
> Kai
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel