RE: MPEG-2 TS Descriptors

From: Brendan Long [mailto:B.Long@cablelabs.com]
Sent: Friday, May 23, 2014 10:01 AM
To: Clift, Graham; public-inbandtracks@w3.org
Cc: Ota, Takaaki; Wu, Max; Nejat, Mike; Masham, Samuel (CPDG); Day, Saneesh
Subject: RE: MPEG-2 TS Descriptors

Some comments:

Interface TrackDescription {

  attribute octet kind;                   //In MPEG-2 this might be mapped to Stream_Type

  attribute ArrayBuffer    data;          //optional raw data (e.g. as contained in the MPEG-2 TS elementary stream descriptor)

  attribute DOMSTRING      text;          //Optional text version of the data.

}



In DataCue, we're considering removing .text because it's not very useful. Do we expect it to be useful here?

[GAC] Yes that is fine. I included it just because DataCue seemed to need it.



If we're providing the descriptor data as one big binary section, it seems not that much simpler than just providing the entire PMT.

[GAC] The descriptor data is only per elementary stream. If there is likely to be more than one descriptor per elementary stream then we could break it out into an array of descriptors. Do you have an example where this is the case? I don't necessarily see the need to expose all the PMT descriptors that don't have any meaning to the application. This alleviates the need for the media pipeline to track every minuscule change in the PMT, only the ones relevant to creating/removing tracks of interest or adding cues to these tracks.



If we want to just provide descriptors, it seems like it would be better to expose them as a list:

interface Descriptor {

    attribute octet tag;

    attribute ArrayBuffer value;

}



interface TextTrack {

     // existing stuff

    attribute Descriptor[]? descriptors;

}

The PMT can change mid-stream though, so a descriptor cue would also be reasonable (but we should obviously do one or the other, not both):

[GAC] The question I am asking here is why do we care about the PMT changing (just like we don't care about the PAT changing)? Isn't it the changes to the tracks that is important? Also so why does a particular TextTrack need to cue its description if it changes? The list of tracks reflects the current audiotracks, videotracks and texttracks described in the PMT so if anything changes here then we should add and remove tracks as needed. In cases where we want to keep the same TextTrack despite the description having changed, we rely on just firing onchange events to the TextTrackList rather than onAddTrack/onRemoveTrack. This is presumably also the mechanism we rely on for audiotrackLists, videoTrackLists where, for instance, the lang or kind attribute changes.



interface DescriptorCue : TextTrackCue {

    attribute octet tag;

    attribute ArrayBuffer value;

}