It was previously a mix and match of both variants, introducing just too much
confusion.
The prefix are from now on:
* GstMpegts for structures and type names (and not GstMpegTs)
* gst_mpegts_ for functions (and not gst_mpeg_ts_)
* GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_)
* GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_)
The rationale for chosing that is:
* the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts)
* the namespace is one word under Gst
* it's shorter (yah)
While it was a great idea, various g-i based bindings don't support
GArray with entries greater than sizeof(gpointer) :(
So let's just make everybody happy by just using GPtrArray.
And since we're breaking the API, also rename the various descriptor fields
to no longer have the descriptor_ prefix.
It does cost a bit more in terms of memory/cpu usage, but makes it usable
from bindings.
* Add a base page for the library
* Add pages for the base MPEG-TS section and descriptors
* Add pages for the known variants
* Add documentation on more fields/sections/types
* Remove some fixmes that were ... fixed
Sorry for this :( But this makes it more in sync with expected type
naming in gobject (i.e. CamelCase and not CamelMAYBECase).
Also split descriptor type enums into the different variants:
* ISO H.222.0 / 13818-1 (i.e. standard mpeg-ts)
* DVB
* ATSC
* ISDB
* miscellaneous
This will avoid future clashes when specs use the same descriptor type
Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section
Information as well as descriptors for usage by plugins and applications.
This replaces entirely the old GstStructure-based system for conveying
mpeg-ts information to applications and other plugins.
Parsing and validation is done on a "when-needed" basis. This ensures
the minimal overhead for elements and applications creating and using
sections and descriptors.
Since all information is made available, this also allows applications
to parse custom sections and descriptors.
Right now the library is targeted towards parsing, but the structures
could be used in the future to allow applications to create and inject
sections and descriptors (for usage by various mpeg-ts elements).
https://bugzilla.gnome.org/show_bug.cgi?id=702724
