Feature/cmcd settings from mpd and steering report

[matiasrb97]

This PR aims to add two features related to CMCD.

First one is CMCD session initialization and configuration through the MPD as specified in the DASH 6th draft version standard.
Second one is the ability to send CMCD data to the Content Steering server.

Summary of changes:

• Parse the new ClientDataReporting and CMCDParameters settings from mpd file following the DASH specification.
• Implement the functionality to use the new parsed settings: serviceLocations , adaptationSets , includeInRequests filters, mode , version , keys , and other configurations for CMCD specified in the DASH 6th draft version standard.
• Implemented _getCmcdDataForSteering for sending CMCD data to content steering server.
• Implemented a set of logs when required settings are not configured in the MPD for CMCD, or when the settings have wrong values. e.g: <CMCDParameters version='1' mode='query' keys='foo bar'> in this example foo bar are not valid values.
• Created tests for both new features.

Note:
If applyParametersFromMpd is true, the player will use the CMCD settings from the MPD if specified, ignoring whatever the player's own settings for CMCD .
If applyParametersFromMpd is false, the player won't use the CMCD settings from the MPD ignoring whatever the MPD has set for CMCD.

This feature can be tested using this simple testing tool: https://github.com/qualabs/cmcd-content-steering-test-runner.
It has a set of use cases which we used for developing and testing the features implemented in this work.

List of use cases tested:
Case 1: Basic MPD Configuration. - It has a simple configuration of CMCD.
Case 2: Basic MPD Configuration with Service Locations filter.
Case 3: Enable CMCD From JS Code. - If "CMCD from JS" checkbox is false, CMCD will not be sent.
Case 4: Multiple ServiceDescription elements. - It will use the latest ServiceDescription element.
Case 5: Multiperiod MPD with ServiceDescription. - We kept this case out of scope in this work, it implies other changes not related to just cmcd.
Case 6: Setting serviceLocations & includeInRequest filters.
Case 7: Setting includeInRequests only filter.
Case 8: Setting serviceLocations & includeInRequests filters.
Case 9: includeInRequest default value.
Case 10: Keys are not defined.
Case 11: Keys parameter has some invalid key.
Case 12: Keys are defined but all the keys are not implemented.
Case 13: includeInRequests is defined but has some invalid request type.
Case 14: includeInRequests are defined but all the request types are not implemented.
Case 15: Sending CMCD data to the steering server from the last video request.
Case 16: Sending CMCD data to the steering server from the last audio request if MPD has only audio tracks.

In each case you should be able to see the CMCD sent in each request and in the bottom the MPD manifest used in the selected use case.

[dsilhavy]

@matiasrb97 Thank you very much for your work on this. I added some review comments and some additional comments and questions below. I am discussing them with the authors on Slack but posting here as well:

• Checking that with the authors of the spec: ReportingSystem has type DescriptorType . Does that imply that CMCDParameters as defined in TableK.4.2.7.2-1 needs to have a schemeIdUri as well (urn:mpeg:dash:cta-5004:2023)? We are currently not checking for this schemeId: urn:mpeg:dash:cta-5004:2023
• Are we checking for multiple ReportingSystem (CMCDParameters) elements in ClientDataReporting
• TableK.4.2.7.2-1 says "Semantics of CMCD Reporting element" while the element itself is named "CMCDParameters"
• ClientDataReportingType can have a sequence/multiple ReportingSystem elements. According to Table K.4.2.7.1-1 only one CMCDParameters element is possible. Is that correct?
• For CMCDParameterType : According to Table K.4.2.7.2-1 version is mandatory which does not seem to be reflected in the schema definition: <xs:attribute name="version" type="xs:unsignedInt"/> . Do we need to add use="required"
• The default value for includeInRequests seems to differ :
  • TableK.4.2.7.2-1: segments
  • Schema: <xs:attribute name="includeInRequests" type="xs:string" default="*"/>
• <xs:attribute name="keys" type="StringNoWhitespaceVectorType"/> is mandatory according to TableK.4.2.7.2-1

[dsilhavy]

Some things I forgot:

• It would be nice to have a sample page similar to this one for CMCD triggered via the MPD: https://reference.dashif.org/dash.js/nightly/samples/advanced/cmcd.html
• Can you share a publicly hosted MPD (maybe one of these https://github.com/qualabs/cmcd-content-steering-test-runner/tree/main/dash-cases/cases) that we include in the reference UI? I will also use this to implement a functional test then.

[ZmGorynych]

@matiasrb97 Thank you very much for your work on this. I added some review comments and some additional comments and questions below. I am discussing them with the authors on Slack but posting here as well:

• Checking that with the authors of the spec: ReportingSystem has type DescriptorType . Does that imply that CMCDParameters as defined in TableK.4.2.7.2-1 needs to have a schemeIdUri as well (urn:mpeg:dash:cta-5004:2023)? We are currently not checking for this schemeId: urn:mpeg:dash:cta-5004:2023

Yes.

• Are we checking for multiple ReportingSystem (CMCDParameters) elements in ClientDataReporting
• TableK.4.2.7.2-1 says "Semantics of CMCD Reporting element" while the element itself is named "CMCDParameters"
• ClientDataReportingType can have a sequence/multiple ReportingSystem elements. According to Table K.4.2.7.1-1 only one CMCDParameters element is possible. Is that correct?

Multiple should be allowed. You can report different keys to different endpoints. Imagine only sending cid and sid to content steering server to let the backend correlate with what it sees from the logs.

• For CMCDParameterType : According to Table K.4.2.7.2-1 version is mandatory which does not seem to be reflected in the schema definition: <xs:attribute name="version" type="xs:unsignedInt"/> . Do we need to add use="required"

Yes.

• The default value for includeInRequests seems to differ :

  • TableK.4.2.7.2-1: segments
  • Schema: <xs:attribute name="includeInRequests" type="xs:string" default="*"/>

• <xs:attribute name="keys" type="StringNoWhitespaceVectorType"/> is mandatory according to TableK.4.2.7.2-1

<xs:attribute name="includeInRequests" type="xs:string" default="*"/> for CMCD is madness, it should be segments

[dsilhavy]

Please address this

[dsilhavy]

@matiasrb97 Thank you for addressing most of my comments. I did another quick review, please see the comments above. One additional item based on the feedback by @ZmGorynych : Can we add a check for the urn:mpeg:dash:cta-5004:2023 scheme id before creating an instance of CMCDParameters.

[matiasrb97]

@matiasrb97 Thank you for addressing most of my comments. I did another quick review, please see the comments above. One additional item based on the feedback by @ZmGorynych : Can we add a check for the urn:mpeg:dash:cta-5004:2023 scheme id before creating an instance of CMCDParameters.

@dsilhavy Thanks again for your comments! I think that now I finished addressing all your comments at the moment. Please check and maybe we can resolve all the comments that are closed now (and keep the ones that need something else).

Regarding the schemeId, can you please check if I understood well ? I did the change in this single commit so it's easy to revert if I missunderstood.

Edit:
I'm working on these two bullets now:

• It would be nice to have a sample page similar to this one for CMCD triggered via the MPD: https://reference.dashif.org/dash.js/nightly/samples/advanced/cmcd.html

• Can you share a publicly hosted MPD (maybe one of these https://github.com/qualabs/cmcd-content-steering-test-runner/tree/main/dash-cases/cases) that we include in the reference UI? I will also use this to implement a functional test then.

[dsilhavy]

@matiasrb97 This looks all good to me. Is there anything left from your side? If not, can you please merge the changes from development one more time then I can merge your PR.

[matiasrb97]

@matiasrb97 This looks all good to me. Is there anything left from your side? If not, can you please merge the changes from development one more time then I can merge your PR.

Great, thanks! Nothing else from my side, I updated this branch with the latest from development.

And regarding the hosted mpd that you asked for, here I have two links with two mpd samples that are used in the testing repository:

• https://d23x4gyjtx25iu.cloudfront.net/1.mpd
• https://d23x4gyjtx25iu.cloudfront.net/8.mpd