Add SVTA's Manifest Composition & Utilization (MC&U) keys: 'omi', 'pmi', 'cmi'

[cksqa]

Define new CMCD keys 'omi', 'pmi', 'cmi'.

The primary purpose is to use 'omi', 'cmi', 'pmi' to generate high-level NOC and Operational visualizations and KPIs showing how a player makes use of the ABR manifest-provided "quality renditions" during a streaming session and across many streaming sessions at scale. The secondary purpose is to enable Engineers to deep dive into streaming session health on a per-chunk basis for a given session to understand how the player is utilizing the obtained ABR manifest's "quality rendition ladder".

SVTA's QoE WG defined, and implemented as part of the SVTA's Distributed Request Tracing POC, several custom CMCD keys:

1. Obtained Manifest Index - 'omi' - CMCD-Object - Number of "quality renditions" present in the last-obtained manifest. This key SHOULD only be sent with an object type of ‘a’, ‘v’ or ‘av’.
2. Playable Manifest Index - 'pmi' - CMCD-Object - Number of "quality renditions" in the last-obtained manifest interpreted as "playable" by the player. This key SHOULD only be sent with an object type of ‘a’, ‘v’ or ‘av’.
3. Current Manifest Index - 'cmi' - CMCD-Object - The "playable quality rendition" chosen by the player for the current chunk request. This key SHOULD only be sent with an object type of ‘a’, ‘v’ or ‘av’.

The resulting visualizations and KPIs are in the process of being published by the SVTA in the upcoming "Request Tracing for Streaming Media Delivery - A Proof of Concept" technical document and will be available for review and discussion at that time.

[ZmGorynych]

The feature is ill defined: e.g. it is rendered useless by multi-codec or multi-key manifests (if you don't have HDCP 1.4, you'll be limited to 540p forever which will in turn affect KPIs for no good reason). I think this feature as defined would both introduce unneeded complexity and be not actionable in multiple cases.

[ZmGorynych]

We can combine the feature with an extra key indicating opaque "audience" -- e.g., an audience may be "people with SW Widevine DRM, H.264 decoder, and a Chrome browser running on mobile Android device".

[cksqa]

Hi @ZmGorynych -

"The feature is ill defined: e.g. it is rendered useless by multi-codec or multi-key manifests (if you don't have HDCP 1.4, you'll be limited to 540p forever which will in turn affect KPIs for no good reason)."

yes, I agree, the feature is not well defined yet. As part of the CMCD v2 definition, I propose that we work to fully define it, including the various use cases, e.g. multi-codec, e.g. multi-key.

For example, for multi-codec, we could handle this by defining that OMI, PMI and CMI values reported for each object request should be done in the context of the specific codec / key chosen by the player associated with the particular object request being made.

[cksqa]

The SVTA has published the SVTA 1055: Request Tracing for Streaming Media Delivery document ( https://www.svta.org/product/svta1055-request-tracing-for-streaming-media-delivery/ ) which makes reference to the PMI and CMI metrics developed as custom CMCD keys as part of the SVTA POC. The document also shows the resulting high-level per-session KPIs (e.g. MUO & MUS KPIs based on collected PMI & CMI metric data) and time-series diagnostic visualizations (an example shown below for a streaming session with poor startup quality, a mid-session quality drop, and the player's inability to go higher than around the middle of the ABR ladder during the enitre session):