[Bug 748814] discoverer: Add serialization methods.

[GStreamer (GNOME Bugzilla)]

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

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #302934|none                        |needs-work
             status|                            |

--- Comment #5 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
Comment on attachment 302934
  --> https://bugzilla.gnome.org/attachment.cgi?id=302934
discoverer: Add serialization methods.

Thanks, I prefer the GVariant variant, since the parsing is less awkward IMHO.

 - as discussed on IRC, we should just provide to/from_variant(); if anyone
wants to convert that to/from strings, they're free to do that using the
GVariant API themselves, but returning the GVariant is more useful for those
who just want to store/retrieve the data as a blob of bytes (otherwise they'd
have to first convert the string we return back to a variant and then store
that).

 - all these g_quark_to_string (_XYZ_QUARK) should just be string constants
("xyz") or defines that are string constants. Quarks make no sense here as far
as I can tell and just incur unnecessary locking/lookup/memory overhead.

 - some of the code could probably be simplified, e.g. let's take
serialize_common_stream_info():

      - {sv} + "foo", g_variant_from_string("bar")
            could just be
        {ss} = "foo", "bar"
            unless you need the possibility to stash other
            types than strings in here later (you can still
            change it later and decide depending on the type
            then though).

      - not everything has to be stuffed into a dict, and
        fields can be made nullable, so if we don't have
        some piece of info we can just leave it as not set

      - I'd probably use something like (va(yv)),
        [I hope I remember the notation right here; I'm
        not exactly a GVariant ninja, so take with a
        grain of salt]
        where the first variant is the common info which
        could just be (msmsmsms) ie. four maybe strings
        (id, caps, tags, misc). We can still extend that
        later if needed. Followed by an array of child
        infos: the 'y' would be a byte/char to mark the
        type that follows: audio/video/sub/container
        (a/v/s/c) Perhaps even the top-level should have
        this byte marker for consistency, dunno.

      - similar thoughts apply to all the other infos

      - if you use dicts you store all the names
        ('framerate-denom') etc. in the serialisation,
        whereas if you made it e.g. mumum(uu)m(uu) for
        then the "schema" is implicit and you save a
        bit of overhead. Less nice to read when serialised
        of course, because one needs to know what the
        fields mean.

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