Closed glenng1215gh closed 11 months ago
The notion of batch reporting came up in the 2023-11-02 meeting that potentially overlaps here.
Additional events that could be captured with these beacons:
What is the relation of this to CTA-2066? There are companies who have been using 2066 definitions and if we introduce new definitions here, would not that cause more confusion/interop issues?
I was unaware of CTA-2066. good work there streaming QOS events and metrics. What I don't see there is a definition of a transmission protocol or format for these events (JSON or XML posts over HTTPS, for example). Now that I see CTA-2066, that should certainly form the basis of a QOS beaconing standard, and should be harmonized with CMCD to use common names and definitions whenever possible. Is any new work ongoing on CTA-2066?
Yup, 2066 did not bother with the transport side of the metrics but then when we defined CMCD, we did not really tie it to 2066, either. Coming from the same organization, these two specs could have been used together in a better way. I think this warrants some discussion in the next call. 2066 was not a product of the WAVE project but it is from R04 WG20 Streaming Media Quality of Experience (QoE). @mlevine84 and @wilaw might say more. Another good read from Akamai is here.
Hi @glenng1215gh , hi @acbegen ,
we also see a huge benefit in extending CMCD to a full beaconing standard, which provides detailed QoS/QoE metrics.
Benefits are:
In order to better understand which metrics are needed for a full picture about the QoS/QoE for each streaming session, we created a table (see below) which includes:
CMCD v1
CTA-2066
CMCD v2
One note about
CTA-2066
: We have the feeling thatCTA-2066
is a good description on how to track metrics of a media session in general, but it does not define a very detailed set of metrics.
Happy to discuss the general approach in our next call!
Value | Type | When to Transmit | CMCD v1 | CTA-2066 | Definition & Further Requirements for CMCD v2 |
---|---|---|---|---|---|
Playback Session definition | behaviour | yes | Definition of playback session | ||
Add-insertion definition | behaviour | yes | Definition of add-insertion | ||
Session Start | event | onEvent | partially (first request) | partially (playbackRequest) | Event when session start is requested; event time in milliseconds; Related issue |
Session End | event | onEvent | partially (playbackFinish) | Event when session is ended; event time in milliseconds; playhead position in milliseconds; additional beaconing request needed, as for VoD no further media segment requests are made | |
Ad Break Start | event | onEvent | partially (adBreakStart) | Event when ad break starts; event time in milliseconds; playhead position in milliseconds | |
Ad Break End | event | onEvent | partially (adBreakEnd) | Event when ad break ends; event time in milliseconds; playhead position in milliseconds | |
PlayState: Connecting | event | onEvent | partially (first request) | Event when playstate Connecting occurs; event time in milliseconds; playhead position in milliseconds; same as session start | |
PlayState: Playing | event | onEvent | partially (playbackStart) | Event when playing playstate occurs; event time in milliseconds; playhead position in milliseconds | |
PlayState: Pause | event | onEvent | partially (playbackPause) | Event when pausing playstate occurs; event time in milliseconds; playhead position in milliseconds; additional beaconing request needed, as long pauses can lead to no further data being loaded and a keep alive is necessary to understand the session is still running | |
PlayState: Buffering/Stall | event | onEvent | partially (bs) | partially (playbackStall) | Event when stalling playstate occurs; exact timing in milliseconds; playhead position in milliseconds |
PlayState: Seek Start | event | onEvent | partially (seekStart) | Event when seeking start playstate occurs; exact timing in milliseconds; playhead position in milliseconds | |
PlayState: Seek End | event | onEvent | partially (seekEnd) | Event when seeking end playstate occurs; exact timing in milliseconds; playhead position in milliseconds | |
PlayState: Warning | event | onEvent | Event when warning playstate occurs; playstate definition; exact timing in milliseconds; playhead position in milliseconds; need to include error type, error message, error description metrics; Related issue | ||
PlayState: Error | event | onEvent | Event when error playstate occurs; playstate definition; exact timing in milliseconds; playhead position in milliseconds; need to include error type, error message, error description metrics; Related issue | ||
PlayState: End | event | onEvent | partially (playbackFinish) | Event when ended playstate occurs; event time in milliseconds; playhead position in milliseconds; additional beaconing request needed, as for VoD no further media segment requests are made | |
CDN Switch | event | onEvent | Event when CDN switch event occurs (first request to new CDN); event time in milliseconds; playhead position in milliseconds; CDN decision: default, error fallback multi-CDN decision (e.g., content steering server response) | ||
User Interaction | event | onEvent | Event when user interaction occurs; user interaction with video player, such as "requested to play", "requested to pause", "requested new video bitrate", "requests captions", etc. | ||
Rendition Update | event | onEvent | partially (renditionUpdate) | Event when rendition update occurs; exact timing in milliseconds; playhead position in milliseconds; rendition width; rendition height | |
Player Resize | event | onEvent | partially (playerResize) | Event when a player resize occurs; exact timing in milliseconds; playhead position in milliseconds | |
Playback Failure | event | onEvent | partially (playbackFail) | Event when a playback failure occurs, indicating that playback failed ultimately; exact timing in milliseconds; playhead position in milliseconds; Related issue | |
Session ID | metric | each request (mandatory) | yes (sid) | As defined in CMCD v1; needs to be mandatory | |
Relative Time since Playback Start | metric | each request (mandatory) | Relative time in milliseconds since session start | ||
Sequential Beacon Number | metric | each request (mandatory) | Human-readable error description. Providing further error information, such as a stack trace, specific platform information, etc. Could be included in Play State Error | ||
Playhead Position | metric | each request (mandatory) | yes | Current playhead position of media player in milliseconds | |
Bitrate | metric | each request (mandatory) | yes (br) | yes (videoReportedBitrate & audioReportedBitrate) | As defined in CMCD v1 |
Session State | metric | each request (mandatory) | Current state of the session, such as "Starting", "Playing", "Paused", "Stopped", "Finished". Could also be derived from playStates | ||
Buffer Length | metric | each request (optional) | yes (bl) | As defined in CMCD v1 | |
Throughput | metric | each request (optional) | yes (mtp) | As defined in CMCD v1 | |
Round Trip Time | metric | each request (optional) | Network round trip time of the last request; duration in milliseconds from request start to first byte for the last segment | ||
Object Type | metric | each request (optional) | yes (ot) | As defined in CMCD v1 | |
Requested Maximum Throughput | metric | each request (optional) | yes (rtp) | As defined in CMCD v1 | |
Streaming Format | metric | each request (optional) | yes (sf) | As defined in CMCD v1 | |
Stream Type | metric | each request (optional) | yes (st) | As defined in CMCD v1 | |
Startup | metric | each request (optional) | yes (su) | As defined in CMCD v1 | |
Top Bitrate | metric | each request (optional) | yes (tb) | As defined in CMCD v1 | |
Playback Rate | metric | each request (optional) | yes (pr) | yes (playbackRate) | As defined in CMCD v1 |
Total Stall Time | metric | each request (optional) | Total amount of stall time in milliseconds since session start | ||
Time to Live Edge | metric | each request (optional) | Definition of delay to server live edge in milliseconds; Only applicable for live streams, especially interesting for low-latency content | ||
Device Type | metric | onEvent: sessionStart, cdnSwitch | Definition of device type, such as "smartphone", "television", "set-top-box", etc. | ||
Device Model | metric | onEvent: sessionStart, cdnSwitch | Definition of model name (if it can be derived from the platform), such as "SM-X710", etc. | ||
Operating System | metric | onEvent: sessionStart, cdnSwitch | Definition of operating system such as "iOS", "Windows", "Android", etc. | ||
Operating System Version | metric | onEvent: sessionStart, cdnSwitch | Definition of operating system version | ||
DRM | metric | onEvent: sessionStart, cdnSwitch | Definition of any kind of DRM information, exact data format TBD | ||
Referrer/App Name | metric | onEvent: sessionStart, cdnSwitch | Definition of Referrer / website or application name | ||
App Version | metric | onEvent: sessionStart, cdnSwitch | Definition of version of website or application | ||
Player Name | metric | onEvent: sessionStart, cdnSwitch | Definition of media player, such as "ExoPlayer", "Shaka", "dash.js", etc. | ||
Player Version | metric | onEvent: sessionStart, cdnSwitch | Definition of media player version number | ||
Content ID | metric | onEvent: sessionStart, cdnSwitch | yes (cid) | yes (contentId) | As defined in CMCD v1 |
Error Message | metric | onEvent: playstate error, playstate warning | Definition of human-readable error message | ||
Error Type | metric | onEvent: playstate error, playstate warning | Definition of error type, such as "network", "media", "player", "delivery", etc. | ||
Error Description | metric | onEvent: playstate error, playstate warning | Definition of human-readable error description | ||
Custom Data | metric | onEvent: next request | Definition of custom data format, e.g., for A/B testing; Related issue; A/B Testing | ||
Captions Enabled | metric | onEvent: next request | Definition if captions are rendered and which ones are being displayed if multiple are available | ||
Mute/Unmute | metric | onEvent: next request | Flag indicating if playback is muted | ||
Picture in Picture | metric | onEvent: next request | Flag indicating if the player is in picture-in-picture mode | ||
Period/Add Information | metric | onEvent: addBreakStart, addBreakEnd | Information about the current period/add which is being played, TBD |
Wow, this is pretty detailed. Maybe, our first step should be to acknowledge whether there is a need for this (or not). Depending on that, reviving/revising 2066 might be one of the next steps.
I completely agree with @acbegen on the need to determine if this expansion of CMCD is the way we want to go. My perception is that there's definitely a lot of enthusiasm for evolving CMCD into a standard with more capabilities for QoE reporting.
However, if we decide to go down this path, I think it's important to think about CMCDv2's scope and ensure it doesn't become overly complex for implementation. We wouldn't want a standard that's so intricate that it ends up not being adopted. Planning for incremental enhancements, adding use cases (more information) in future versions as the industry adopts CMCDv2's new functionalities, could be a good approach.
to minimize overloading CMCD, we could either evolve CTA2066 into a beacon standard (with transmission semantics), or develop a new standard specific only to beacons, leveraging CTA2066 event & metric definitions. either way, CTA2066 and CMCD2 need to be harmonized, using common vocabulary whenever possible.
Notes from meeting 11/30/23
Glenn: QoE used to be a beacon based concept with heartbeats (30 seonds?) where the experience was described. It would be good to have a standard that all could use for this type of use case. Sebastian: +1 for extending CMCD for more QoS/QoE. Looking at CTA-2066, wondering what the overlap is. It doesn't look sufficient. Nicholas: Worried that making CMCDv2 too heavyweight could cost us in adoption. Glenn: CMCDv2 shouldn't be extended to be a beaconing system, but CMCDv2 could be a way to send a common set of information in a standardized QoE "suite". Possibly session based stats should be outside of CMCD which is optimized for request level. Sebastian: Splitting this up into multiple standards and multiple versions will cause a lot of latency before we get valuable QoE data. PJ: +1 to Glenn and Nicholas where we don't want to make this too big. Might go past the original mission of CMCD Will: I was one of the authors of 2066, along with Mux and Conviva. Nobody has used the standard for anything, including Mux developed their own way of computing metrics. CMCD shouldn't dabble in aggregations, but supply metrics/data. CMCD is getting a ton of adoption, and further adoption is paramount. Piers: (also author of 2066) Certain subsets of QoE data can and should be added to CMCD, cited other issues with proposals for specific metrics. If we can get sufficient information for CMCD as-is maybe we don't need to worry about extending it to be a beacon. Chris L: If we do a good job and define all the values, the question of using the JSON format for beaconing is optional and potentially useful. Worried about where the beaconing data is going and potentially re-inventing third party cookies. David H: Greatest value is our adoption, move beaconing to CMCDv3 Ali: Will, what do you think Apple needs in v2? Will: Not sure. Don't even know if they like v1. Paul: We can do a lot with a little, don't need to go as far as aggregations and dashboards but coming up with some pointed and opinionated standards for calculating the most important parts of QoE and be a data provider for exactly that. Also encompassing the failure mode of not having connectivity to the original video provider would be nice. Glenn: Maybe it makes sense to have a fallback if you can't get to the original video provider Alex G: Agree that we can move beaconing into 2066v2, but +1 for quality metrics being in CMCDv2 Piers: See the value in beaconing to reduce reporting load Nicholas L: Might make sense to define some structures Will: hearing a movement towards not defining a beaconing standard, but adding some QoE metrics to CMCDv2 and possibly to allow for the case where the player fails to connect. Would it be useful for CMCD to define a way to report data that is decoupled from a media request? Alex G: +1 to have a way to report that is decoupled from the media requests themselves. Sebastian: +1 to what Paul said earlier, sending essential metrics to understand what is going on. Paul: will Mux or Conviva ever use CMCD as their API? Will: likely no, also we don't want to hold that burden Paul: so we should always have customers looking at their proprietary Mux's and Conviva's, we should define the audience we are targetting, maybe the CDN for decisioning? Will: we should aim to get 90% of the way there, and get the most value out of the least data. Sebastian: +1 to not starting a race with analytics providers, but if we extend in a little way we could get a lot of data. Alex G: Main benefit of CMCD is that it doesn't lock you into a particular solution. Paul: Maybe there is a use case for aggregated QoE across workloads? Will: Edgeio provides global aggregate CMCD data for free
There isn't enough support for full beaconing, there may be support for sending data to external locations that are not the CDN.
As a summary of the decisions reached on this issue:
While CMCD version 1 defines a JSON format for the payload, it does not fully address the use case where the primary goal is to report player-side QOE data out-of-band to an analytics service, one that is typically independent from any of the CDNs. In this use case, player QOE data tends to be session and time-interval based as opposed to based around individual media segment requests.
With a few additions, CMCD can essentially also become a player QOE beaconing standard. A beacon would be defined as a set event-oriented beacon types, with each beacon type containing a set of CMCD keys. A proposed set of beacon types could like something like this:
playback-start Issued at play start with all of the CMCD-Session keys and selected CMCD-Object keys such as Top bitrate (tb)
playback-end Issued at play end with the CMCD sessionID (sid) key
playback-error Issued whenever the player encounters a playback error. payload would carry an error identifier & data (TBD)
playback-stall Issued whenever the player encounters a buffer stall. contains CMCD keys such as br,mtp,ot,pr,rtp. It would also be useful to capture duration of the stall, either on this event (posted when the stall ends), or with an additional playback-resume event.
playback-heartbeat Issued on a time interval defined either by the player or the analytics service that is is reporting, with a typical interval around 30 seconds. Metrics such as bitrate, throughput, and buffer length would represent the averages over the reporting time interval. Contains CMCD keys such as br,bl,mtp,ot,pr,rtp
Some may argue that this is beyond the scope of CMCD, but it could bring value to the overall ecosystem. For example, the existence of a QOE beaconing standard could eliminate the need for QOE vendor-specific player plugins, with players and QOE analytics backends all understanding the same beacon specification.