RE: MPEG-2 TS Metadata Cue

Individual descriptor cues would make sense if we don't need anything else in the PMT. 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").

________________________________________
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:38:29 UTC