RE: MPEG-2 TS Metadata Cue

Exposing all of the sections as DataCues is the easiest solution (on the UA side, and there's a library for handling it on the JS side: https://github.com/cablelabs/mpegtssections-js).

For the PMT and Track Description, we could just have a "DescriptorCue" instead, since that seems to be all we need:

enum Scope {
    TRACK,
    PROGRAM,
    TRANSPORT_STREAM
}

interface DescriptorCue : TextTrackCue {
    octet tag;
    ArrayBuffer value; // the contents of the descriptor, excluding the tag and the length
    Scope scope;
}

I'm not sure how we could expose private sections besides DataCue. I know we need the data in them, but I'm not sure if any of the header-like data is important.
________________________________________
From: Silvia Pfeiffer [silviapfeiffer1@gmail.com]
Sent: Monday, May 26, 2014 8:23 AM
To: Bob Lund
Cc: Brendan Long; public-inbandtracks@w3.org; Mark Vickers @ Comcast; Giuseppe Pascale; Glenn Adams
Subject: Re: MPEG-2 TS Metadata Cue

I'll be frank: I don't much like the structures at
https://www.w3.org/community/inbandtracks/wiki/Main_Page#MPEG-2_TS_Metadata_Cue
- there are far too many new objects, their content seems too
low-level to be relevant for a Web app and there are subtypes of
subtypes of TextTrackCue. I don't think it has to be this complicated.
I maintain that we should be able to resolve everything with DataCue
objects or with something akin to a JSONCue, and then with file-wide
metadata (a la https://www.w3.org/Bugs/Public/show_bug.cgi?id=5755
which we're not ready to resolve yet).

Bob, could you rework that proposal with the recent thoughts on
DataCue that went into
http://rawgit.com/w3c/HTMLSourcingInbandTracks/master/index.html#mpeg2ts
? What is still missing?

Thanks,
Silvia.


On Wed, May 21, 2014 at 8:08 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
> I think so. The only other program level metadata is the program number,
> which has little use in a single program transport stream and no use to a
> Web app.
>
> On 5/20/14, 3:25 PM, "Brendan Long" <B.Long@cablelabs.com> wrote:
>
>>This was in response to Silvia's question:
>>
>>> 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?
>>
>>It seems like all we really care about are the descriptors and the
>>private section data, right?
>>
>>________________________________________
>>From: Bob Lund
>>Sent: Tuesday, May 20, 2014 4:23 PM
>>To: Brendan Long; Silvia Pfeiffer
>>Cc: public-inbandtracks@w3.org; Mark Vickers @ Comcast; Giuseppe Pascale;
>>Glenn Adams
>>Subject: Re: MPEG-2 TS Metadata Cue
>>
>>On 5/20/14, 3:12 PM, "Brendan Long" <B.Long@cablelabs.com> wrote:
>>
>>>Oh, the other kind of data we'll need is the content of private data
>>>sections.
>>
>>That interface is already defined in [3]:
>>
>>interface MpegTsPrivateSection : MpegTsSection { //Private section (see
>>Table 2-30)
>>
>>identified by tableId of 0x40 - 0xFE.
>>
>>[3]
>>https://www.w3.org/community/inbandtracks/wiki/Main_Page#MPEG-2_TS_Metadat
>>a
>>_Cue
>>
>>>
>>>As far as I know, the only useful information is the table_id and the
>>>binary data. Would we want to include anything else?
>>>________________________________________
>>>From: Bob Lund
>>>Sent: Monday, May 19, 2014 10:51 AM
>>>To: Brendan Long; Silvia Pfeiffer
>>>Cc: public-inbandtracks@w3.org; Mark Vickers @ Comcast; Giuseppe Pascale;
>>>Glenn Adams
>>>Subject: Re: MPEG-2 TS Metadata Cue
>>>
>>>On 5/19/14, 9:36 AM, "Brendan Long" <B.Long@cablelabs.com> wrote:
>>>
>>>>Individual descriptor cues would make sense if we don't need anything
>>>>else in the PMT.
>>>
>>>I do not know of a use case that uses the other program level fields.
>>>
>>>> They're conveniently name-value pairs, so whatever works for ID3 will
>>>>probably work for MPEG-TS descriptors.
>>>>
>>>>We would probably want some way to differentiate between program-level
>>>>descriptors and track-level descriptors (and the transport-stream-level
>>>>descriptors in the "Transport Stream Description Table").
>>>
>>>The tableId in [1] would differentiate. In fact, tableId == 0x03
>>>“Transport stream description table” [2] could be reused.
>>>
>>>[1] http://www.atsc.org/cms/standards/A65_2013.pdf
>>>[2] ISO/IEC 13818-1 Table 2-30-1
>>>
>>>>
>>>>________________________________________
>>>>From: Bob Lund
>>>>Sent: Monday, May 19, 2014 10:12 AM
>>>>To: Silvia Pfeiffer; Brendan Long
>>>>Cc: public-inbandtracks@w3.org; Mark Vickers @ Comcast; Giuseppe
>>>>Pascale;
>>>>Glenn Adams
>>>>Subject: Re: MPEG-2 TS Metadata Cue
>>>>
>>>>On 5/18/14, 11:47 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
>>>>wrote:
>>>>
>>>>>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.
>>>>
>>>>The PMT can change over time because a) elementary streams are added or
>>>>removed or b)program level descriptors (content_advisory_descriptor [1])
>>>>changes. Case Œaı above will be handled by track add/remove events. Case
>>>>Œbı could be handled by on exposing the PMT program level descriptor
>>>>array, if it changes.
>>>>
>>>>This alternative would be OK by me. I know Brendan felt exposing the PMT
>>>>as metadata would have some advantages but he can weigh in if he wants
>>>>to.
>>>>
>>>>>It's a DataCue, not a MetadataCue. The information of a PMT should
>>>>>already be available from the HTMLMediaElement and its attributes.
>>>>
>>>>No the program level stuff [2] (see below). So, at least the
>>>>descriptor()
>>>>list needs to be exposed.
>>>>
>>>>table_id
>>>>section_syntax_indicator
>>>>reserved
>>>>section_length
>>>>program_number
>>>>reserved
>>>>version_number
>>>>current_next_indicator
>>>>section_number
>>>>last_section_number
>>>>reserved
>>>>PCR_PID
>>>>reserved
>>>>program_info_length 12 uimsbf
>>>>for (i = 0; i < N; i++) {
>>>>   descriptor()
>>>>}
>>>>
>>>>
>>>>> 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.
>>>>
>>>>Any program level descriptor, e.g. content_advisory_descriptor [1].
>>>>
>>>>>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 ?
>>>>
>>>>We actually discussed this and I know Graham Clift @ Sony was in favor
>>>>of
>>>>this approach. However, the challenge with MPEG-2 TS is that there are a
>>>>lot of descriptor types and content providers can describe their own.
>>>>So,
>>>>in some cases, the JSON name/value wonıt be very descriptive, e.g.
>>>>descriptor id = some_arbitrary_number, value =
>>>>binary_data_of_unknown_format.
>>>>
>>>>Iım not opposed to a JSONCue.
>>>>
>>>>>
>>>>>3. Is there any other use case that I missed?
>>>>
>>>>Nope.
>>>>
>>>>Bob
>>>>
>>>>[1] http://www.atsc.org/cms/standards/A65_2013.pdf section 6.9.3
>>>>[2] ISO/IEC 13818-1 Table 2-28
>>>>
>>>>>
>>>>>Thanks,
>>>>>Silvia.
>>>>
>>>
>>
>

Received on Tuesday, 27 May 2014 13:35:14 UTC