CMCD
Main.CMCD History
Hide minor edits - Show changes to output
Added lines 1-39:
Chair: Will Law
Note taker: JP Saibene
CMCD v1:
*CTA Wave Spec
*Players to communicate mutually useful info: view into the player state & health
*Monitoring & observability
*Pre-integrated in all players: Shaka, Roku, HLS.js, DASH.js, Bitmovin, etc.
*Exoplayer now supports all 16 parameters
*CMCD v2: Powerful monitoring solution
Goals of V2:
*Tighten ambiguities of v1 after 2 years of deployment
*Increase utility / functionality as a monitoring tool (QoE)
*Apple meeting on Friday: they want to implement CMCD, not sure if they will implement v1 or v2
*Worried about the number of properties being sent. Warning for v2. Possible solution: default set and an API to add more VS once on, everything is there (apple classic approach)
*Session handling: how can we track session information without compromising identification.
*Session ID (persistent) + Content ID (per ad / content)
CTA Wave: produce a clear spec
SVTA: produce “how to use” guidelines
Challenges v2:
*BS: very ambiguous. Flag + duration. Make it stateless or stateful?
*Decoupled reporting:
**If you report decoupled, it’s not attached to an object
**Is this too much of a QoE product?
Modes of operation:
*QoE vs CDN Optimization
*V1: nor has only one object pre-fetch Not absolute: avoid attacks Could we ask for more than 1 object?
Ideas:
*HLS / DASH playlist or manifest, send reporting information (comes from the origin / content distributor).
*Content steering already has a mechanism to establish who is the decision maker. There’s some correlation.
*Should we have a mode to encrypt this? downside: CDN doesn’t have access to the info
*Add AI to pre-fetch info :-P
Primary call to action:
*@Will to open issue for HEAD request for reporting data instead of HTTP POST
*V2 is being discussed right now. Will to send the list of discussions to this group to enhance discussion.
Note taker: JP Saibene
CMCD v1:
*CTA Wave Spec
*Players to communicate mutually useful info: view into the player state & health
*Monitoring & observability
*Pre-integrated in all players: Shaka, Roku, HLS.js, DASH.js, Bitmovin, etc.
*Exoplayer now supports all 16 parameters
*CMCD v2: Powerful monitoring solution
Goals of V2:
*Tighten ambiguities of v1 after 2 years of deployment
*Increase utility / functionality as a monitoring tool (QoE)
*Apple meeting on Friday: they want to implement CMCD, not sure if they will implement v1 or v2
*Worried about the number of properties being sent. Warning for v2. Possible solution: default set and an API to add more VS once on, everything is there (apple classic approach)
*Session handling: how can we track session information without compromising identification.
*Session ID (persistent) + Content ID (per ad / content)
CTA Wave: produce a clear spec
SVTA: produce “how to use” guidelines
Challenges v2:
*BS: very ambiguous. Flag + duration. Make it stateless or stateful?
*Decoupled reporting:
**If you report decoupled, it’s not attached to an object
**Is this too much of a QoE product?
Modes of operation:
*QoE vs CDN Optimization
*V1: nor has only one object pre-fetch Not absolute: avoid attacks Could we ask for more than 1 object?
Ideas:
*HLS / DASH playlist or manifest, send reporting information (comes from the origin / content distributor).
*Content steering already has a mechanism to establish who is the decision maker. There’s some correlation.
*Should we have a mode to encrypt this? downside: CDN doesn’t have access to the info
*Add AI to pre-fetch info :-P
Primary call to action:
*@Will to open issue for HEAD request for reporting data instead of HTTP POST
*V2 is being discussed right now. Will to send the list of discussions to this group to enhance discussion.