Available

CMCD decoder

Common Media Client Data is what a video player tells the delivery network about itself on every segment request. Paste a payload, a whole URL from a log line, or a block of headers. It decodes in this tab, and nothing is uploaded.

Encoded

read as raw · version 1 (assumed)

Nothing is uploaded. The parser runs in this tab, and the payload lives in the link fragment, which browsers never send to a server.

Decoded

10 keys

CMCD-Requestchanges with every request

bl
2130021.3 sBuffer length
mtp
2540025.40 MbpsMeasured throughput

CMCD-Objectchanges with the object requested

br
32003.20 MbpsEncoded bitrate
d
40004.00 sObject duration
ot
vvideo onlyObject type
tb
60006.00 MbpsTop encoded bitrate

CMCD-Sessionfixed for the session

cid
"movie-42"Content ID
sf
hHLSStreaming format
sid
"6e2fb550-c457-11e9-bb97"Session ID
st
vvideo on demandStream type

The same payload, sent the other ways

query argument
CMCD=bl%3D21300%2Cbr%3D3200%2Ccid%3D%22movie-42%22%2Cd%3D4000%2Cmtp%3D25400%2Cot%3Dv%2Csf%3Dh%2Csid%3D%226e2fb550-c457-11e9-bb97%22%2Cst%3Dv%2Ctb%3D6000
CMCD-Request
CMCD-Request: bl=21300,mtp=25400
CMCD-Object
CMCD-Object: br=3200,d=4000,ot=v,tb=6000
CMCD-Session
CMCD-Session: cid="movie-42",sf=h,sid="6e2fb550-c457-11e9-bb97",st=v

What is CMCD?

Common Media Client Data, standardised as CTA-5004. A video player attaches a short list of key and value pairs to every media request it makes, so the delivery network sees the player's own state next to the request it served.

Where does CMCD data end up?

In the access log of whatever served the request. In query argument mode it lands in the query field of a CloudFront or Fastly log with no configuration. In header mode the delivery network has to be told to log the four CMCD headers.

What changed in CMCD version 2?

Version 2 changed the shape of the most common keys, not just the key list. Encoded bitrate went from br=3200 to an inner list such as br=(5000;v 320;a), with one value per object type, and the list form is required even for a single value. Four more version 1 keys moved the same way: buffer length, measured throughput, next object request and top bitrate. The next range request key was removed, and the version key became required.

Does this tool upload my logs?

No. The parser runs in your browser, and the payload is kept in the link fragment, which a browser never sends to a server.

Every key, and what it means

All 50 reserved keys across both versions, taken from the published standard. Keys are grouped by the header that carries them, which the specification chose by how often the value changes.

CMCD-Requestchanges with every request13 keys

blBuffer lengthVersion 1 and 2, and version 2 changed its shape

inner list of integers, milliseconds, one per object type (version 1: integer, milliseconds)

The buffer length associated with the media object being requested. This value SHOULD be rounded to the nearest 100 ms.

csContent SignatureNew in version 2

string, in double quotes

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.

dfaDropped Frames AbsoluteNew in version 2

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.

dlDeadlineVersion 1 and 2

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.

ltcLive stream latencyNew in version 2

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.

mtpMeasured throughputVersion 1 and 2, and version 2 changed its shape

inner list of integers, kbps, one per object type (version 1: integer, kbps)

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.

norNext object requestVersion 1 and 2, and version 2 changed its shape

inner list of strings, one per object type (version 1: string, in double quotes)

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.

nrrNext range requestVersion 1 only, removed in version 2

string, in double quotes

The byte range of the next request, expressed as "<start>-<end>". Removed in version 2.

pbPlayhead bitrateNew in version 2

inner list of integers, kbps, one per object type

The encoded bitrate of the media object(s) being shown to the end user.

snSequence NumberNew in version 2

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.

staStateNew in version 2

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.

suStartupVersion 1 and 2

boolean, written as a bare key when true and omitted when false

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.

tblTarget Buffer lengthNew in version 2

inner list of integers, milliseconds, one per object type

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.

CMCD-Objectchanges with the object requested9 keys

abAggregate encoded bitrateNew in version 2

inner list of integers, kbps, one per object type

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.

brEncoded bitrateVersion 1 and 2, and version 2 changed its shape

inner list of integers, kbps, one per object type (version 1: integer, kbps)

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.

dObject durationVersion 1 and 2

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’.

labLowest aggregated encoded bitrateNew in version 2

inner list of integers, kbps, one per object type

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.

lbLowest encoded bitrateNew in version 2

inner list of integers, kbps, one per object type

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.

otObject typeVersion 1 and 2

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.

tabTop aggregated encoded bitrateNew in version 2

inner list of integers, kbps, one per object type

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.

tbTop encoded bitrateVersion 1 and 2, and version 2 changed its shape

inner list of integers, kbps, one per object type (version 1: integer, kbps)

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.

tpbTop playable bitrateNew in version 2

inner list of integers, kbps, one per object type

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’.

CMCD-Statuschanges rarely10 keys

bgBackgroundedNew in version 2

boolean, written as a bare key when true and omitted when false

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.

bsBuffer starvationVersion 1 and 2

boolean, written as a bare key when true and omitted when false

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.

bsaBuffer Starvation AbsoluteNew in version 2

inner list of integers, one per object type

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.

bsdBuffer Starvation durationNew in version 2

inner list of integers, milliseconds, one per object type

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.

bsdaBuffer Starvation Duration AbsoluteNew in version 2

inner list of integers, milliseconds, one per object type

An absolute count of buffer starvation duration since session initiation. Token identifier MAY be omitted if the cause of the rebuffering is unknown.

ecPlayer Error CodeNew in version 2

inner list of strings, one per object type

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.

nrNon renderedNew in version 2

boolean, written as a bare key when true and omitted when false

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.

prPlayback rateVersion 1 and 2

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.

ptPlayhead timeNew in version 2

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].

rtpRequested maximum throughputVersion 1 and 2

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.

CMCD-Sessionfixed for the session6 keys

cidContent IDVersion 1 and 2

string, in double quotes

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.

msdMedia Start DelayNew in version 2

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.

sfStreaming formatVersion 1 and 2

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

sidSession IDVersion 1 and 2

string, in double quotes

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].

stStream typeVersion 1 and 2

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

vVersionVersion 1 and 2

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.

Event mode onlysent to a collector, never on a media request12 keys

cenCustom Event NameNew in version 2

string, in double quotes

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.

cmsddCMSD Dynamic HeaderNew in version 2

string, in double quotes

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).

cmsdsCMSD Static HeaderNew in version 2

string, in double quotes

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).

eEventNew in version 2

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.

hHostnameNew in version 2

string, in double quotes

A string identifying the current hostname from which the player is retrieving content. Maximum length is 128 characters.

rcResponse codeNew in version 2

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).

smrtSMRT-Data HeaderNew in version 2

string, in double quotes

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).

tsTimestampNew in version 2

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.

ttfbTime to first byteNew in version 2

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).

ttfbbTime to first body byteNew in version 2

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).

ttlbTime to last byteNew in version 2

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).

urlRequest URLNew in version 2

string, in double quotes

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).

Use it in your own code

This page is a thin layer over an open source package. It has no dependencies and runs in a browser, in Node and in a worker.

npm install cmcd-parser

import { parse } from 'cmcd-parser'
parse('br=3200,ot=v,sid="abc"').data.br  // { kind: 'integer', value: 3200 }

Source and issues on GitHub. Prior art worth knowing: cmcd-validator by Montevideo Tech, which checks a player's implementation as it runs.

Built from Scratch

A newsletter on video streaming infrastructure. No spam, unsubscribe anytime.