Re: MPEG-2 TS Metadata Cue

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, 20 May 2014 22:10:07 UTC