Add key to allow CMCD transmission to be modified in the player

[wilaw]

[Feedback from CMCD meeting with respect to https://github.com/cta-wave/common-media-client-data/issues/82]

There could be a CMSD key which activated/deactivated CMCD transmission by the player.

The CMSD key should have sufficient flexibility to dictate a whitelist/blacklist of CMCD keys to be sent.

There was some opinion that the two specifications should not be linked, other opinions that there was merit in defining synergistic behaviors between the two CTA specifications

[nicoweilelemental]

That sounds like a mission for the origin CMSD.

How would the player CMCD activation/deactivation instructions would look like? It would likely be good to have a default true/false that applies to all player platforms, plus a list of true/false exceptions that applies to specific player platforms.

The list of CMCD keys to include/exclude seems very straightforward to specify.

Extending the discussion to the 3rd party beaconing use case (CMCD-117), I would suggest to extend the CMSD signaling to include the 3rd party beaconing URL and the beaconing interval (for example in the CMSD headers present on manifest responses). That would prevent to include this information in the manifests themselves, and would provide more flexibility for evolution than if we try to sync the HLS and DASH specs onto the CMCD needs.

[nicolaslevy]

I think that this is outside the scope of this spec (CMCD) and could be defined in CMSD if there is interest. Similar to what DASH did with "CMCDParameters" (see example image below).

Note that players will have to specify some way of preference to know what to use: JavaScript configuration of CMCD, MPD configuration of CMCD, or CMSD configuration of CMCD?