- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Fri, 23 May 2014 20:52:31 +0000
- To: "Clift, Graham" <Graham.Clift@am.sony.com>, "public-inbandtracks@w3.org" <public-inbandtracks@w3.org>
- CC: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>, "Wu, Max" <Max.Wu@am.sony.com>, "Masham, Samuel (CPDG)" <SamuelA.Masham@jp.sony.com>
- Message-ID: <CFA50F76.402BE%b.lund@cablelabs.com>
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
Received on Friday, 23 May 2014 20:53:01 UTC