Closed pankaj-giter closed 1 year ago
** CMSD Use Cases - Player and CDN
Providing player with source of error For any 4xx, 5xx received by player, it is helpful to know the source of this error code such that player can take appropriate action, such as, either switch CDN or switch bitrate.
Providing player with latency info To assess the source of highest latency and have a view of latency breakdown, it is helpful to know if the latency is between player <-> CDN, CDN <-> Mid-tier, Mid-Tier <-> Origin. This info can be used by player to switch CDNs or bitrates.
Source of Response Bytes (cache-hit/miss/etc.)
Discussion at 6/7 meeting - consensus around adding an informative appendix to the spec documenting the use-cases.
etp/mb/Transport-info metrics can be useful for:
Some potential use cases angles been thinking about:
Auto slating on errors, if network can’t keep up with a live feed upstream it might compensate with temporary slate segments or bit stuffing a lower quality stream at same profile and later self recover rather than say stop the stream
Censored/profanity filtering - you might have reason to have proxy nodes physically in a certain geolocation, that location might have reason to restrict parts of the content
Dynamic pricing - multiple CDNs could spot price against each other over the duration of an event depending on actual demand vs revenue target for a local edge demographic
Piracy fingerprinting, identifying a pirate streamer by deductions from contents of CMSD metadata vs known video, audio variants provided by each edge node at a given time
Supply and demand - player can choose quality based on a budget - one CDN path might be cheaper than another (note that ‘cheapest’ option isn’t necessarily what consumers are asking for) CMSD adjusts to demand or possibly selects r outs that injects more or removes ads or lowers or increases quality/resolution offerings
Auto slating on errors, if network can’t keep up with a live feed upstream it might compensate with temporary slate segments or bit stuffing a lower quality stream at same profile and later self recover rather than say stop the stream
The new DASH edition has this concept of slate segments (if the packager has loss on the input, it can generate them instead). Is this something we should expect the CDN servers to do? I doubt it. Also stuffing bits from the lower quality bitstream means that the server actually knows a lot of things about the segments (pretty much all the stuff in the MPD).
Censored/profanity filtering - you might have reason to have proxy nodes physically in a certain geolocation, that location might have reason to restrict parts of the content
How do you suggest the server knows about these parts?
Piracy fingerprinting, identifying a pirate streamer by deductions from contents of CMSD metadata vs known video, audio variants provided by each edge node at a given time
CMSD is optional to implement and to use. How can it be used for fingerprinting?
Uses cases proposed by M. Lim, M. Akcay, A. Bentaleb, A. Begen, R. Zimmermann.
Closing this tracking issue as the use cases were formalized in the v1 candidate recommendation. These are listed below:
Annex B. Informative Use-Case Definitions (Informative)
Mostly a placeholder to call out that we should work on a use cases document to help shape/guide the metrics we will need and identify relevant actors (player to server, server to origin, etc.)