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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #8 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
> Did you look at my doc?

I did, but when I first looked it was just a list of pros and cons IIRC -
better to do this in bugzilla :)

> We can make the GstStructure part even faster.

Not sure what you mean here by "GstStructure part" exactly (if you're talking
about serialization, see bug #760027 too which adds GString API, but current
GLib implementation makes that useless).


> Also your proposal to take vararg to not hardcode the structure, is not
> going to fly (sorry):
> gst_tracer_log("name", "field1", type1, val1, "field2", type2, val2, ...)
> still implies structure.

Not sure I understand. What do you mean by "this implies structure"? (Is
structure = GstStructure?) If you only allowed types like
G_TYPE_INT/STRING/FRACTION etc. we can read the values as we like. For the
spec/class part I don't care about whether it's GstStructure-based or not.

> Anyway what I proposed in the doc could actually
> get us there.
> 
> Here is the essence:
> We add a GstTracerRecord (object/miniobject). In the tracer plugin init we
> create new GstTracerRecord instances by passing the large nested
> GstStructure that described the log format. This will be extended to also
> list the types. Now gst_tracer_record_new(GstStructure *spec) will generate
> a printf style format string from the spec. That is we do a variant of
> gst_structure_to_string that instead of writing the values write the format
> placeholder (e.g. %u for an G_TYPE_UINT and % + GST_PTR_FMT for
> Caps/Structure/…). Based on that we can provide
> gst_tracer_record_log(GstTracerRecord *self, …); that will only that the
> values.

Not sure I understand fully, or why we need a 'printf format string' here, but
it sounds to me like this is going in the right direction.

I think you may be a bit too focused on how/where to serialise the data to. For
me, this is completely secondary, and I don't see us outputting to the debug
log longer-term anyway.


> Also for the size math. The gvariant output is not a third, it is 2/3 of the
> structure output.

gst_structure_to_string:
91: name, ...
g_variant_print (v, FALSE):
27: ('name', 0, 10, 'hallo', 1)
g_variant_print (v, TRUE):
48: ('name', uint64 0, uint32 10, 'hallo', uint32 1)

(not entirely fair of course, because the field names are missing, just an
indication that we need to do better than gst_structure_to_string, which we
surely can.)

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