2018 Content Spec: AMD 1: Table 5: Single Init per SS should be SHOULD

[johnsim]

(Section 7.2.2) Table 5, “Single Initialization per SS”, undo change of MAY->SHOULD. I reverted it back to MAY because we don’t have consensus.

[poolec]

We shouldn't change this to a SHOULD - Switching Sets may have single init constraints or they may not - if players have to cope with that within a Switching Set they can also cope across sequential switching sets too.

[KilroyHughes]

Agree. At present, this is a statement of permission ("May"). Clarifying that sequential Switching Sets can change "initialization" constraints at a Baseline splice (single init or not). The alternative would be to say sequential Switching Sets SHALL be limited to the same initialization constraints.

We don't say anything about manifests, but different init constraints would require appropriate signaling in a manifest to signal allowed player processing, possibly changing between Header signaling and Fragment signaling (e.g. @bitstreamSwitching="true/false" in DASH MPD).

The term "single initialization" takes on a different meaning when applied to a WAVE Program vs. a Switching Set, where a Master Header provides single initialization of the media pipeline for the entire WAVE Program, but Switching Sets can require Header processing, or not, at each switch or splice (SS "single init constraints").

If a stream with changing parameters is encoded, e.g. a TS broadcast feed containing spliced video with inband parameters and it is VBR encoded with Header parameter signaling, then it needs to be broken into a sequence of Switching Sets (DASH Periods or HLS discontinuities) to force downloading and processing a new Header at each contained splice where inband parameters change. We are determining that by allowing splices with different initialization constraints, but manifest and playback requirements aren't in scope of the content spec and can only be inferred from the specified splice constraints.

Members should consider if additional clarification is necessary. I don't think so.

[poolec]

I think we can safely put it back to MAY and leave it at that.

[johnsim]

I have put it back to MAY. We will confirm consensus in our next call.

[johnsim]

Changed back to MAY. Also, during October 10, 2018 conference call @haudiobe suggested rewording: 'Switching Sets MAY conform to CMAF Single Initialization Constraints to indicate that no CMAF Header needs to be appended on a track switch.'