Add feature support for Common Media Server Data

[wilaw]

The CTA WAVE project is releasing CTA-5006 - Common Media Server Data. This specification is intended to define a standard means by which every media server (intermediate and origin) can communicate data with each media object response and have it received and processed consistently by every intermediary and player, for the purpose of improving the efficiency and performance of distribution and ultimately the quality of experience enjoyed by the users. A draft version of the spec is available at CTA-5006_CMSD-TWG-Review-draft.pdf , the final version will be published by the CTA in December.

Request is for dash.js player to support the following features

1. Have a property setting to enable CMSD. Default can be false
2. If CMSD is enabled, then look for incoming CMSD-Static and CMSD-Dynamic headers. If multiple CMSD-Dynamic headers are present, only ingest the last one defined. If a single CMSD-Dynamic header contains multiple entries (; separated), then only ingest the last entry.
3. Make the CMSD-Static key/value pairs, including custom keys, available via an event, so that application logic can access them.
4. If the 'etp' estimated-throughput value is received on a manifest load, then use that value in the decision on which starting bitrate to select. The value does not need to be sole determinant, but can be combined in a weighted sum with other information that the player may possess about its throughput.
5. If the "mb" Max-suggested-bitrate is present, then use that value as an upper-bound for the ABR algorithm. If the player is playing a bitrate higher than this value, it SHOULD immediately switch to a bitrate lower than or equal to this value. This decision can apply to the video bitrate only for simplification. This restriction should hold until a higher or lower 'mb' value is received, or the end of stream is reached. The application of this throttling limit should be logged.
6. If the "rd" response-delay is present, then subtract that time from the overall segment retrieval time when. estimating throughput.
7. If the "du" duress signal is received from the server, then switch to an alternate BaseURL if one is available and log the behavior.
8. If the "at" availability time attribute is available, then use that value to adjust the request time for segments.

Cheers Will

[bbert]

FYI, a pull request has been initiated to implement support of CMSD specification as described in this issue. See PR #4095

Some first questions araise:

1. Is it required to have a CMSD-Static header along with each CMSD-Dynamic header? In order to know on which object type the CMSD-dynamic parameters apply?
2. If some parameters are missing in a CMSD-Dynamic header, does it mean the previously received values shall be reset, or do they persist until a new value is received or until the end of stream?
3. If a parameter (for example "mb") is provided along with a given object type, does this parameter applies only for the requests corresponding to the object type?

[dsilhavy]

From dash.js call:

1. No static is not required, edge server might remove static header. They can exist independently of each other
2. Depends on the value. 2.1. du: If signaled once it is permanent. 2.2 etp: Applies per segment duration. etp at the moment of the last segment request. Client should evaluate if it should still use older etp. In general only valid for the current segment. 2.3 mb: Applies until another value is received. Cancel by setting high value. 2.4 rd: Only applies to the current request 2.5 rtt: Current request
3. Applies to the entirety of the stream, not only the current object type. For instance, mb applies to audio and video combined.

[dsilhavy]

4095 implemented partial support for CMSD, we leave this issue open until the remaining parameters are implemented. Related is the work in the Common Media Player Library, see https://github.com/streaming-video-technology-alliance/common-media-library/issues/35