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
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel