RE: MPEG-2 TS Metadata Cue



> -----Original Message-----
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
> Sent: Monday, May 26, 2014 7: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

I think the DataCue direction currently in  http://rawgit.com/w3c/HTMLSourcingInbandTracks/master/index.html#mpeg2ts is preferred to the MPEG-2 TS Cue I proposed.  

> - 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#mp

> eg2ts
> ? What is still missing?

I need to look.

> 
> 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_Met
> >>adat
> >>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:48:34 UTC