[gst-devel] GDP updates and questions

[Thomas Vander Stichele]

Hi everyone,

I'm working on a GDP payloader and depayloader so that we can more
generically use GDP in GStreamer with other elements than just the TCP
ones.

As part of that, I'm running into a few things I would like some
feedback on.

a) Currently the GDP serializes every event separately based on type.
In 0.10, events now store all of the specialized info in a structure,
which we could serialize to a string instead, and get rid of a lot of
specialized code.  (We serialize caps using to_string as well btw).

Strictly speaking this would be an ABI change; however, nothing in
GStreamer actually serializes events at the moment.  The question is,
which of the following is preferred:
1) changing it without revving the GDP major/minor version
2) changing it, revving the major/minor, thus making it so older core
cannot use GDP with newer core processes
3) changing it, revving, and implementing fallback code for the older
GDP version

Personally I lean towards 1) because nobody is using the event
serialization code right now.

b) to be able to deserialize some common types of enums/flags in events,
these enums/flags need to be registered at gst_init() time, possibly in
the respective source file _init functions.  Right now a lot of them get
registered the first time they're used, which is too late for
deserializing.  Does anyone object to my doing that for the types that
we have that can currently be put into an event ?

c) our flags serialization code uses "+" as a delimiter, which seems
strange to me.  Anyone know why this is ? I would find it more logical
to use the same as in C - the "|" delimiter.

d) our flags serialization code serializes no flags to the empty string;
so when serializing a structure with unset flags, you can get something
like "...(GstSeekFlags),".  Note the comma right after the parenthesis.
Our deserialization code treats this as an error and fails to
deserialize.  Which of the following is preferable ?

1) it should serialize to "GST_SEEK_FLAG_NONE" or "0"
2) the parsing code should be changed to accept the empty string
(possibly only for flags, though it doesn't look like that would be easy
to verify at that point)

Again I lean towards 1, though it may be considered an ABI change as
well.

Suggestions welcome !

Thomas