Trying to undersand g_signal_connect()

[rick b]

All, I'm working through the gstreamer tutorial https://gstreamer.freed
esktop.org/data/doc/gstreamer/head/manual/manual.pdf

On page page 43 is a simple streaming example. One of the things they
are showing is how to connect a callback to a signal. In this case, whe
a pad is added


=======================================================================
Here is where the signal is connected in the main function
=======================================================================
g_signal_connect( demuxer, "pad-added", G_CALLBACK( on_pad_added ),
decoder );



=======================================================================
Here is the code for the callback
======================================================================
static void on_pad_added( GstElement *element, GstPad *pad, 
                                        gpointer data )
{
        GstPad  *sinkpad;
        GstElement  *decoder = ( GstElement * ) data;

        /* We can now link this pad with the vorbis-decoder sink pad */
        g_print( "Dynamic pad created, linking demuxer/decoder\n" );

        // Get the sink pad from the vorbis decoder element 
        sinkpad = gst_element_get_static_pad( decoder, "sink" );

        gst_pad_link( pad, sinkpad );

        gst_object_unref( sinkpad );
}




In the code is the following comment

* note that the ogg demuxer will be linked to the vorbis decoder 
* dynamically. The reason is that Ogg may contain various streams 
* (for example audio and video). The source pad(s) will be created
* at run time, by the ogg demuxer when it detects the amount and 
* nature of streams. Therefore we connect a callback function which 
* will be executed when the "pad-added" is emitted.

I get the comment. But what is throwing me off is the actual code for
the definition of the callback. It's taking a pointer to an element,
but that element is not even being used. I might have thought that it
was a pointer to the demuxer.  

Which leads me to... Why are we adding the demuxer to the g_signal_call
?  Also where is the connection from the demuxer to the decoder? Is the
GstPad pad the pad on the demuxer???  

I guess what is throwing me off is the definition of calling 
g_signal_connect with it's required parameters and the declaration of
on_pad_added and it's function definition.  


Anyway, thanks for any clarification!!!

Rick




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

[Enrique Ocaña González]

El jueves, 3 de noviembre de 2016 4:44:04 (CET) Rick Blacker escribió:

> g_signal_connect( demuxer, "pad-added", G_CALLBACK( on_pad_added ),
> decoder );
>
> static void on_pad_added( GstElement *element, GstPad *pad,
> gpointer data )
> {
> GstPad *sinkpad;
> GstElement *decoder = ( GstElement * ) data;
> sinkpad = gst_element_get_static_pad( decoder, "sink" );
> gst_pad_link( pad, sinkpad );
> gst_object_unref( sinkpad );
> }
>
> I get the comment. But what is throwing me off is the actual code for
> the definition of the callback. It's taking a pointer to an element,
> but that element is not even being used. I might have thought that it
> was a pointer to the demuxer.  
>
> Which leads me to... Why are we adding the demuxer to the g_signal_call
> ?  Also where is the connection from the demuxer to the decoder? Is the
> GstPad pad the pad on the demuxer???  
>
> I guess what is throwing me off is the definition of calling
> g_signal_connect with it's required parameters and the declaration of
> on_pad_added and it's function definition.  

The callback takes 3 arguments (even if they're not used) because the signal
definition demands that particular callback signature. That's how the API is.
The programmer (user) can't decide about that.

GstOggDemux[1] is a subclass of GstElement, and all GstElements offer the pad-
added signal[2]. Note that for some reason which has always striked me,
signals are only documented in developer.gnome.org.

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
  decoder.
- 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 pad (2nd parameter) with the
  demuxer. How do we get a pointer to the demuxer from inside the callback?
  Using a global variable? That's not very elegant nor scalable (in a scenario
  with several demuxers). The best way is to pass a pointer to the demuxer 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.

I hope to have shed some light on why the example code is like that.

Cheers.


[1] https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-oggdemux.html
[2] https://developer.gnome.org/gstreamer/stable/GstElement.html#GstElement-pad-added
[3] https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/
GstBin.html#gst-bin-get-by-name






--
Enrique Ocaña González
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Enrique Ocaña González]

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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeudi 03 novembre 2016 à 13:44 +0100, Enrique Ocaña González a
écrit :
> GstOggDemux[1] is a subclass of GstElement, and all GstElements offer the pad-
> added signal[2]. Note that for some reason which has always striked me, 
> signals are only documented in developer.gnome.org.

Because GObjects don't hold this information, it requires parsing the
source code.

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