Don't forbid the empty string "" in generic structures, only in taglists.
Properly allow the NULL string by adding special cases for serialising
and deserialising it. prop1=(string)NULL is the NULL string,
prop1=(string)"NULL" is the actual string with the value "NULL"
Add a new macro GST_DEBUG_CATEGORY_GET to get a log category by name. This
allows plugins to use e.g. core categories like PERFORMANCE or CLOCK.
API: GST_DEBUG_CATEGORY_GET
This makes the generated code faster since:
* It won't have to read an undirect value (which will most likely be
outside of the L1/L2 cache)
* We know that value never changes (the compiler has no clue that it doesn't).
It is not too obvious that getting and releasing request pads is not entierly
symetrical regarding to the pad refcount. Add a note about that to the docs.
This might deserve a FIXME-0.11 too.
Just in case someone who clearly can't be deterred by any number of leading
underscores uses this very private but still somewhat documented symbol
directly in their code (*cough* qtdemux *cough*).
Add new method to iterate a bufferlist without having to allocate an iterator.
Add convenience method for getting an item from the list based on the group and
index.
Remove redundant _do_data callback and method.
Update unit-tests and add some more for the new methods.
Add functions to create a new tag list and set tags in one go, which
is nice for use in combination with functions that take ownership of
the taglist, such as gst_event_new_tag() or gst_element_found_tags().
API: add gst_tag_list_new_full()
API: add gst_tag_list_new_full_valist()
Update design doc with step-start docs.
Add eos field to step done message
when stepping in reverse, update the segment time field.
Flush out the current step when we are flushing.
Small micro-optimisation: look up value table for fundamental types
via an array dedicated to fundamental types instead of going through
a hash table lookup. Since there can be only 255 fundamental types,
the table size/efficiency trade-off should be acceptable, esp. since
the most commonly-used types are all fundamental types. The size of
the table could probably be minimised further if needed by allocating
the table dynamically and only expanding it on demand.
GTypes are not ints and as such are not guaranteed to fit into an int
(with the exception of fundamental types), so we really shouldn't put
them into int variables. Even if a rather unlikely obscure corner case,
this has actually been a problem at some point in the past, see commit
99f16655f4.
