Initialization Segments: Inband Tracks

[haudiobe]

John Simmons:

• Clause 4 of the INBANDTRACKS spec contains rules for constructing the ISOBMFF mappings for id, kind, label and language. This section needs to be examined in detail in light of CMAF, and itself may need to be modified.

[haudiobe]

I agree on this. CMAF says

Kind Box ('kind') The KindBox ('kind') may be used to store the role of a CMAF track. The KindBox is stored in the UserDataBox of the TrackBox, as documented in the ISO Base Media File Format (ISO/IEC 14496-12). Any track can be labelled with role information describing the intended purpose of the track. This information can be captured at the time of encoding and later copied to a manifest describing the CMAF tracks in a selection set so that a user or an automatic algorithm can make an appropriate selection. The KindBox can contain one or more tags from a variety of places, including:

• the DASH specification ISO/IEC 23009-1, as identified by the schemeURI "urn:mpeg:dash:role:2011" (without the quotation marks);

• the W3C HTML5 specification of track 'kind', as identified by the schemeURI "about:html-kind". Where multiple schemes define the same concepts, the DASH Role scheme should be used.

• All tracks that are language-specific should identify the language as precisely as possible (e.g. a text track whose language can be written in different scripts should identify which script is used). When the language is not relevant or not known, the 'und' (undetermined) language tag should be used.

[haudiobe]

Details are here for ISO BMFF Byte Stream Format: https://dev.w3.org/html5/html-sourcing-inband-tracks/#mpeg4 Action: Create possibly an Annex to the Byte Stream to improve the sourcing for CMAF. Zach takes a look

[technogeek00]

Assigned to Zack (me)

[haudiobe]

(2020/04/14 CTA WAVE Call) no updates - keep status

[technogeek00]

Drafted an implementation, static document reference, HTML Sourcing In-Band Tracks CMAF.docx, with open comments but I've sent a collaborative edit version to the CTA reflector.

Main open questions:

• Can I get confirmation that track_ID uniqueness holds in CMAF presentations? I assume it is unique per switching set instead of track though given box equality requirements of a switching set.
• HTML tracks define a "metadata" type for text tracks, do we have an equivalent for CMAF tracks or should this be omitted?
• Does CMAF have a better identifier for the language of 608/708 caption service, couldn't find a reference but figured I'd check.
• WRT the KindBox, the CMAF specification specifically calls out multiple boxes being used for semantically equivalent description in a different scheme. However the DASH Role scheme is commonly used with multiple values, in this case is the expectation that there are multiple KindBox boxes with the DASH Role scheme, or a single KindBox with the DASH Role scheme and a specially delineated value? Assuming the former (multi-box) approach but looking for confirmation.

[johnsim]

• Does CMAF have a better identifier for the language of 608/708 caption service, couldn't find a reference but figured I'd check.

The CMAF Specification contains "Annex A.5 CMAF supplemental data", containing Table A.4 - CMAF supplemental data - which identifies a file brand 'ccea' which can be included in addition to a video CMAF media profile brand to indicate the presence of CTA-608 or CTA-708 captions embedded in the video elementary stream.

[haudiobe]

(2020/05/05 Call): Agreed to attach this as an Annex taking into account the comments

[haudiobe]

Remaining comments from Zach:

1. Assuming true, but does track_ID uniqueness hold for CMAF ISOBMFF tracks?
2. Should "metadata" kind remain possible in a CMAF conforming presentation? Answer here will inform lower usage of metadata fallback as well.
3. Carry over from ISOBMFF definition, service language may not match encapsulating track, do we have a better identifier?
4. If "metadata" is not a valid track type for CMAF this clause goes away and this field is always the empty string.
5. Similar to text tracks, can track_ID be consistently used?
6. This is not explicitly called out as a case in the CMAF specification, but this is a correct usage of the DASH role scheme in DASH manifests and would appear to be appropriate in CMAF tracks as well.
7. Linking to ISOBMFF exposure description since it remains the same.

[haudiobe]

Keep the Annex for now, please comment on the details.

@haudiobe action to map this back to the CTA WAVE content format as well, such that the values are part of the content manifest.

Relevant parameters:

• trackID
• handler_type
• kind/Role
• label
• language