Re: MPEG-2 TS Descriptors

From: <Clift>, Graham <Graham.Clift@am.sony.com<mailto:Graham.Clift@am.sony.com>>
Date: Friday, May 23, 2014 at 3:13 PM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: "Masham, Samuel (CPDG)" <SamuelA.Masham@jp.sony.com<mailto:SamuelA.Masham@jp.sony.com>>, "Ota, Takaaki" <Takaaki.Ota@am.sony.com<mailto:Takaaki.Ota@am.sony.com>>, "Wu, Max" <Max.Wu@am.sony.com<mailto:Max.Wu@am.sony.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: Re: MPEG-2 TS Descriptors


I see your point about changing program map descriptors but how are you thinking that these get exposed as datacues? As one blob of data that includes the section length etc or separate cues per descriptor?

One section table per Cue (this would contain all the descriptors in the case of the Transport description section). This makes DataCue operation consistent across all ES's that carry metadata.


Graham

On May 23, 2014 1:52 PM, Bob Lund <B.Lund@CableLabs.com<mailto:B.Lund@CableLabs.com>> wrote:


From: <Clift>, Graham <Graham.Clift@am.sony.com<mailto:Graham.Clift@am.sony.com>>
Date: Friday, May 23, 2014 at 2:18 PM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Cc: "Ota, Takaaki" <Takaaki.Ota@am.sony.com<mailto:Takaaki.Ota@am.sony.com>>, "Wu, Max" <Max.Wu@am.sony.com<mailto:Max.Wu@am.sony.com>>, "Masham, Samuel (CPDG)" <SamuelA.Masham@jp.sony.com<mailto:SamuelA.Masham@jp.sony.com>>
Subject: RE: MPEG-2 TS Descriptors




Sorry if I wasn’t clear. This ES section data only contains program level descriptors, not any of the other PMT data that I agree we don’t need. Here’s the Transport Description Table definition taken from 13818-1:

TS_description_section() {
table_id 8 uimsbf
section_syntax_indicator 1 bslbf
'0' 1 bslbf
reserved 2 bslbf
section_length 12 uimsbf
reserved 18 bslbf
version_number 5 uimsbf
current_next_indicator 1 bslbf
section_number 8 uimsbf
last_section_number 8 uimsbf
for (i = 0; i < N; i++) {
descriptor()
}
CRC_32
}

[<GAC>] If we are only interested in exposing the descriptors from the program level and we have the attribute inBandMetadataDispatchType which already is described with language about carrying descriptors (albeit described  for elementary streams currently)

But that’s a significant point. inBand…Type is meant to convey metadata about what is in the associated text track. The program descriptors don’t do that – they convey program level info. The ES descriptors don’t change. The program descriptors can change. So that’s two significant. IMO, differences with how the current semantics of the inBand…Type.

 then doesn’t this reinforce the argument not to use cues but just create one textTrack per descriptor, updating the list with the relevant PMT changes. It may be the path of least resistance IMHO.

I guess I see it the other way. DataCue is a general mechanism for exposing section data in ES that is expected to change over time. This is exactly what is needed for the Transport Description Sections. Nothing else needs to be done.





Graham