[Bug 746373] New fundamental type for caps - GstFlagSet

[GStreamer (GNOME Bugzilla)]

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

--- Comment #17 from Jan Schmidt <thaytan at noraisin.net> ---
Gah. Sorry for the extra commit noise - it's late and I'm jet-lagged.

I came up with this change, that hopefully addresses Olivier's concern.
Attached as a second patch for easier reviewing. I'll push it upstream as one
commit.

I've added a gst_register_flagset() function, which takes the GType of an
existing GFlags and associates it with a new type. When serializing a
GstFlagSet, it checks if there's an associated GFlags type, and if so appends a
'human readable' form of the flags, like this:

Given flags and mask respectively of

GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_TRICKMODE |
GST_SEEK_FLAG_TRICKMODE_KEY_UNITS

and 

GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_TRICKMODE |
GST_SEEK_FLAG_TRICKMODE_NO_AUDIO;

it will be serialised as:

11:111:+GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_TRICKMODE/GST_SEEK_FLAG_TRICKMODE_NO_AUDIO

+ means the flag must be set, / means it must not be set. I thought about using
'-', but '-' is a valid character in the nick for GFlags, so it might get
confusing.

For deserialisation, the human-readable form is ignored - only the hex strings
at the start are important.

For static caps and pad templates, it's still possible to use the
GST_TYPE_FLAG_SET as the GValue type, and it will be serialized only as the hex
values, and therefore be deserialisable from the registry. For intersection, it
doesn't matter what the final GstFlagSet type is - it's possible to intersect a
derived GstFlagSet type with a GValue containing a 'raw' GstFlagSet.

In the future, I think we could add extra types as a registry feature, to be
loaded as a plugin that will provide a GType by name - then we could serialise
the full human-readable form in the registry for gst-inspect and friends.

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