Common Media Server Data

Origin CMSD is an experimental project for testing CTA-WAVE's Common Media Server Data (CMSD) proposal.

CMSD's proposal aims to generate a specification on how every media server (intermediate and origin) can communicate data with each media object response and have it received and processed consistently by every intermediate server and player. It is expected that using CMSD's proposal will increase efficiency and performance in distributing media workflows. Consequently, improve the quality of experience (QoE) for end-users.

A good overview here cmsd.pdf or slides.

CMSD key/value pairs

The following table shows the current key-value pairs used in CMSD proposal.

Key number Description Key Name Header name Type & Unit Value definition Origin or Proxy Comment
Timestamp t CMSD-Dynamic Integer [milliseconds] (See CMSD ref.) Proxy This value seems to be present by Unified Origin with the Header Last-Modified. In this case Last-Modified is not in milliseconds but a proxy in front can potentially do the conversion to millisecond epoch time.
Entity identifier n CMSD-Dynamic & CMSD-Static String (See CMSD ref.) Origin & Proxy Unified Origin provides the header X-USP which identifies the version. However, to be CMSD complaint and be able to track the Origin that wrote the CMSD Header the must be a UUID generated by the server (proxy and Origin)
Estimated Throughput etp CMSD-Dynamic Integer [kilobit per second] (See CMSD ref.) Origin & Proxy This value is still not well defined in CMSD for me. Having an implementation may help to decide who (intermediate or origin) writes this value. Also, there are multiple ways to calculate this value, so the objective is to use it as a hint between intermediate servers.
RTT rtt CMSD-Dynamic Integer [milliseconds] The maximum bitrate value that the player SHOULD play in its Adaptive Bit Rate (ABR) ladder. If the player is playing a bitrate higher than this value, it SHOULD immediately switch to a bitrate lower than this value. Proxy  
Max suggested bitrate mb CMSD-Dynamic Integer [kilobit per second] (See CMSD ref.) Origin  
Next object no CMSD-Static String (See CMSD ref.) Origin Unified Origin already provides this information by the Link HTTP Header
Next range nr CMSD-Static String of the form “<range-start>-<range-end>” (See CMSD ref.) Proxy We suggest to customers not to generate byte-range requests which can generate an overhead at Origin.
Object type ot CMSD-Static Token - one of [m,a,v,av,i,c,tt,k,o]

The media type of the current object being returned:

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 returned is unknown, then this key MUST NOT be used.

 Origin  
Stream type st CMSD-Dynamic Token - one of [v,l]

v = all segments are available – e.g., VOD

l = segments become available over time – e.g., LIVE

 Origin  
Streaming format sf CMSD-Static Token - one of [d,h,s,o]

The streaming format that defines the current response:

d = MPEG DASH h = HTTP Live Streaming (HLS) s = Smooth Streaming o = other

If the streaming format being returned is unknown, then this key MUST NOT be used.

 Origin  
Publish time pt CMSD-Static Integer The wallclock time at which the first byte of this object became available for successful request. The time is expressed as integer milliseconds since the Unix epoch i.e the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Origin This value seems to be present by Unified Origin with the Header Last-Modified. In this case Last-Modified is not in milliseconds but a proxy in front can potentially do the conversion to millisecond epoch time.
Held time ht CMSD-Dynamic Integer The number of milliseconds that this response was held back before returning. This is applicable to blocking responses under LL-HLS. Proxy but also Origin? Perhaps if Origin generates this value there may be a way to tell the intermedia server that some backend services are failing and it must switch to a second origin. Perhaps worth asking Arjen about this.
Served from cache sc CMSD-Dynamic Boolean (See CMSD ref.) Proxy  
CPU load cpu CMSD-Dynamic Token - one of [l,m,h] (See CMSD ref.) Origin & Proxy I am not fully sure if this value would be beneficial to an intermediate server or a client. There has been a lot of discussions about the security vulnerabilities by providing this CPU value.
Bitrate cached at the edge TBD TBD TBD TBD Proxy  
Object duration d CMSD-Static Integer [milliseconds] (See CMSD ref.) Origin but also a Proxy should be capable  
Encoded bitrate br CMSD-Static Integer [Kilobit per second] (See CMSD ref.) Origin but also a Proxy should be capable  
Init segments is CMSD-Static String Relative path to the init segments referenced inside the playlist or manifest. Each init segment path is separated by a semi-colon and concatenated into a single String. Origin A Proxy could also do this by requesting the server Manifest and generating the Init segment URI
Startup su CMSD-Static Boolean (See CMSD ref.) ?  
Request ID rid CMSD-Static String (See CMSD ref.) Origin & Proxy This can be achieved by using Apache module mod_unique_id.so as follow RequestHeader setifempty X-Request-ID %{UNIQUE_ID}e
Session ID sid CMSD-Static String (See CMSD ref.) Origin & Proxy A tie to the CMCD Session ID request which spawned this response. This common attribute between CMCD and CMSD provides a join across both data sets.
Version v CMSD-Static Integer (See CMSD ref.) Origin & Proxy The version number of the CMSD specification used.

Example configurations

Current open source project supporting this proposal can be found in the following github repository.