[Bug 760267] New: tracer: how to pass and structure tracing data (GstStructure, GVariant, etc.)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=760267

            Bug ID: 760267
           Summary: tracer: how to pass and structure tracing data
                    (GstStructure, GVariant, etc.)
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: t.i.m at zen.co.uk
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: ensonic at sonicpulse.de, francisv at mail.uio.no,
                    hk at getslash.de, julien.isorce at gmail.com,
                    kripton at kripserver.net, marcin.kolny at gmail.com,
                    mduponchelle1 at gmail.com, slomo at coaxion.net,
                    t.i.m at zen.co.uk, thiagossantos at gmail.com,
                    tsaunier at gnome.org, vjaquez at igalia.com
     GNOME version: ---

+++ This bug was initially created as a clone of Bug #733187 +++

Discussion bug about gst_tracer_log_trace() and/or in what way/format to best
pass trace data from the tracer.

Currently a GstStructure is passed. It might be nice to have a variant that
takes a vararg function so tracers don't have to do the gst_structure_new(..)
dance. The other reason the vararg approach might be nice is that it gives us
more options later to stuff the contents into something else or
process/serialise them more efficiently. Additionally, I wonder if it'd make
sense to specify explicitly what types are accepted (we seem to use
GST_TYPE_STRUCTURE a lot for nesting, which seems unfortunate in this context
to make it generic).

GVariant would be perfect for this, only that unlike GstStructure it doesn't
make fieldnames mandatory, although we could just require GVariant with
key/value tuples like we do in GstStructure.

Of course we could always add some other format in future if we want to.

GstStructure's killer feature is that it's very free-form and easy to
read/write due to the name/type/value triplets. The downside is that it's very
verbose and comparatively expensive to serialize.

IRC discussion from today:
11:03:23 ensonic: regarding tracer and why gst_tracer_log_trace() is using a
structure right now: this allows us to deserialize the strcuture back (as done
in gststats.c), I'll take another look at gvariant to see if I could use that
instead
11:10:10 tim: yeah, I was mostly thinking out loud there :)
11:11:14 tim: the downside with GVariant is that it doesn't have fieldnames by
default, so it's less convenient
11:11:53 tim: the upside is that it's restricted to serialisable types
11:16:05 tim: where in gststats.c is anything deserialized?
11:22:43 tim: I guess my worry is the overhead, if all the
GValue/GValueTable/GType/GstValue scales well
11:30:49 ensonic: gst_structure_from_string() at line793
11:33:06 ensonic: I have a little ipc library in buzztrax that uses dbus like
specs: ipc_send(channel, "iis", 5, 7, "test"); where ipc_send is a var-args
func.
11:34:05 tim: ah, gst-stats.c :)
11:34:14 ensonic: there I can also add fields (at the end)
11:34:31 tim: yeah, that's basically how GVariant works as well
11:34:50 ensonic: I'll try to prototype something using gvariant
11:35:05 tim: the advantage of GstStructure is the triplet-structure
11:35:21 tim: which allows tracers to log data almost free-form, just giving
names to fields
11:35:28 ensonic: jep
11:35:47 tim: with the dbus/gvariant style you either need to know what each
field means or you require field names to be added everywhere
11:35:48 ensonic: and the apps can read the tracer spec (also structure) to
understand it
11:36:33 ensonic: for gvariant we can also log a spec first and the apps can
parse the spec and then know what the gvariant logs mean
11:36:40 tim: right
11:36:47 ensonic: so we only need to log e.g. the field names once
11:36:53 tim: the amount of data you have to serialiase and send is much less
then
11:37:03 tim: -a
11:37:12 ensonic: yeps
11:38:08 ensonic: let me try a few things, but lunch first :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.