[Bug 702724] first-class miniobjects/API for mpeg-ts related SI (Service Information)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702724
  GStreamer | gst-plugins-bad | git

--- Comment #10 from Edward Hervey <bilboed at gmail.com> 2013-06-23 07:51:08 UTC ---
I've put some WIP in this git branch (top 3 commits):
http://cgit.freedesktop.org/~bilboed/gst-plugins-bad/log/?h=mpegts-si

Includes:
* The new library
* mpegtsbase/tsdemux/tsparse ported
* dvb ported

I tested tsparse and tsdemux on a whole bunch of ts files (including obscure
ones) and didn't see any regression in behaviour

The only regression right now are that some descriptor info are not
parsed/extracted.
PMT:
* DESC_DVB_AC3
* DESC_DVB_DATA_BROADCAST_ID
* DESC_DVB_DATA_BROADCAST
* DESC_DVB_CAROUSEL_IDENTIFIER
* DESC_DVB_STREAM_IDENTIFIER
* DESC_ISO_639_LANGUAGE
* DESC_DVB_SUBTITLING

NIT:
* DESC_DVB_SATELLITE_DELIVERY_SYSTEM
* DESC_DVB_TERRESTRIAL_DELIVERY_SYSTEM
* DESC_DVB_CABLE_DELIVERY_SYSTEM
* DESC_DVB_FREQUENCY_LIST
* DESC_DTG_LOGICAL_CHANNEL

EIT:
* DESC_DVB_EXTENDED_EVENT
* DESC_DVB_COMPONENT

The reason why I didn't parse those descriptors above are:
1) Because they are not needed for tsdemux/tsparse/dvb usage
2) I did parse out some not-absolutely needed descriptors (EIT DESC_DVB_EVENT
and NIT network name for example) because i wanted to see more realistically
the gain of switching to non-Gvalue/GstStructure usage.

Right now the sections are mini-objects. As other people mentioned...
introspection support for them are crap, but they are the most lightweight
refcounted solution around (sections never get copied, even when put in
messages on the bus).

In order to cope with introspection support while keeping the performance gain,
I'm wondering if we couldn't:
1) Add section-specific type registration (i.e. a new GType for each)
2) Add section-specific methods to extract from messages
(gst_message_parse_pat() for example).


Another item is (better) support for descriptors. Right now they are an array
(which obviously g-i in all its glory don't detect as arrays despite provided
annotations *sigh*), which is fast to create, and fast to parse
(tag/length/extended_tag are extracted for convenience). They don't duplicate
the tag contents, and instead point to the location of that descriptor in the
section (private) data field.

1) Should we expose the list of all "known" descriptor ids ? Essentially a big
GstMpegTSDescriptorType enum with description.
2) Should we expose the macros from gst/mpegtsdemux/gstmpegdesc.h ?
3) Should we expose the method 
4) Should we create new functions (therefore introspectable) and struct to
extract information from (some) descriptors ?

And in a (much) longer run, how do we deal with creating section/descriptors
from the app level ? Right now everything is hidden nicely in regards to
allocation/freeing, but I'm wondering if that's sufficient to be able to add
later on that feature with the proposed API.


Anyway, comments welcome :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.