language priority between manifest and isobmff

jpiesing commented 3 years ago

The byte stream format spec says;

language .. ● Otherwise, the content of the language field in the MediaHeaderBox

For DASH, what about AdaptationSet@lang? This requirement automatically gives precedence to the ISOBMFF layer which is not the most obvious solution.

technogeek00 commented 3 years ago

It's a good question since the MPEG-DASH mapping within the unofficial draft does explicitly call out the usage of the ContentComponent or AdaptationSet element language. The text in the byte stream format is written with the same assumptions as CMAF that there is a manifest for carriage but it is out of scope of this particular binding. Instead we focused solely on the data within the byte stream that the user agent would have access to for sourcing the information. This is parallel to how the ISOBMFF mapping provides a language reference even though ISOBMFF is the current reference for the DASH mapping.

But to the point of the concern here, I would go out on a limb and suggest that the information within the CMAF byte stream and manifests should always be equal anyways. Otherwise the byte stream is not conformant to CMAF or the manifest is not conforming to its format's CMAF binding profile. However, I don't know how assumptive I'm being with this statement.

haudiobe commented 3 years ago

AHG 2020/10/19:

We add a reference to the DASH profile for CMAF content that basically mandates the alignment of the manifest and the CMAF header.
This statement may apply not only for this specific issue, but also for other parameters.
User Agent can not overwrite, so sourcing is done through CMAF header.

Needs implementation: @haudiobe will propose something and include @technogeek00, @poolec and @jpiesing

haudiobe commented 3 years ago

Implemented: https://1drv.ms/w/s!AiNJEPgowJnWgqsz3EFQvnMD7BhN0w?e=42BwJJ

cta-wave / CMAF-Byte-Stream

language priority between manifest and isobmff #19