Closed poolec closed 3 years ago
@poolec You are right the mixture of type 1 and type 3 description makes this description muddy. I like the idea of stating the restriction of the description to type 3 players and simplifying the A.3 to your descriptive note:
Track ordering does not apply when MSE is used and a single CMAF switching set of a particular media type is chosen by the application.
Description around Type 3 players will also solve #24
Updated A.3 to note that track ordering does not apply.
Call 2020/11/19: Agreed. We update A.3 as follows
Track ordering does not apply to this sourcing profile as CMAF is provided to the user agent via MSE and only a single CMAF switching set of a particular media type is chosen by the application.
The inband tracks part of the CMAF byte stream doc includes section A.3 on Track Order:
As written this would seem to apply only where the browser directly supports DASH or HLS (a so-called "type 1" player), rather than when using MSE since it's only in that case that the browser sees any manifest. With MSE, there aren't generally multiple tracks known to the user-agent. It is only likely to see a single CMAF Switching Set at a time, which can only contribute a single Track.
I don't think this specification needs to cover "type 1" players - there is already a DASH section in the inband tracks spec which tells you how to populate track metadata from a DASH MPD. Having a CMAF mapping that applies in that case too would lead to conflict and confusion.
I'd propose replacing the text here with the following:
Or perhaps the entire CMAF inband tracks mapping should be restricted more explicitly to the MSE case?