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 Monday, 19 May 2014 15:53:13 UTC