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