Web Application Video Ecosystem - Common Media Client Data (CTA-5004-A)

While playing back content, Media player clients can convey information to trusted endpoints. These endpoints can be the Content Delivery Networks (CDNs) from which the players are requesting content, or they can be third-party data collection services. The information conveyed can be useful in log analysis, Quality of Service (QoS) monitoring, Quality of Experience (QoE) monitoring, ad reporting, and delivery optimization. Session identification allows thousands of individual reports to be interpreted as a single user session, leading to a clearer picture of end-user experience. Bitrate, buffer, and segment signaling allow CDNs to fine-tune and optimize their midgress traffic by intelligently reacting to the time constraints implicit in each request. Prefetch hints allow CDNs to have content ready at the edge ahead of the player request, improving delivery performance. Buffer starvation flags allow performance problems across a multi-CDN delivery surface to be identified in real-time. Event-based reporting allows players to dispatch data when triggered by certain events, such as play state or content changes, user actions, errors, ad boundaries, received segments or a heartbeat time interval. In combination, this transferred data should improve the overall quality of experience enjoyed by consumers.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

This document outlines a means by which every media player can communicate structured data and have it processed consistently by CDNs and third-party data collection services.

This document defines the second version of the specification.

Common Media Client Data (CMCD) data supports two reporting modes named Request Mode and Event Mode. These modes differ in the target of the data as well as the trigger. Request Mode MUST be supported by every CMCD player. Event Mode is optional for player support. A player may report data using any combination of modes. The decision as to which reporting modes to use and which keys to use within those reporting modes is application-defined.

The player attaches CMCD data to each media object request, using either query arguments or request headers. Batch object data transfer mode is explicitly not allowed with request mode. This mode matches the default delivery mode in v1 of CMCD and MUST be supported by all v2 compliant player implementations. ‘Media objects' refers to any object requested by a media player during its normal course of operation. Examples include media segments, partial segments, manifests, license requests and captioning files.

The player reports CMCD data to one or more alternate destinations in batches in the HTTP request body as defined in Section 3. These reports are made at predefined events and are independent of the reports made by request mode.

The destination endpoint URLs are defined by the application and are given to the player via an out-of-band mechanism, such as a configuration file or media manifest.
Each report MUST include a ‘ts’ key, defining the time at which the event was triggered.
Each report MUST carry the event key 'e', defining the event that triggered the report.
Only keys defined in Table 1 as being allowed for Event reporting may be included with Event reports.

CMCD data can be transmitted by the following means:

As a custom HTTP request header,
As an HTTP query argument,
As an HTTP POST body – consisting of newline separated strings.

Each HTTP report MUST use only one data transmission mode. Multiple HTTP reports across a session MAY use different means of transmission. The preferred mode of transmission for non-batched reports is to use custom headers, unless these are inefficient due to CORS preflight requirements for custom headers.

A player MUST NOT send a value for an optional CMCD parameter if its value is unknown or undefined. Instead, the key MUST be omitted entirely from the data transmission.

Four headers are defined to transmit the data. The payload key/value pairs are sharded over these headers based upon their expected level of entropy, in order to assist with HPACK/QPACK [2][19] header compression. The headers begin with the prefix "CMCD-" and have the following case-insensitive names:

CMCD-Request

CMCD-Object

CMCD-Status

CMCD-Session

Note: Usage of a custom header from a web browser user-agent will trigger a preflight OPTIONS request before each unique media object request. This will lead to an increased request rate against the server. As a result, for CMCD transmissions from web browser user-agents that require CORS-preflighting per URL, the preferred mode of use is query arguments or for event-based reporting only - batch objects.

The query argument is case-sensitive and capitalization MUST be used.

CMCD=<URL_encoded_concatenation_of_key_value_pairs><reserved_character>

The reserved character is defined by RFC 3986 [3]. This reserved character is optional at the end of the URL.

If the request already bears a query string, then an ampersand Unicode 0x26 character should precede the CMCD field.

<string>(\n<string>)*

A body object is constructed by concatenating one or more CMCD records separated by a single Line Feed (LF) character (Unicode 0x0A). Each record is constructed by concatenating query argument values according to the rules of section 3.2 with the exception that the string is not URL encoded. The encoding MUST be UTF-8 [18]. Trailing and leading spaces on each line MUST be ignored by the receiver. If the body contains only a single record, then a trailing single Line Feed (LF) character MUST NOT be present.

Body payloads MUST be transmitted using an HTTP POST request in which the body object forms the body of the request. The content-type MUST be "text/cmcd".

Example (where \n is used indicate the Line Feed [LF] character):

bl=11200,br=67,d=4011,dl=11200,mtp=42900,nor="bbb_a64k_5.m4a",ot=a,rtp=200,sf=d,sid="31b090a2-def1-44f9-87f8-4f8213c7bf63",st=v,tb=67\nbl=41400,br=67,d=4011,dl=41400,mtp=60100,nor="bbb_a64k_6.m4a",ot=a,rtp=100,sf=d,sid="e871f4ee-7945-4001-aae1-ca280f4717df",st=v,tb=67\nbl=53400,br=67,d=4011,dl=53400,mtp=64500,nor="bbb_a64k_7.m4a",ot=a,rtp=100,sf=d,sid="e871f4ee-7945-4001-aae1-ca280f4717df",st=v,tb=67

The data payload for Header and Query Argument transmission consists of a series of key/value pairs constructed according to the following rules:

All information in the payload MUST be represented as <key>=<value> pairs.
The key and value MUST be separated by an equals sign (Unicode 0x3D). If the value type is BOOLEAN and the value is TRUE, then the equals sign and the value MUST be omitted as described in RFC 8941 [5] section 3.1.2.
Successive key/value pairs MUST be delimited by a comma (Unicode 0x2C).
The key names described in Table 1 are reserved.
Custom key names may be used, but they MUST carry a hyphenated prefix to ensure that there will not be a namespace collision with future revisions to this specification. Players SHOULD use a reverse-DNS syntax when defining their own prefix. Custom keys MUST have a value type of STRING or TOKEN and a maximum character count of 64.
If headers are used for data transmission, then custom keys SHOULD be allocated to one of the four defined header names based upon their expected level of variability:

CMCD-Request: keys whose values vary with each request.
CMCD-Object: keys whose values vary with the object being requested.
CMCD-Status: keys whose values do not vary with every request or object.
CMCD-Session: keys whose values are expected to be invariant over the life of the session.

All key names are case-sensitive.
Any value of type String MUST be enclosed by opening and closing double quotes (Unicode 0x22). Double quotes and backslashes MUST be escaped using a backslash ("\" Unicode 0x5C) character. Any value of type Token does not require quoting.
All keys are OPTIONAL except for ‘v’ which is now required as of version 2.
Key-value pairs SHOULD be sequenced in alphabetical order of the key name in order to reduce the fingerprinting surface exposed by the player. This requirement also applies to any custom key names included in the report.
If the data payload is transmitted as a query argument, then the entire payload string MUST be URLEncoded per [4]. Data payloads transmitted via headers MUST NOT be URLEncoded.
The data payload syntax MUST be compliant with Structured Field Values for HTTP [5].
Transport Layer Security SHOULD be used to protect all transmission of CMCD data.
Some keys allow different values per object type. To enable this we use inner lists with Object Type parameters. The parameter name matches an object type token and has a boolean value. An Inner List [5] is denoted by opening (Unicode 0x28) and closing (Unicode 0x29) parenthesis, with each internal element separated by a space (Unicode 0x20). The list syntax MUST always be used even if only a single value is present. The allowed tokens are those defined as allowed values for the Object Type 'ot' key in Table 1. An example describing an encoded bitrate of 5mbps for video and 320kbps for audio would be br=(5000;v 320;a).

Transport Layer Security SHOULD be used to protect all transmission of CMCD data.
The payload for batch is constructed by appending individual query argument payloads using the format defined in Section 3.3.

The reserved keys and their definitions are defined in Table 1 below.

Table 1: Reserved Key and Value definitions

Description	Key Name	Header Name	Type & Unit	Value definition	Allowed Modes
Aggregate encoded bitrate	ab	CMCD-Object	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The aggregate encoded bitrate across a playable combination of tracks. This metric SHOULD NOT be used when the individual bitrates of the tracks are known. This value SHOULD be derived from a playlist/manifest declaration, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value MUST be transmitted. This value MUST NOT be sent if the encoded bitrate is known.	Request Event
Buffer length	bl	CMCD-Request	Inner list of integer milliseconds with token identifiers (see 4.1, item 14).	The buffer length associated with the media object being requested. This value SHOULD be rounded to the nearest 100 ms.	Request Event
Backgrounded	bg	CMCD-Status	Boolean	All players in a session are currently in a state that is not visible to the user due to a user interaction. This key SHOULD only be sent if it is TRUE. If the visibility state of the player is not known this key SHOULD NOT be reported.	Request Event
Encoded bitrate	br	CMCD-Object	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The encoded bitrate. In request mode, this refers to the encoded bitrate of the requested representation. In event mode this refers to the encoded bitrate of the currently selected representation. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value MUST be transmitted.	Request Event
Buffer starvation	bs	CMCD-Status	Boolean	TRUE if the player buffer was starved at some point between the prior report and this report per reporting destination, resulting in the player entering a rebuffering state or remaining in a rebuffering state. Note that if the player begins requesting data from a new CDN, then this key might initially report buffering caused by the prior CDN. This key SHOULD NOT be reported if it is FALSE. If the object type ‘ot’ key is sent along with this key, then the ‘bs’ key refers to the buffer count associated with the particular object type. If no object type is communicated, then the buffer state applies to the current session.	Request Event
Buffer Starvation Absolute	bsa	CMCD-Status	Inner list of integers with optional token identifiers (see 4.1, item 14).	An absolute count of buffer starvation events since session initiation. A buffer starvation event occurs when the state changes to rebuffering. Token identifier MAY be omitted if the cause of the rebuffering is unknown.	Request Event
Buffer Starvation duration	bsd	CMCD-Status	Inner list of integer milliseconds with optional token identifiers (see 4.1, item 14).	A list of durations of each buffer starvation period reported once the rebuffering has completed. This value MUST only be reported once per reporting mode and report destination. Token identifier MAY be omitted if the cause of the rebuffering is unknown.	Request Event
Buffer Starvation Duration Absolute	bsda	CMCD-Status	Inner list of integer milliseconds with optional token identifiers (see 4.1, item 14).	An absolute count of buffer starvation duration since session initiation. Token identifier MAY be omitted if the cause of the rebuffering is unknown.	Request Event
Custom Event Name	cen	N.A	String	Used to define a custom event name. A maximum length of 64 characters is allowed. This key MUST be sent when the event type is 'ce' (custom event) and MUST NOT be sent when the event type is any other value. A custom key-value pair MAY be used to transfer a custom value associated with this event. The names chosen SHOULD associate the custom event name with the custom key name.	Event
Content ID	cid	CMCD-Session	String	A unique string identifying the current content. The maximum length is 128 characters. This value is consistent across multiple different sessions and devices and is defined and updated at the discretion of the service provider.	Request Event
CMSD Dynamic Header	cmsdd	N.A	String	Holds a Base64 [13] encoded copy of the CMSD [15] data received on the CMSD-Dynamic response header. This key MUST only be reported on events of type rr (response received).	Event
CMSD Static Header	cmsds	N.A	String	Holds a Base64 [13] encoded copy of the CMSD [15] data received on the CMSD-Static response header. This key MUST only be reported on events of type rr (response received).	Event
Content Signature	cs	CMCD-Request	String	A string representing a signature of the content being played. This field SHOULD vary with content ID and be bound by some mechanism to the content. For example, this field may be used to transmit the C2PA signature associated with the content being viewed.	Request Event
Object duration	d	CMCD-Object	Integer milliseconds	The playback duration in milliseconds of the object being requested. If a partial segment is being requested, then this value MUST indicate the playback duration of that part and not that of its parent segment. This value can be an approximation of the estimated duration if the explicit value is not known. This value MUST NOT be sent for objects which do not have an object type of ‘a’, ‘v’, ‘av’, ‘tt’, ‘c’, or ‘o’.	Request Event
Dropped Frames Absolute	dfa	CMCD-Request	Integer	An absolute count of dropped frames since session initiation. This key SHOULD only be sent for content types of 'v', 'av' or 'o'. Note that this value will be driven by the content being rendered rather than the content being retrieved, therefore it is beneficial if accompanied by the playhead time 'pt' key to allow for correct interpretation.	Request Event
Deadline	dl	CMCD-Request	Integer milliseconds	Deadline from the request time until the first sample of this Segment/Object needs to be available in order to not create a buffer underrun or any other playback problems. This value MUST be rounded to the nearest 100ms. For a playback rate of 1, this may be equivalent to the player’s remaining buffer length.	Request Event
Event	e	N.A	Token - one of [ abs, abe, ae, as, b, bc, c, ce, e, h, m, pc, pe, ps, rr, sk, t, um ]	This key MUST only be used in Event mode and MUST be present on all reports. The minimum recommended set of supported events are: `ps`, `e`, `t`, and `rr`. abs - ad break start: The start of an ad break or ad pod which would contain 1 or more sequential ads. abe - ad break end: This signals the end of an ad break or ad pod. If the ad break is ended early for any reason this event should still be fired when leaving the ad break and resuming content. This token should only be used if the associated ad break start event has been triggered before. ae - ad end: This token should be used at the end of the current playing ad but before exiting the ad. This includes if the ad has an error during playback or if the ad is being skipped mid playback. This token should only be used if the associated ad start event has been triggered before. as - ad start: This token should be used when a new ad begins playing within an ad break pod. b - The player has entered backgrounded mode if this event is accompanied by the ‘bg’ key and exited backgrounded mode if not. bc - The bitrate being requested by the player, for any object type, has changed. c - content ID has changed. ce - custom event. e - the player has experienced an error. This token MUST be accompanied by a 'ec' key defining the player error code. h - hostname has changed. m - mute. The user activated the mute control or set the volume to zero. pc - playerCollapse: The user activated a control to reduce the player to a smaller size. The definition of this event is intended to be compliant with the VAST [14] Player Operation Metrics. pe – playerExpand: The user activated a control to extend the player to a larger size. The definition of this event is intended to be compliant with the VAST [14] Player Operation Metrics. pr - playback rate change. This event only triggers while the state is playing ('p'). Note that certain players may have very frequent playback rate changes, in which case use of this event is not recommended. ps - play state change: This token MUST be accompanied by a 'sta' key carrying the new state. rr - response received: This signals the receipt of a response. This event SHOULD be accompanied with the url key holding the URL of the request that triggered this response. sk - skip: The user activated a control to skip an advertisement. t - time interval: The interval at which these reports are made is application-defined. A default interval of 30 seconds SHOULD be used if no explicit application interval is provided. Short form content may wish to use a shorter interval. An application-defined interval of zero should be interpreted as turning off interval event reporting. This event MUST be supported by all players that support Event mode. um – unmute: The user deactivated the mute control or raised the volume above zero if it was previously set to zero.	Event
Player Error Code	ec	CMCD-Status	Inner list of strings	A string defining an error code produced by the player. The namespace and formatting of this error code is left to the application. Even if only one error code is being specified, the list notation MUST still be used. Errors should be buffered per report destination as they occur and reported along with the next CMCD report. With Event mode there is the option to report errors as they occur.	Request Event
Hostname	h	N.A	String	A string identifying the current hostname from which the player is retrieving content. Maximum length is 128 characters.	Event
Lowest aggregated encoded bitrate	lab	CMCD-Object	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The lowest aggregated bitrate rendition in the manifest or playlist. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value MUST be transmitted. The aggregate encoded bitrate is of the complete media object including all object types. This value MUST NOT be sent if the lowest encoded bitrate is known.	Request Event
Lowest encoded bitrate	lb	CMCD-Object	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The lowest bitrate rendition in the manifest or playlist. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value MUST be transmitted. This lowest bitrate MUST apply to the object type being requested. Requests for video objects MUST specify the lowest video bitrate and requests for audio objects MUST specify the lowest audio bitrate.	Request Event
Live stream latency	ltc	CMCD-Request	Integer milliseconds	The time delta between when a given media timestamp was made available at the origin and when it was rendered by the player. The accuracy of this estimate is dependent on synchronization between the packager and the player clocks.	Request Event
Media Start Delay	msd	CMCD-Session	Integer milliseconds	Measures the initial delay in wall-clock time from when a player is instructed to play media for a given session to when any media begins playback, whether it be primary content or interstitial content. This value SHOULD be the time difference between the "starting" and "playing" states. This key MUST only be sent once per Session ID and MUST be sent for each reporting mode which is active within the player. For request reporting mode, this key SHOULD be sent on the next media object request following successful startup.	Request Event
Measured throughput	mtp	CMCD-Request	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The throughput between player and server, as measured by the player. Throughput MUST be rounded to the nearest 100 kbps. This value, however derived, SHOULD be the value that the player is using to make its next Adaptive Bitrate switching decision. If the player is requesting different object types from different providers then it SHOULD take care to match the throughput measured against that provider with each object type request. It is acceptable to report aggregate information if objects of the same type are requested from different providers. If the player has multiple concurrent connections to the provider, then the intent is that this value communicates the aggregate throughput the player sees across all those connections. If this key is sent on an interval report, the value transmitted should be the last throughput estimate made by the player prior to making the report. There is no requirement for the player to calculate the average measured throughput since the prior interval report.	Request Event
Next object request	nor	CMCD-Request	Inner list of strings	The relative path, as defined by RFC 3986 [3], to one or more objects which can reasonably be expected to be requested by the player making the current request. Each object SHOULD be fetched in its entirety unless there is a range associated with the future request. Even if only one object is being specified, the list notation MUST still be used. If there is a range associated with the future request, then the range is communicated as the parameter 'r' with a String value. The formatting of the String value is similar to the HTTP Range header, except that the unit MUST be ‘byte’, the ‘Range:’ prefix is NOT permitted, specifying multiple ranges is NOT allowed and the only valid combinations are: "<range-start>-" "<range-start>-<range-end>" "-<suffix-length>" The player SHOULD NOT depend upon any pre-fetch action being taken - it is merely a request for such a pre-fetch to take place.	Request Event
Non rendered	nr	CMCD-Status	Boolean	True when the content being retrieved by a player is not rendered as audio or video. The key SHOULD only be sent when it is TRUE. The purpose of this key is to disambiguate active background players from foreground players which may be rendering interstitial content.	Request Event
Object type	ot	CMCD-Object	Token - one of [ m, a, v, av, i, c, tt, k, o ]	The media type of the current object being requested: m = text file, such as a manifest or playlist a = audio only v = video only av = muxed audio and video i = init segment c = caption or subtitle tt = ISOBMFF timed text track k = cryptographic key, license or certificate. o = other If the object type being requested is unknown, then this key MUST NOT be used. This key is also used as a token parameter for other keys, as described in Section 4.1.	Request Event
Playhead bitrate	pb	CMCD-Request	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The encoded bitrate of the media object(s) being shown to the end user.	Request Event
Playback rate	pr	CMCD-Status	Decimal	1.0 if real-time, 2.0 if double speed, 0 if not playing. SHOULD only be sent if not equal to 1.0.	Request Event
Playhead time	pt	CMCD-Status	Integer milliseconds	The playhead time, expressed in milliseconds, which is being rendered to the viewer when the report is made. For Event mode, this corresponds to the playhead time that was rendered at the wallclock time reported by the timestamp field. For VOD, this MUST be milliseconds offset from the beginning of the media asset. For live streams with a playhead date time, this field MUST be expressed as the number of milliseconds that have elapsed since the Unix Epoch (January 1, 1970, at 00:00:00 UTC), excluding leap seconds [17].	Request Event
Response code	rc	N.A	Integer	The response code received when requesting a media object. In a redirect scenario, this would be the final response code received. A value of 0 SHOULD be used to indicate that a response was not received. This key MUST only be reported on events of type rr (response received).	Event
Requested maximum throughput	rtp	CMCD-Status	Integer kbps	The requested maximum throughput that the player considers sufficient for delivery of the asset. Values MUST be rounded to the nearest 100kbps. For example, a player would indicate that the current segment, encoded at 2Mbps, is to be delivered at no more than 10Mbps, by using rtp=10000. Note: This can benefit players by preventing buffer saturation through over-delivery and can also deliver a community benefit through fair-share delivery. The concept is that each player receives the throughput necessary for great performance, but no more. The CDN may not support the rtp feature.	Request Event
Streaming format	sf	CMCD-Session	Token - one of [ d, h, e, s, o ]	The streaming format that defines the current request. d = MPEG DASH [9] h = HTTP Live Streaming (HLS) [10] e = HESP [11] s = Smooth Streaming [12] o = other	Request Event
Session ID	sid	CMCD-Session	String	A GUID identifying the current playback session. A playback session typically consists of the playback of a single media asset along with accompanying content such as advertisements.. This session may comprise the playback of primary content combined with interstitial content. This session is being played on a single device. The maximum length is 64 characters. It is RECOMMENDED to conform to the UUID specification [6].	Request Event
SMRT-Data Header	smrt	N.A	String	Holds a Base64 [13] encoded copy of the streaming media response tracing data received on the Request Tracing header [16]. This key MUST only be reported on events of type rr (response received).	Event
Sequence Number	sn	CMCD-Request	Integer	A monotonically increasing integer to identify the sequence of a CMCD report to a target within a session. This MUST be reset to zero on the start of a new session-id. Sequence numbers increase independently per each combination of mode and target.	Request Event
Stream type	st	CMCD-Session	Token - one of [ v, l, ll ]	v = all segments are available – e.g., VOD l = segments become available over time – e.g., LIVE ll = low latency LIVE	Request Event
State	sta	CMCD-Request	Token - one of [ s, p, k, r, a, w, e, f, q, d ]	A token describing the current playback state of the player as perceived by the end user, one of: s - starting: the player has been instructed to play media for a given session, either by a user interaction or by an autoplay action. p - playing: Media is being rendered. k - seeking: The start of the action of moving the playhead position after starting. r - rebuffering: Media has stopped being rendered due to an insufficient buffer. This state is not reported during startup or seeking. a - paused: Playback has been intentionally paused by either the user or the player. e - ended: Rendering has ended due to completion of the media asset playback. f - fatal error: Rendering has ended due to an irrecoverable error. q - quit: User initiated end of playback before media asset completion. d - preloading: the player is loading, or has loaded, assets ahead of starting in order to provide a fast startup. The expectation is that playback will commence at a future time. Note: if used with Request Mode, then this key represents a snapshot of the state at request time, which may obscure prior state changes since the last request. For most accurate state tracking in players, use Event mode. The addition of a timestamp in Request Mode might be useful in correctly placing the state change on a timeline.	Request Event
Startup	su	CMCD-Request	Boolean	Key is included without a value if the object is needed urgently due to startup, seeking or recovery after a buffer-empty event. The player reports this key as true until its buffer first reaches the target buffer for stable playback. Note: the starting State 's' is valid until the player renders media for the end user, which may be different from when the target buffer has been reached. As a result, 'su' = TRUE and 'sta' = 's' are not expected to align on a timeline.	Request Event
Top aggregated encoded bitrate	tab	CMCD-Object	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The highest aggregated bitrate rendition in the manifest or playlist. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value MUST be transmitted. The aggregate encoded bitrate is of the complete media object including all object types. This value MUST NOT be sent if the top encoded bitrate is known.	Request Event
Top encoded bitrate	tb	CMCD-Object	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The highest bitrate rendition in the manifest or playlist. This SHOULD be derived from playlist/manifest declarations, or it MAY be estimated by the player. If the playlist declares both peak and average bitrate values, the peak value MUST be transmitted. This top bitrate MUST apply to the object type being requested. Requests for video objects MUST specify the top video bitrate and requests for audio objects MUST specify the top audio bitrate.	Request Event
Target Buffer length	tbl	CMCD-Request	Inner list of integer milliseconds with token identifiers (see 4.1, item 14).	The target buffer length associated with the media object being requested at the time of the request. This value SHOULD be rounded to the nearest 100 ms.	Request Event
Top playable bitrate	tpb	CMCD-Object	Inner list of integer kbps with token identifiers (see 4.1, item 14).	The highest bitrate rendition that the player is currently capable of playing for reasons other than bandwidth limitations. This key captures the cases in which, for example, screen resolution, DRM, or performance constraints limit the player's topmost choice of bitrate. These constraints are intentionally obfuscated for privacy reasons. This key can increase the fingerprinting surface exposed by CMCD transmission and SHOULD NOT be transmitted in a default player configuration. If the playlist declares both peak and average bitrate values, the peak value MUST be transmitted. This top playable bitrate MUST apply to the object type being requested. Requests for video objects MUST specify the top playable video bitrate and requests for audio objects MUST specify the top playable audio bitrate. This value MUST NOT be sent for objects which do not have an object type of ‘a’, ‘v’, ‘av’ or ‘c’.	Request Event
Timestamp	ts	N.A	Integer milliseconds	The timestamp at which the associated event occurred, expressed as the number of milliseconds that have elapsed since the Unix Epoch (January 1, 1970, at 00:00:00 UTC), excluding leap seconds [17]. When the event is a request for a media object the time SHOULD reference when the request was first initiated. This key MUST be included with all Event reports.	Event
Time to first byte	ttfb	N.A	Integer milliseconds	The elapsed time between when the request was first initiated (captured in ts) and the time when the first byte of the response was received. This value should only be reported if it is known. Absence of this key does not indicate that the response was not received. This key MUST only be reported on events of type rr (response received).	Event
Time to first body byte	ttfbb	N.A	Integer milliseconds	The elapsed time between when the request was first initiated (captured in ts) and the time the first bytes of the response body are received. This value should only be reported if it is known. Absence of this key does not indicate that the body was not received. This key MUST only be reported on events of type rr (response received).	Event
Time to last byte	ttlb	N.A	Integer milliseconds	The elapsed time between when the request was first initiated (captured in ts) and the time the response body is fully received. This value should only be reported if it is known. Absence of this key does not indicate that the response was not fully received. This key MUST only be reported on events of type rr (response received).	Event
Request URL	url	N.A	String	The URL used to request the media object. If the request is redirected, this key MUST report the initial requested URL. This key MUST be reported on events of type rr (response received).	Event
Version	v	CMCD-Session	Integer	The version of this specification used for interpreting the defined key names and values. If this key is omitted, the player and server MUST interpret the values as being defined by version 1. player SHOULD omit this field if the version is 1 and MUST include this field if the version is not 1.	Request Event

A player SHOULD supply ‘sid’ on all media object requests in a session, including playlists/manifests, init files, captioning files and DRM key requests. Other keys SHOULD be applied where they have contextual meaning. For example, a ‘br’ (bitrate) key on a manifest request is inappropriate and could be omitted.

If there are multiple players used to play different content IDs as part of a session, use of the content ID change events along with play state and not rendered SHOULD be used to make clear the experience of the user. The following are example sessions with a single-player, multiple players with sequential ad breaks, and multi-players with parallel ad breaks:

Figure 1: Variation in Content ID across ad breaks, for single and multi-player sessions

This section outlines requirements for player-side implementations of CMCD v2. Adherence to these guidelines can enhance interoperability, backward compatibility, and the overall effectiveness of CMCD data reporting.

Backward Compatibility with CMCD v1 Configuration: Players migrating from CMCD v1 SHOULD maintain backward compatibility with CMCD v1 configuration methods. Furthermore, it is RECOMMENDED to extend the player's configuration capabilities to comprehensively support the new Event Mode introduced in CMCD v2.
Mixed Version Support for CDNs: To ensure backward compatibility with CMCD v1 implementations that may exist on CDN infrastructure, a player SHOULD support sending CMCD data using v1 syntax (i.e., omitting the v key or as per v1 rules if v key behavior differs) for Request Mode, while utilizing CMCD v2 syntax (e.g., including v=2) for data transmitted via Event Mode.
Handling of Mandatory Keys: CMCD v2 designates certain keys as mandatory. Players SHOULD NOT provide configuration options that allow end-users to disable the transmission of these mandatory keys when the conditions for their inclusion are met and their respective values are known by the player.
Multiple Targets for Event Mode: Players implementing Event Mode SHOULD
support the configuration of multiple destination targets (URLs) for that mode. It
is RECOMMENDED that each configured target can possess distinct settings such as batching size for batch object transmission and other mode-specific parameters.
Key Filtering per Target: For players supporting multiple targets in Event mode, it is RECOMMENDED to implement a mechanism for configuring key filters on a per-target basis. Such filters allow each destination endpoint to receive only the specific subset of CMCD keys that are relevant to its operational requirements, minimizing data overhead.
If there are CMCD keys specified in a manifest as part of segment request URLs, care should be taken to remove/overwrite or merge them with future CMCD reports ideally based on configuration options.
Centralized Configuration for cid and sid: To maintain data integrity and consistency, the Content ID (cid) and Session ID (sid) keys SHOULD be configurable from a single setting or else be algorithmically deterministic. This practice ensures that uniform values for cid and sid are utilized across all CMCD reporting modes (Request, Event) and for all configured destination targets, thereby preventing potential data inconsistencies.
Event Filtering for Event Mode: For Event mode, it is RECOMMENDED that players support the configuration of event filters for each designated target. This capability enables each Event Mode target to receive reports only for the specific events (corresponding to the allowed values of the e key, as defined in Table 1) that it needs to process.
Management of Custom Keys: Players SHOULD implement a mechanism that facilitates the straightforward addition and management of custom (non-reserved) keys. The player SHOULD verify that any configured custom keys adhere to the naming conventions and value length and types stipulated in this specification before transmission. The player SHOULD include a configuration field specifying which header the custom key uses under header-transmission mode. It is RECOMMENDED that players supporting multiple targets (for Event mode) allow the selective inclusion of different sets of custom keys for each distinct destination target.
Players SHOULD follow any redirects given by the beacon endpoint.
Handling of 2xx Responses: Player SHOULD understand 2xx response codes as successful receipt of CMCD data. For Event based reporting, a 204 response code is expected with an empty body response.
Handling of HTTP 429 Response: For CMCD data sent via Event mode, players SHOULD appropriately handle the HTTP 429 (Too Many Requests) response code from the target. If batching is employed, it is RECOMMENDED that the player implements a back-off strategy. This MAY include automatically increasing the number of messages aggregated per batch or increasing the delay interval between the transmissions of subsequent batches.
Handling of HTTP 410 Response: For CMCD data sent via Event mode, players SHOULD appropriately handle the HTTP 410 (Gone) response code received from the target. Upon receiving a 410 response, the player SHOULD immediately cease sending any further CMCD reports to that specific target URL for the remainder of the current session.
Handling of HTTP 5XX responses: For CMCD data sent via Event mode, players SHOULD appropriately handle the HTTP 5XX (server error) response codes received from the target by batching and retrying with a back-off interval strategy.
In the event of lost connectivity with Event mode reports, a player SHOULD batch reports and attempt to deliver them once connectivity is restored.
To limit access to CMCD targets, configuration of CMCD can include access tokens. These tokens may be incorporated into the URLs of the CMCD targets themselves or can be added to the commonly used ‘Authorization’ header. A configuration option SHOULD be added per-target specifying the value to add to the Authorization header on all requests to that target.
If the content has metadata defining CMCD configuration, the player SHOULD apply this configuration by default.
When the player is requesting interstitial content and the CMCD configuration for that content is unknown, it is RECOMMENDED not to append CMCD data in order to avoid issues with the target destination not supporting CMCD.
Players SHOULD offer a mechanism to restrict which portion of a URL is shared when the 'url' key is used, for privacy or security reasons.
To ensure accuracy in analysis, Boolean keys MAY be reported as FALSE using the concise notation offered by Structured Field Values, for example bs=?0,su=?0.
The 'url', 'nor', 'smrt' and 'smt' keys can potentially be large. Implementers of these keys SHOULD guard against length limits in query-reporting mode. An option for very large payloads in Event mode would be to use Batch reporting mode with a single report, which would allow a report payload of an unconstrained size.

Server MUST only process these requirements when data is received via a valid CMCD header or query argument.
A server, upon receiving common media client data, MUST interpret the keys according to their definition in this document.
Unknown keys, which the server does not understand, MUST be ignored, without affecting known key values.
Values that do not meet the structured data definition (such as an invalid token, or a string when an integer is expected) MUST be ignored.
Since there is no guarantee that keys are included, the server MUST be robust against the absence of individual keys on any given request.
The server MUST be able to correctly process the key-value pairs irrespective of the order in which they are provided.
If the sid key is present, the server SHOULD propagate that value to the server access logs. The server access logs SHOULD conform to RFC 6302 [7].
The server MUST support both the header and query argument methods of data transmission. The server MUST process data from only the query argument or the request header, but never both for a given request. If any CMCD headers are present, then any CMCD query argument information MUST be ignored.
The server, upon receiving the requested throughput (rtp) attribute, is not required to throttle the response at the requested value. It is merely a request from the player and the server may have other business requirements that dictate throttling at a different value or not throttling the response at all.
The server, upon receiving the nor "next object request" key, MAY optionally decide not to implement any pre-fetch action against that data.
Servers SHOULD provide the necessary CORS responses to allow browser-based players to send custom headers, specifically:

Access-Control-Allow-Headers response header with a value that contains "CMCD-Request, CMCD-Object, CMCD-Status, CMCD-Session".
Access-Control-Allow-Methods with a value that includes GET.

Servers SHOULD be aware that malicious players may send false key data with the objective of either attacking the server or gaining an unfair delivery advantage. The server SHOULD validate incoming key data before any performance impacting behaviors are executed.
Servers MUST ignore the entire data set if the signaled version is greater than they understand, as they cannot know which fields have been modified or deprecated. Servers SHOULD log the version incompatibility so that there is a record of why the data is not getting logged.
The server SHOULD support HTTPS and MAY support HTTP requests, to maximize compatibility with players operating under the Web Security Model and to maximize privacy.
The response to a beacon-based request is not defined by this specification and the response MAY have an empty body. The communication between the player and the reporting endpoint MUST adhere to standard HTTP protocol mechanisms and properly react to response codes as defined in RFC 9110 (HTTP Semantics). An endpoint implementation:

SHOULD return 2xx codes (including 204 for empty response) to indicate successful receipt of CMCD data.
SHOULD return a redirect when appropriate (301, 302).
SHOULD return a 429 when the server becomes overloaded.
SHOULD return a 410 when the server wants to stop incoming requests.

Note: Any caching proxy should be aware that the CMCD payload will be constantly changing and therefore has the potential to pollute cache keys. Implementers may wish to exclude CMCD query arguments from any cache key.

Note: Origin servers are advised not to include the CMCD-Request, CMCD-Object, CMCD-Status, CMCD-Session headers in the Vary header [8].

The data transmitted as defined by this specification is passed between a client device and a Content Delivery Network (CDN) or other data receiving nodes, as described in Section 2, Data Transmission Modes. Data is exchanged over HTTP/HTTPS during the regular process of a media client requesting content. The HTTP Request Headers and Query Arguments utilized for data transmission are mature and established technologies for data transmission over the web. Transport Layer Security (TLS) can provide confidentiality and integrity for data during transmission.

A malicious player may inject false data. This tactic may be part of replay, message insertion, or modification attacks. If the server-client communication is delivered over HTTP, then man-in-the-middle attacks are feasible. Use of HTTPS for communications mitigates these attacks. All server responses are optional, which aids in server-based protection strategies. The server is not required to take any action upon receiving CMCD data.

Some limited denial-of-service amplification opportunity exists for malicious players utilizing the next-object-request key. Requiring the next object to be a relative path to the current request, along with the prefetch operation being optional for the server, helps mitigate this amplification.

Privacy concerns resulting from successful eavesdropping and man-in-the-middle attacks in this threat environment indicate the need to strictly limit device-identifiable data. Therefore, fingerprinting opportunities have been minimized; see sections 3.1 and 3.2. Identification confidentiality of content, as described above, is dependent upon protocol-layer protections since the player must by definition request playback of specific content pieces to operate.

Defense against malicious content injected via man-in-the-middle, message insertion, or message modification attacks is likewise dependent upon protocol-layer protections. HTTPS is strongly recommended over HTTP, when applicable, for all CMCD data transmissions over the web.

As discussed above, this specification does not expose any security issues that are not already exposed to a player making media object requests or to an edge server that answers all incoming requests. A number of steps have been taken to mitigate specific security and privacy concerns:

The ‘nor’ key value is a relative path to the current request. This makes it harder to inject false requests to arbitrary objects.
All requests to the server are optionally executed by the server, meaning that a server can ignore them for security concerns (such as a rate-based threshold being exceeded) and still be compliant with the specification.
Session ID is a GUID which is highly unlikely to repeat for a particular user.
Measured throughput, requested maximum throughput, deadline and buffer length are bucketed to reduce fingerprinting surface.
Key-value pairs are suggested be sequenced in alphabetical order to reduce fingerprinting surface.
Personally Identifiable Information fields, such as IP address, cookie information and location data, are intentionally not carried by the specification.

These examples illustrate valid data combinations across the various delivery modes. In many examples, the same information is repeated three times: as raw keys, as Query-args and as Headers.

Raw keys:


bl=(2000),br=(3000;v),cid="content-id-123",d=4000,dl=1000,mtp=(15000),nor=("next-seg.mp4"),ot=v,rtp=12000,sf=d,sid="session-id-123",st=v,sta=p,tb=(6000;v),v=2

Query-arg:


CMCD=bl%3D%282000%29%2Cbr%3D%283000%3Bv%29%2Ccid%3D%22content-id-123%22%2Cd%3D4000%2Cdl%3D1000%2Cmtp%3D%2815000%29%2Cnor%3D%28%22next-seg.mp4%22%29%2Cot%3Dv%2Crtp%3D12000%2Csf%3Dd%2Csid%3D%22session-id-123%22%2Cst%3Dv%2Csta%3Dp%2Ctb%3D%286000%3Bv%29%2Cv%3D2

Headers:


CMCD-Request: bl=(2000),dl=1000,mtp=(15000),nor=("next-seg.mp4"),sta=p
CMCD-Object: br=(3000;v),d=4000,ot=v,tb=(6000;v)
CMCD-Status: rtp=12000
CMCD-Session: cid="content-id-123",sf=d,sid="session-id-123",st=v,v=2

Raw keys:


bl=(2000),br=(320),cid="content-id-123",d=2000,mtp=(15000),ot=a,sid="session-id-123",st=v,v=2

Query-arg:


CMCD=bl%3D%282000%29%2Cbr%3D%28320%29%2Ccid%3D%22content-id-123%22%2Cd%3D2000%2Cmtp%3D%2815000%29%2Cot%3Da%2Csid%3D%22session-id-123%22%2Cst%3Dv%2Cv%3D2

Headers:


CMCD-Request: bl=(2000),mtp=(15000)
CMCD-Object: br=(320),d=2000,ot=a
CMCD-Session: cid="content-id-123",sid="session-id-123",st=v,v=2

Raw keys:


cid="content-id-123",sid="session-id-123",v=2

Query-arg:


CMCD=cid%3D%22content-id-123%22%2Csid%3D%22session-id-123%22%2Cv%3D2

Headers:


CMCD-Session: cid="content-id-123",sid="session-id-123",v=2

Request 1: Manifest/Playlist fetch (Startup)

Raw keys:


cid="content-id-123",ot=m,sf=d,sid="session-id-123",st=v,su,v=2

Query-arg:


CMCD=cid%3D%22content-id-123%22%2Cot%3Dm%2Csf%3Dd%2Csid%3D%22session-id-123%22%2Cst%3Dv%2Csu%2Cv%3D2

Headers:


CMCD-Request: su
CMCD-Object: ot=m
CMCD-Session: cid="content-id-123",sf=d,sid="session-id-123",st=v,v=2

Request 2: Init Segment (Startup)

Fetching the initialization segment. 'nor' requests the first two media segments.

Raw keys:


bl=(0),br=(3000;v),cid="content-id-123",mtp=(15000),nor=("seg-1.m4v" "seg-2.m4v"),ot=i,sid="session-id-123",st=v,sta=s,su,v=2

Query-arg:


CMCD=bl%3D%280%29%2Cbr%3D%283000%3Bv%29%2Ccid%3D%22content-id-123%22%2Cmtp%3D%2815000%29%2Cnor%3D%28%22seg-1.m4v%22%20%22seg-2.m4v%22%29%2Cot%3Di%2Csid%3D%22session-id-123%22%2Cst%3Dv%2Csta%3Ds%2Csu%2Cv%3D2

Headers:


CMCD-Request: bl=(0),mtp=(15000),nor=("seg-1.m4v" "seg-2.m4v"),sta=s,su
CMCD-Object: br=(3000;v),ot=i
CMCD-Session: cid="content-id-123",sid="session-id-123",st=v,v=2

Request 3: First Segment (Starting/Buffering)

Fetching the first media segment. nor requests the next two segments.

Raw keys:


bl=(0),br=(3000;v),cid="content-id-123",d=4000,mtp=(15000),nor=("seg-2.m4v" "seg-3.m4v"),ot=v,sid="session-id-123",st=v,sta=s,su,v=2

Query-arg:


CMCD=bl%3D%280%29%2Cbr%3D%283000%3Bv%29%2Ccid%3D%22content-id-123%22%2Cd%3D4000%2Cmtp%3D%2815000%29%2Cnor%3D%28%22seg-2.m4v%22%20%22seg-3.m4v%22%29%2Cot%3Dv%2Csid%3D%22session-id-123%22%2Cst%3Dv%2Csta%3Ds%2Csu%2Cv%3D2

Headers:


CMCD-Request: bl=(0),mtp=(15000),nor=("seg-2.m4v" "seg-3.m4v"),sta=s,su
CMCD-Object: br=(3000;v),d=4000,ot=v
CMCD-Session: cid="content-id-123",sid="session-id-123",st=v,v=2

Request 4: Second Segment (Playing)

Fetching the second media segment. The player enters the playing state. 'nor' requests the next two segments (3 and 4). The startup time msd is reported.

Raw keys:


bl=(4000),br=(3000;v),cid="content-id-123",d=4000,msd=200,mtp=(15000),nor=("seg-3.m4v" "seg-4.m4v"),ot=v,sid="session-id-123",st=v,sta=p,v=2

Query-arg:


CMCD=bl%3D%284000%29%2Cbr%3D%283000%3Bv%29%2Ccid%3D%22content-id-123%22%2Cd%3D4000%2Cmsd%3D200%2Cmtp%3D%2815000%29%2Cnor%3D%28%22seg-3.m4v%22%20%22seg-4.m4v%22%29%2Cot%3Dv%2Csid%3D%22session-id-123%22%2Cst%3Dv%2Csta%3Dp%2Cv%3D2

Headers:


CMCD-Request: bl=(4000),mtp=(15000),nor=("seg-3.m4v" "seg-4.m4v"),sta=p
CMCD-Object: br=(3000;v),d=4000,ot=v
CMCD-Session: cid="content-id-123",msd=200,sid="session-id-123",st=v,v=2

Non-fatal error (recoverable).

Codec is not supported, but the player continues playing (sta=p).

Raw keys:


cid="content-id-123",ec=("CODEC_NOT_SUPPORTED"),sid="session-id-123",sta=p,v=2

Query-arg:


CMCD=cid%3D%22content-id-123%22%2Cec%3D%28%22CODEC_NOT_SUPPORTED%22%29%2Csid%3D%22session-id-123%22%2Csta%3Dp%2Cv%3D2

Headers:


CMCD-Request: sta=p
CMCD-Status: ec=("CODEC_NOT_SUPPORTED")
CMCD-Session: cid="content-id-123",sid="session-id-123",v=2

Fatal error.

Playback failed, player enters fatal error state (sta=f).

Raw keys:


cid="content-id-123",ec=("DRM_NOT_SUPPORTED" "PLAYBACK_FAILED"),sid="session-id-123",sta=f,v=2

Query-arg:


CMCD=cid%3D%22content-id-123%22%2Cec%3D%28%22DRM_NOT_SUPPORTED%22%20%22PLAYBACK_FAILED%22%29%2Csid%3D%22session-id-123%22%2Csta%3Df%2Cv%3D2

Headers:


CMCD-Request: sta=f
CMCD-Status: ec=("DRM_NOT_SUPPORTED" "PLAYBACK_FAILED")
CMCD-Session: cid="content-id-123",sid="session-id-123",v=2

Minimal Information, requesting video (ot=v) with zero buffer.

Raw keys:


bl=(0),bs,cid="content-id-123",ot=v,sid="session-id-123",sta=r,v=2

Query-arg:


CMCD=bl%3D%280%29%2Cbs%2Ccid%3D%22content-id-123%22%2Cot%3Dv%2Csid%3D%22session-id-123%22%2Csta%3Dr%2Cv%3D2

Headers:


CMCD-Request: bl=(0),sta=r
CMCD-Object: ot=v
CMCD-Status: bs
CMCD-Session: cid="content-id-123",sid="session-id-123",v=2

Similar request, but with more detailed Information.

Requesting video (ot=v). Buffer shows video is empty (0;v), but audio has buffer (2000;a).

Raw keys:


bl=(0;v 2000;a),bs,cid="content-id-123",ot=v,sid="session-id-123",sta=r,v=2

Query-arg:


CMCD=bl%3D%280%3Bv%202000%3Ba%29%2Cbs%2Ccid%3D%22content-id-123%22%2Cot%3Dv%2Csid%3D%22session-id-123%22%2Csta%3Dr%2Cv%3D2

Headers:


CMCD-Request: bl=(0;v 2000;a),sta=r
CMCD-Object: ot=v
CMCD-Status: bs
CMCD-Session: cid="content-id-123",sid="session-id-123",v=2

Background ad content request while main content is playing.

Primary player:

Raw keys:


cid="movie-123",ot=v,sid="session-common-1",v=2

Query-arg:


CMCD=cid%3D%22movie-123%22%2Cot%3Dv%2Csid%3D%22session-common-1%22%2Cv%3D2

Headers:


CMCD-Object: ot=v
CMCD-Session: cid="movie-123",sid="session-common-1",v=2

Ad player

Raw keys:


cid="ad-555",nr,ot=v,sid="session-common-1",v=2

Query-arg:


CMCD=cid%3D%22ad-555%22%2Cnr%2Cot%3Dv%2Csid%3D%22session-common-1%22%2Cv%3D2

Headers:


CMCD-Object: ot=v
CMCD-Status: nr
CMCD-Session: cid="ad-555",sid="session-common-1",v=2

Ad rendered while primary content is not shown (same Session ID, different Content ID):

Primary player

Raw keys:


cid="movie-123",nr,ot=v,sid="session-common-1",v=2

Query-arg:


CMCD=cid%3D%22movie-123%22%2Cnr%2Cot%3Dv%2Csid%3D%22session-common-1%22%2Cv%3D2

Headers:


CMCD-Object: ot=v
CMCD-Status: nr
CMCD-Session: cid="movie-123",sid="session-common-1",v=2

Ad player:

Raw keys:


cid="ad-555",ot=v,sid="session-common-1",v=2

Query-arg:


CMCD=cid%3D%22ad-555%22%2Cot%3Dv%2Csid%3D%22session-common-1%22%2Cv%3D2

Headers:


CMCD-Object: ot=v
CMCD-Session: cid="ad-555",sid="session-common-1",v=2

Raw keys:


bg,bl=(2100;v 1800;a),br=(3000;v 164;a),bs,bsa=(3;v),bsd=(1200;v 100;a),bsda=(4150;v 300;a),cid="content-id-123",cs="g48djn236sk2",d=4000,dfa=32,dl=1000,ec=("2001"),lb=(500;v 32;a),ltc=13500,msd=1700,mtp=(15000;v 6000;a),nor=("next-seg.mp4"),nr,ot=v,pb=(2000;v 164;a),pr=1.1,pt=632782,rtp=12000,sf=d,sid="session-id-123",sn=129,st=l,sta=p,su,tb=(6000;v 350;a),tbl=(2000;v 2000;a),tpb=(5000;v 164;a),v=2

Query-arg:


CMCD=bg%2Cbl%3D%282100%3Bv%201800%3Ba%29%2Cbr%3D%283000%3Bv%20164%3Ba%29%2Cbs%2Cbsa%3D%283%3Bv%29%2Cbsd%3D%281200%3Bv%20100%3Ba%29%2Cbsda%3D%284150%3Bv%20300%3Ba%29%2Ccid%3D%22content-id-123%22%2Ccs%3D%22g48djn236sk2%22%2Cd%3D4000%2Cdfa%3D32%2Cdl%3D1000%2Cec%3D%28%222001%22%29%2Clb%3D%28500%3Bv%2032%3Ba%29%2Cltc%3D13500%2Cmsd%3D1700%2Cmtp%3D%2815000%3Bv%206000%3Ba%29%2Cnor%3D%28%22next-seg.mp4%22%29%2Cnr%2Cot%3Dv%2Cpb%3D%282000%3Bv%20164%3Ba%29%2Cpr%3D1.1%2Cpt%3D632782%2Crtp%3D12000%2Csf%3Dd%2Csid%3D%22session-id-123%22%2Csn%3D129%2Cst%3Dl%2Csta%3Dp%2Csu%2Ctb%3D%286000%3Bv%20350%3Ba%29%2Ctbl%3D%282000%3Bv%202000%3Ba%29%2Ctpb%3D%285000%3Bv%20164%3Ba%29%2Cv%3D2

Headers:


CMCD-Request: bl=(2100;v 1800;a),cs="g48djn236sk2",dfa=32,dl=1000,ltc=13500,mtp=(15000;v 6000;a),nor=("next-seg.mp4"),pb=(2000;v 164;a),sn=129,sta=p,su,tbl=(2000;v 2000;a)
CMCD-Object: br=(3000;v 164;a),d=4000,lb=(500;v 32;a),ot=v,tb=(6000;v 350;a),tpb=(5000;v 164;a)
CMCD-Status: bg,bs,bsa=(3;v),bsd=(1200;v 100;a),bsda=(4150;v 300;a),ec=("2001"),nr,pr=1.1,pt=632782,rtp=12000
CMCD-Session: cid="content-id-123",msd=1700,sf=d,sid="session-id-123",st=l,v=2

Data is sent always as a HTTP POST body

POST body:


e=t,ts=1764752400000,v=2

This example shows a hypothetical sequence of individual time interval reports for an active player.

POST body:


bl=(0),cid="content-id-123",e=t,h="example.com",pt=0,sid="session-id-123",sn=1,sta=s,su,ts=1764752400000,v=2

POST body:


bl=(6000),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),msd=812,mtp=(87000;v 49000;a),pb=(4200;v 256;a),pt=29188,sf=d,sid="session-id-123",sn=2,st=v,sta=p,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752430000,v=2

POST body:


bl=(3200),br=(4200;v 256;a),bs,bsd=(720;v),cid="content-id-123",e=t,ec=("MEDIA_ERR_NETWORK"),h="example.com",lb=(523;v 64;a),mtp=(89000;v 52000;a),pb=(4200;v 256;a),pt=59188,sf=d,sid="session-id-123",sn=3,st=v,sta=p,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752460000,v=2

POST body:


bl=(6000),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(81000;v 55000;a),pb=(4200;v 256;a),pt=89188,sf=d,sid="session-id-123",sn=4,st=v,sta=p,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752490000,v=2

POST body:


bl=(0),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(82000;v 55000;a),pb=(4200;v 256;a),pr=0,pt=111000, sf=d, sid="session-id-123",sn=5,st=v,sta=e,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752520000,v=2

POST body:


bl=(0),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(82000;v 52000;a),pb=(4200;v 256;a),pr=0,pt=111000, sf=d, sid="session-id-123",sn=6,st=v,sta=e,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752550000,v=2

bl=(0),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(82000;v 52000;a),pb=(4200;v 256;a),pr=0,pt=111000, sf=d, sid="session-id-123",sn=7,st=v,sta=e,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752580000,v=2

A player makes a report after successfully retrieving a video segment.

POST body:


cid="bbb",cmsdd="ZXRwPTEyNTAwO3J0dD0zNTttYj02MDAwO3JkPTIwMA==",cmsds="c2lkPSI5YTNiLTIxY2QiO2JyPTQ1MDA7ZD00MDAwO290PXY7c3Q9dg==",e=rr,nor=("video/segment-6.m4v"),ot=v,rc=200,sid="session1",ts=1763657019723,ttfb=180,ttlb=200,url="video/segment-5.m4v",v=2

POST body:


cid="content-id-123",e=e,ec=("CODEC_NOT_SUPPORTED"),sid="session-id-123",ts=1764269150,v=2

First event: Entering Rebuffering State.

POST body:


cid="content-id-123",e=ps,sid="session-id-123",sta=r,ts=1764269150,v=2

Second event: Exiting Rebuffering with Buffer Starvation Duration.

POST body:


bs,bsd=(1500),cid="content-id-123",e=ps,sid="session-id-123",sta=p,ts=1764269150,v=2

Buffering level (bl) is typically 0 or unknown during a scrub/seek.

POST body:


bl=(0),cid="content-id-123",e=ps,pt=30000,sid="session-id-123",sta=k,ts=1764269150,v=2

POST body:


cid="ad-content-555",e=sk,sid="session-id-123",ts=1764269150,v=2

Ad Break Start (using main content ID context)

POST body:


cid="movie-123",e=abs,nr,sid="session-id-123",ts=1764269150,v=2

Ad Start (switching to Ad content ID)

POST body:


cid="ad-001",e=as,sid="session-id-123",ts=1764269150,v=2

Ad End (Ad content ID)

POST body:


cid="ad-001",e=ae,nr,sid="session-id-123",ts=1764269170,v=2

Ad Break End (Returning to main content ID)

POST body:


cid="movie-123",e=abe,sid="session-id-123",ts=1764269170,v=2

POST body:


bg,bl=(2100;v 1800;a),br=(3000;v 164;a),bs,bsa=(3;v 1;a),bsd=(1200;v 100;a),bsda=(4150;v 350;a),cid="content-id-123",cmsdd="IkNETkItM2FrMSI7ZXRwPTk2O3J0dD04",cmsds="b3Q9dixzZj1oLHN0PXYsZD01MDAwLGJyPTIwMDA=",cs="g48djn236sk2",d=4000,dfa=32,dl=1000,e=rr,ec=("2001"),h="example.com",lb=(500;v 32;a) ,ltc=13500,msd=1700, mtp=(15000;v 6000;a), nor=("next-seg.mp4"),nr,ot=v, pb=(2000;v 164;a),pr=1.1, pt=632782,rc=200,rtp=12000,sf=d,sid="session-id-123",smrt="KCk7bj1PcmlnaW5BO3N5biwgKCk7bj1PcmlnaW5CO3Q9MTcwMDAwMDAwMTAwNjtmYj0zLCAoIDE7dD0xNzAwMDAwMDAxMDA1O2ZiPTEzO2xiPTE4IDA7dD0xNzAwMDAwMDAwMDAzO2M9MTAwMCApO249SW50ZXJtZWRpYXJ5O3Q9MTcwMDAwMDAwMDAwMjtmYj0xMDIy",sn=129,st=l,sta=p,su,tb=(6000;v 350;a),tbl=(2000;v 2000;a),tpb=(5000;v 164;a),ts=1764677101751, ttfb=512,ttfbb=632,ttlb=4018,url="https://example.com/videosegment32.mp4",v=2

An example showing all the events of 8.2.1 sent in a single batch POST (any white space is an artifact of document formatting and would not be included in the batch payload. \n is used to represent the LF character representing a new line).

POST body:


bl=(0),cid="content-id-123",e=t,h="example.com",pt=0,sid="session-id-123",sn=1,sta=s,su,ts=1764752400000,v=2\nbl=(6000),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),msd=812,mtp=(87000;v 49000;a),pb=(4200;v 256;a),pt=29188,sf=d,sid="session-id-123",sn=2,st=v,sta=p,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752430000,v=2\nbl=(3200),br=(4200;v 256;a),bs,bsd=(720;v),cid="content-id-123",e=t,ec=("MEDIA_ERR_NETWORK"),h="example.com",lb=(523;v 64;a),mtp=(89000;v 52000;a),pb=(4200;v 256;a),pt=59188,sf=d,sid="session-id-123",sn=3,st=v,sta=p,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752460000,v=2\nbl=(6000),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(81000;v 55000;a),pb=(4200;v 256;a),pt=89188,sf=d,sid="session-id-123",sn=4,st=v,sta=p,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752490000,v=2\nbl=(0),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(82000;v 55000;a),pb=(4200;v 256;a),pr=0,pt=111000, sf=d, sid="session-id-123",sn=5,st=v,sta=e,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752520000,v=2\nbl=(0),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(82000;v 52000;a),pb=(4200;v 256;a),pr=0,pt=111000, sf=d, sid="session-id-123",sn=6,st=v,sta=e,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752550000,v=2\nbl=(0),br=(4200;v 256;a),cid="content-id-123",e=t,h="example.com",lb=(523;v 64;a),mtp=(82000;v 52000;a),pb=(4200;v 256;a),pr=0,pt=111000, sf=d, sid="session-id-123",sn=7,st=v,sta=e,tb=(4200;v 256;a),tpb=(4200;v 256;a),ts=1764752580000,v=2

The following documents contain provisions that, through reference in this text, constitute normative provisions of this specification. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this specification are encouraged to investigate the possibility of applying the most recent editions of the documents listed here.

IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, https://tools.ietf.org/html/rfc2119.
IETF RFC 7541, HPACK Header compression, https://tools.ietf.org/html/rfc7541.
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax,https://tools.ietf.org/html/rfc3986.
WHATWG URL Living Standard, Section 5, URL Encoding. Accessed 9 February 2026. https://url.spec.whatwg.org/#application/x-www-form-urlencoded.
IETF RFC 8941, Structured Field Values for HTTP,https://datatracker.ietf.org/doc/html/rfc8941.
IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace, https://tools.ietf.org/html/rfc4122.
IETF RFC 6302, Logging Recommendations for Internet-Facing Servers,https://tools.ietf.org/html/rfc6302.
IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 8.1.4, Vary header, http://tools.ietf.org/html/rfc7231#section-8.1.4.
ISO/IEC 23009-1, Dynamic adaptive streaming over HTTP (DASH), https://www.iso.org/standard/83314.html.
IETF RFC 8216, HTTP Live Streaming, https://datatracker.ietf.org/doc/html/rfc8216.
HESP High Efficiency Streaming Protocol [draft], https://datatracker.ietf.org/doc/draft-theo-hesp/.
Microsoft Smooth Streaming Protocol (2018), https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sstr.
IETF RFC4648, The Base16, Base32, and Base64 Data Encodings https://datatracker.ietf.org/doc/html/rfc4648.
Video Ad Serving Template (VAST), https://iabtechlab.com/standards/vast/.
CTA-5006, Common Media Server Data (CMSD), https://www.cta.tech/standards.
CTA-5010, Request Tracing, https://www.cta.tech/standards.
IEEE Std 1003.1-2017 (POSIX.1-2017), Section 4.16: Seconds Since the Epoch, https://pubs.opengroup.org/onlinepubs/9699919799/.
IETF RFC 3629, UTF-8, a transformation format of ISO 10646, https://datatracker.ietf.org/doc/html/rfc3629.
IETF RFC 9204, QPACK: Field Compression for HTTP/3, https://datatracker.ietf.org/doc/html/rfc9204.

Web Application Video EcosystemCommon Media Client Data (CTA-5004-A)

Abstract

1. Introduction

2. Reporting Modes (When We Send Data)

2.1 Request mode

2.2 Event mode

3. Data Transmission Modes (How We Send Data)

3.1 Header field definition

3.2 Query argument definition

3.3 Body definition

4. Data Payload Definition (What Data to Send)

4.1 Payload definition for Headers and Query Argument transmission

4.2 Payload definition for batch transmission

4.3 Reserved keys

Aggregate encoded bitrate

Buffer length

Backgrounded

Encoded bitrate

Buffer starvation

Buffer Starvation Absolute

Buffer Starvation duration

Buffer Starvation Duration Absolute

Custom Event Name

Content ID

CMSD Dynamic Header

CMSD Static Header

Content Signature

Object duration

Dropped Frames Absolute

Deadline

Event

Player Error Code

Hostname

Lowest aggregated encoded bitrate

Lowest encoded bitrate

Live stream latency

Media Start Delay

Measured throughput

Next object request

Non rendered

Object type

Playhead bitrate

Playback rate

Playhead time

Response code

Requested maximum throughput

Streaming format

Session ID

SMRT-Data Header

Sequence Number

Stream type

State

Startup

Top aggregated encoded bitrate

Top encoded bitrate

Target Buffer length

Top playable bitrate

Timestamp

Time to first byte

Time to first body byte

Time to last byte

Request URL

Version

5. Player Processing Requirements

6. Server Processing Requirements

7. Security and Privacy Considerations

7.1 Threat environment

7.2 Threats to the server

7.3 Threats to the player

7.4 Specific mitigations

8. Examples

8.1 Request mode

8.1.1 Standard video segment request

8.1.2 Standard audio segment request

8.1.3 Standard request showing minimal fields

8.1.4 Standard sequence of events in happy day start-up scenario

8.1.5 Error scenario

8.1.6 Rebuffering example

8.1.7 Multiple players with sequential ads

8.1.8 Complex example with many Request Mode keys

Web Application Video Ecosystem
Common Media Client Data (CTA-5004-A)