Trying to undersand g_signal_connect()
Enrique Ocaña González
eocanha at igalia.com
Thu Nov 3 13:00:22 UTC 2016
El jueves, 3 de noviembre de 2016 13:44:05 (CET) Enrique Ocaña González
escribió:
Sorry, there are some mistakes in the previous email. Corrections in *bold*
below:
> The 3 parameters of the signal callback, as shown in [2] are:
- GstElement: The object which received the signal. Who is creating a new
pad? The demuxer. So the demuxer will be this element. In the particular
code of the example this info isn't needed, but in other contexts it would
be. For instance, if you register a callback on several different elements
to just log the creation of pads, you would be interested in knowing which
element created the pad. In the specific case of the example we register
the callback to only one element, so we already know that it will always be
the *demuxer*.
- GstPad: This is the pad being added (to the demuxer element).
- gpointer user_data: This is kind of a "context", or "whatever the
programmer thinks is needed for the callback to do its job". If the
callback was a logger, this parameter could have been null. In this case,
what this callback wants to do is to link the created *demuxer* pad (2nd
parameter) with the *decoder*. How do we get a pointer to the *decoder* from
inside the callback? Using a global variable? That's not very elegant nor
scalable (in a scenario with several *decoders*). The best way is to pass a
pointer to the *decoder* as "context" when registering the callback. We
could also have passed a pointer to the decoder sink pad, or a pointer to
the whole pipeline and perform a search for the decoder using
gst_bin_get_by_name()[3]. There's always more than one way to do it.
--
Enrique Ocaña González
More information about the gstreamer-devel
mailing list