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

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #12 from Edward Hervey <bilboed at gmail.com> 2013-06-26 06:27:43 UTC ---
Some updates.

On the side, another use-case came to mind lately: supporting some 3rd party
systems that will do the PID/SECTION filtering elsewhere (like with the DVB
kernel system) and want to have a system by which they can parse those
sections.

And I've been brainstorming the whole "when to parse" issue, "supporting g-i"
issue, etc...

To support all of that I've come up with an updated plan (still not done yet in
the git repo but won't involve that much work) which is a bit similar to how we
deal with non-subclassable miniobjects (like GstEvent) but with a twist:

1) GstMpegTSSection remains a GstMiniObject but is no longer "subclassable" (in
spirit). It contains the underlying section (unparsed) string.
2) The various "parsed" structures are registered boxed objects, which you
access by calling a method on GstMpegTSSection.

The twist is that the (refcounted) GstMpegTSSection will do the parsing of the
type-specific section only on-demand and will cache that result:

struct _GstMpegTSSection {
  .... /* Generic section fields */
  /< private >/
  guint8 *section_data;
  gpointer *cached_parsed; /* If parsing already happened, will contain the
type-specific data */
}

const GstMpegTSPMT *gst_mpeg_ts_section_get_pmt (GstMpegTSSection * section);
const GstDateTime * gst_mpeg_ts_section_get_tot (GstMpegTSSection * section);
....


This will result in moving all the type-specific parsing from
gst/mpegtsdemux/mpegtspacketizer.c to the helper library.

Bonus:
*) Still usable by mpegtsbase/tsparse/tsdemux elements where needed
*) Parsing of data only happens once
*) I can't make section parsing much cheaper (if nobody uses it, no parsing is
involved except for the base section headers and no useless memory is used) :)
*) Easier to use for bindings

=====

Another item on the list is ... dealing with g-i (sic).

I thought the boxed subclass issue would be the biggest, but the plan above
solves that. The remaining one is dealing with (efficient) arrays (Example of
the issue in bug #678663).

Right now all arrays of contents in the structures (be it arrays of programs,
events, descriptors, ...) are of the following form:
{
 ...
 guint nb_elements;
 ElementType *array; /* (array length=nb_elements) */
 ...
}

The reason why they are done as such are because I wanted to minimize memory
and cpu overhead to a minimum (array is one allocation of (nb_element *
sizeof(ElementType) and accessing any member content is a one op).

This is not supported with g-i, therefore we need to find alternatives:

1) Use a different container structure
  By making it a GList (no direct member access, requires allocating 2 *
nb_elements memory blocks (one for GList, one for ElementType)
  An alternative is making it a GArray or derivate (provides direct member
access, number of allocation is a bit lower, but still requires allocating
nb_elements memory blocks (for ElementType)

2) Provide custom getters
  Requires a lot of extra code, introducing some cpu overhead....

With the new plan of doing on-demand/if-needed parsing of sections (in the
first part), maybe the overhead of using GArray would be acceptable now, and
some macros could make it trivial to use.

=====

For much later, I'm wondering also if extracting the PES parsing code into that
helper library wouldn't be of some use for other plugins/apps. This would
essentially make the mpeg-ts elements simple filters which then use the lib to
make sense of the data... Food for thought.

Comments welcome

-- 
Configure bugmail: http://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.