Change:
I think we should wait until the [CTA-5004] reference link is resolved to merge this PR.
I made this change in the CMCD branch. We can merge it when we're ready.
Will resolve conflicts and merge.
We could reasonably start with standardized mechanisms, and could also give other examples. Also provide links to specifications that provide guidance on what to measure.
Replace: In addition to measurements media players use to guide their segment-by-segment adaptive streaming requests, streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media content caching is providing the best experience for viewers. With: In addition to measurements media players use to guide their segment-by-segment adaptive streaming requests, streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media content caching is providing the best experience for viewers. To that effect, the Consumer Technology Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. CTA-2066 specifies a set of media player events, properties, quality of experience (QoE) metrics and associated terminology for representing streaming media quality of experience across systems, media players and analytics vendors. While all these events, properties, metrics and associated terminology is used across a number of proprietary analytics and measurement solutions, they were used in slightly (or vastly) different ways that led to interoperability issues. CTA-2066 attempts to address this issue by defining a common terminology as well as how each metric should be computed for consistent reporting. Many assumes that the CDNs have a holistic view into the health and performance of the streaming clients. However, this is not the case. The CDNs produce millions of log lines per second across hundreds of thousands of clients and they have no concept of a "session" as a client would have, so CDNs are decoupled from the metrics the clients generate and report. A CDN cannot tell which request belongs to which playback session, the duration of any media object, the bitrate, or whether any of the clients have stalled and are rebuffering or are about to stall and will rebuffer. The consequence of this decoupling is that a CDN cannot prioritize delivery for when the client needs it most, prefetch content, or trigger alerts when the network itself may be underperforming. One approach to couple the CDN to the playback sessions is for the clients to communicate standardized media-relevant information to the CDNs while they are fetching data. CTA-5004 was developed exactly for this purpose.
CTA-2066: URL CTA-5004: URL
This should be addressed by . Ali, please confirm this, and let me know when we can change the reference URL for [CTA-5004].
URL is fixed now, so please use URL
Looks good, and I asked CTA to fix the link and they did, so please use instead: URL

Discussion:
This document provides an overview of operational networking issues that pertain to quality of experience in streaming of video and other <del> high-bitrate media over the internet. </del> <ins> high-bitrate media over the Internet. </ins> 1.

3. Streaming media latency refers to the "glass-to-glass" time duration, <del> which is the delay between the real-life occurence of an event and </del> <ins> which is the delay between the real-life occurrence of an event and </ins> the streamed media being appropriately displayed on an end user's device.  Note that this is different from the network latency (defined as the time for a packet to cross a network from one end to

Because adaptive application-level response strategies are typically using application-level protocols, these mechanisms are affected by transport-level protocol behaviors, and the application-level <del> feedback loop is interacting with a transport-level feedback loop, ase described in idle-time and hol-blocking. </del> <ins> feedback loop is interacting with a transport-level feedback loop, as described in idle-time and hol-blocking. </ins> 4.3.1.

players, or whether current media content caching is providing the best experience for viewers. <ins> In addition to measurements media players use to guide their segment- by-segment adaptive streaming requests, streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media content caching is providing the best experience for viewers.  To that effect, the Consumer Technology Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. 4.4.1. CTA-2066 specifies a set of media player events, properties, quality of experience (QoE) metrics and associated terminology for representing streaming media quality of experience across systems, media players and analytics vendors.  While all these events, properties, metrics and associated terminology is used across a number of proprietary analytics and measurement solutions, they were used in slightly (or vastly) different ways that led to interoperability issues.  CTA-2066 attempts to address this issue by defining a common terminology as well as how each metric should be computed for consistent reporting. 4.4.2. Many assumes that the CDNs have a holistic view into the health and performance of the streaming clients.  However, this is not the case. The CDNs produce millions of log lines per second across hundreds of thousands of clients and they have no concept of a "session" as a client would have, so CDNs are decoupled from the metrics the clients generate and report.  A CDN cannot tell which request belongs to which playback session, the duration of any media object, the bitrate, or whether any of the clients have stalled and are rebuffering or are about to stall and will rebuffer.  The consequence of this decoupling is that a CDN cannot prioritize delivery for when the client needs it most, prefetch content, or trigger alerts when the network itself may be underperforming.  One approach to couple the CDN to the playback sessions is for the clients to communicate standardized media-relevant information to the CDNs while they are fetching data.  CTA-5004 was developed exactly for this purpose. </ins> 4.5. In contrast to segmented delivery, several applications use UDP or