RE: MPEG-2 TS Metadata Cue

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_Metadata
_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, 20 May 2014 21:26:30 UTC