[Bug 733187] integrating the tracer branch

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Sep 12 00:50:36 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=733187
  GStreamer | gstreamer (core) | 1.x

Thibault Saunier <tsaunier> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |tsaunier at gnome.org
     Ever Confirmed|0                           |1

--- Comment #2 from Thibault Saunier <tsaunier at gnome.org> 2014-09-12 07:50:27 UTC ---
Overal that API makes a lot of sense to me but there are a few point I would
like to talk about:

1- Why did you choose to go with var_args to invoke the hooks? That is a bit
weird to use and that means that we won't be able to use the system from the
Introspection. I have the impression that for that case using GClosures or even
signals could make sense. This way the Tracer implementers would know what the
arguments are and potentially let us use the system from the introspection.

  The solution I can think of is (which is basically the same way of doing
things as with the bus messgage system):

  You do not actually need the notion of GstTracerHookId as it is anyway
repeated in GstTracerMessageId (and then it could be renamed to
GstTracerHookId). You would need a structure containing the information about
the hook, a GstMiniObject that has a GstTracerHookId and a GstStructure with
the various arguments.

  Then I would imagine something using signals and in the gst_tracer_dispatch
method. So it would look like:

  The GstTracer::hook:hook-id messsage definition:

    gst_tracer_signals[HOOK_SIGNAL] =
      g_signal_new ("hook", G_TYPE_FROM_CLASS (klass),
      G_SIGNAL_RUN_LAST | G_SIGNAL_DETAILED,
      G_STRUCT_OFFSET (GstTracerClass, hook), NULL, NULL,
      g_cclosure_marshal_generic, G_TYPE_NONE, 1, GST_TYPE_TRACER_HOOK_DATA);


Signal emition in gst_tracer_dispatch:

    GQuark details = gst_tracer_type_to_quark;
    g_signal_emit_valist (tracer, gst_tracer_signals[HOOK_SIGNAL], details,
                          GstTracerMessageId, var_args);

Then in the tracer implementation you would connect to the signals you need,
for example, a hook could need to operate on GST_TRACER_MESSAGE_ID_PAD_PUSH_PRE
only, in the init method of that tracer you would do:

    g_signal_connect (some_tracer, "hook:pad-push-pre", _pad_push_pre_cb);

The _pad_push_post_cb method:

      static void
      _pad_push_pre_cb (tracer, GstTracerHookData *hook_data)
      {
        GstBuffer * buffer;

        gst_tracer_hook_data_parse_pad_push_pre (hook_data, &buffer);

        /* Do you business here */
      }


2- I did not understand what the GstTracer:params property was about.

3- The GstTracer:masks property is rather a class property to me, or am I
missing something?


What do you think?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list