Fields to help inform suggested bitrate (through CMSD)

[PCaponetti]

Many times the player can do an alright job with bitrate selection on their own, but the CDN often has richer data spanning over time that can result in much more optimal selections. There is a tension between finding the optimal bitrate video to play for a particular user, and the privacy of that user. I would like to evaluate each type of data to see what should be available to CDNs and origins, and what is too private to ask of the player.

• viewport size: Larger viewports beg for more pixels of data.
• bitrate selection event: If the user decides to choose a higher or lower bitrate (if that ability is present in a player) is probably the most important piece of data to inform QoE based bitrate suggestion.
• visibility: Whether or not the video is visible to the end user. Background play is common enough now that suggesting low video bitrate could save a ton of bytes (if the player doesn't already optimize for this scenario).
• connection type: Connection type (wired, 3G/4G/5G, etc.) in conjunction with observed throughput (and time of day, day of month) give a better understanding of what can be expected of a connection.

Fields including data like fine grained device and connection details (hardware or software decoder, player type/version, data plan info, carrier identifier, battery status) are likely to intrusive to include in the spec, but can be helpful in the creation of bitrate suggestion models.

[acbegen]

More or less what was proposed and implemented in this paper: https://ieeexplore.ieee.org/document/10470394 (happy to share the pdf with anyone who wants to have a look)