Re: MPEG-2 TS Metadata Cue

On Tue, Apr 29, 2014 at 8:00 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
> Hi All,
>
> Given the direction of the discussion around DataCue, I put together a
> proposal for an MPEG-2 TS specific metadata cue interface. I’m no WebIDL
> expert (or even novice) so comments/suggestions are welcome.
>
> The approach is fairly straightforward. There are three types of metadata
> script can use: program map table, transport stream descriptors and private
> sections. All of these are tables that have a common set of attributes,
> including tableId, and table specific attributes. tableId is used to
> determine the type of table. So, the Cue exposes the tableId and the rest of
> the table data. The tableId is used to determine the format of the rest of
> the table data.


IIUC the Program Map Table is a data structure that describes the
composition of the full stream, i.e. its elementary streams. It is
therefore not timed data (as in: there are chuncks of data coming up
frequently during a program) and therefore exposing it in a TextTrack
in DataCue objects to JS is not appropriate.
It's a DataCue, not a MetadataCue. The information of a PMT should
already be available from the HTMLMediaElement and its attributes. I
wouldn't advocate exposing Ogg Skeleton to HTML either.

I am trying to understand what use cases you are trying to get to and
what (semantic) information you are trying to expose.
Exposing the structure of the headers of a MPEG file simply doesn't
seem useful .
What semantic information is contained in a MPEG transport stream
program map table that you need access to from JS?

I'll make some guesses:

1. I can see a need for name-value metadata information. Is that what
you're after?
This would be part of an orthogonal discussion to DataCue.
In fact, it's part of the discussion where we don't expose in-band
metadata for any file format to JavaScript, see for example that we
also don't expose EXIF metadata on images.

However, there is always
https://www.w3.org/Bugs/Public/show_bug.cgi?id=5755 (just like there
is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23511).


2. Then there is always timed metadata, i.e. the name-value pairs, but
changing over time
I assume it is possible to have something like that, e.g. to signal
hooks for advertisements, or changing information about copyright or
content advisory.
I think such fields could always be represented as JSON, so maybe we
should start defining a JSONCue ?

3. Is there any other use case that I missed?

Thanks,
Silvia.

Received on Monday, 19 May 2014 05:48:25 UTC