Open mikedo opened 2 years ago
- “Whitespace separated list of 4CC” does not conform to either permitted syntax above. So we need to remove that comment, I think.
Its likely that the definition was copied from @segmentProfiles
and not given full consideration.
The definition as <xs:attribute name="containerProfiles" type="ListOf4CCType"/>
may have similar history.
- The pro-simple syntax, unencodedv, would look like, e.g.: “iso9,cmfc”. OK, good.
We have a definition of simp-list
which could be applied to @containerProfiles
What is the value in using the more complex pro-fancy form, encodedv? Should we remove that form?
Not sure - need input from the proposer
- Per the RFC “.”must be escaped, but also XML forbids & and <. Other symbols have to be escaped as well, such as comma, space, double quote, unprintable, etc. So far, MP4RA Brands only have the space character in use other than alphanumeric. But a DASH client would need to expect and parse for all forms of escaped syntax to work in the future.
Should @containerProfiles
only support MP4RA brands, or allow any values
- How should a DASH packager populate @containerProfiles from ftyp.major_brand and ftyp.compatible_brands[]? The most obvious - major_brand first, then all compatible_brands? Or is it application-defined?
This is probably something for be resolved through a specification issue and not just in the schema repository...
Should @containerProfiles only support MP4RA brands, or allow any values
This was added with CMAF to convey the profiles parameter defined in RFC 6381. In the context of CMAF, @segmentProfiles carries one or more CMAF brands, as described in DASH 8.12.4.3. But the core definition of the syntax not so specific.
This is probably more of a DASH DUI topic than something only for the resultant schema in this repo
5th Ed defines it as:
There are no examples.
The DASH schema types it broadly as xs:string, but has documentation that says “Whitespace separated list of 4CC“.
RFC 6381 says:
Some issues: