[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 #8 from Edward Hervey <bilboed at gmail.com> 2013-06-20 17:22:59 UTC ---
(In reply to comment #7)
> Maybe even in this case?
> 
> There are two things here I guess:
> 
> a) how to make the data available
> b) how applications would use/parse the data
> 
> For a) we want to avoid inefficient GValue usage at a large scale - options are
> exposing structs in some way, or perhaps even GVariant, or just exposing the
> data unparsed?
> 
> For b) the question is would applications want to use structs, or maybe it
> would be easier/better to provide helper functions to get/parse the info out
> instead and expose the data in a more raw/rough form?

So it's essentially the question of : how much do we pre-parse.

0) No parsing at all, we just provide a gchar *data and let the app deal with
it
1) Only do generic SI parsing (i.e. what is common to all SI)
2) Do table_type (i.e. PAT, PMT, NIT, ...) specific parsing of the fields only
(and do not touch the descriptors)
3) Do full and extensive parsing of everything, including descriptors

I think we can find a right balance somewhere between 2) and 3) so that we keep
the cpu usage at a reasonably low-level in the element, yet do not impose too
much work on the application.

The non-descriptor fields are straightforward and trivial to parse, so it's not
a big burden.

As for the descriptors, which ones do we decide to parse and expose explicitly
in the structure ?

I'd say there are two ways to go forward for this:
1) descriptors that are needed anyway for proper tsparse/tsdemux usage should
be extracted explicitly.
2) descriptors which are *expected* to be present for a certain SI type should
also be extracted explicitly.

So that would boil down ... to the descriptors we are already parsing in
mpegtspacketizer.c. The logic is also there and I would prefer not to lose it.

That still leaves plenty of descriptors we don't parse (because they are not
essential to core usage or core expectations) and they would still be available
for the application to parse.

The one descriptor I might be keen on moving away... are the various string
ones (due to overhead of GIConv). But it doesn't cost a lot to leave them right
now (we would already gain a massive amount of overhead by no longer using
structure/gvalue/...) , and would allow existing apps to trivially switch (and
would be available via g-i).

that being said ... I still don't see the point about GVariant (tbh, I'm a bit
clueless about it, but I fear using anything glib-originated in hotspots). I
welcome an explanation though :)

-- 
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.