Both the time and track fragment axes are supported by our media delivery platform. Media segments can be requested by using the query parameter and/or through the HTTP range header. It is important to notice that no transcoding is applied to create the media segments; more specifically, all segments are extracted from the original media resource.
When media segments are expressed using fragment identifiers (i.e., using the #), the user agent needs to interpret the fragment identifier. There are three possible scenarios defined in the Media Fragments URI specification, which are all supported by our platform. Note that spatial fragments are typically not requested but interpreted at client-side only.
If the user agent is able to perform the mapping of the media fragment to one or more byte ranges, media fragments can be requested using HTTP byte range requests. Hence, in this scenario, an HTTP 1.1-compliant Web server supporting byte range requests is enough to serve media fragments (Apache is one such example server). A fictive examples:
GET /Media/example.webm HTTP/1.1 Host: ninsuna.elis.ugent.be Accept: video/* Range: bytes=19147-22880 HTTP/1.1 206 Partial Content Accept-Ranges: bytes, t Content-Length: 3743 Content-Type: video/webm Content-Range: bytes 19147-22880/4055466 {binary data}
When a user agent is not able to do the fragment-to-byte mapping by itself, this mapping should be done at a media fragment aware server. Therefore, the HTTP Range header is extended with additional units (other than bytes) to communicate the fragment information to the server. The following fictive example illustrates a temporal fragment request through the HTTP Range header:
GET /Media/example.webm HTTP/1.1 Host: ninsuna.elis.ugent.be Accept: video/* Range: t:npt=10-20 HTTP/1.1 206 Partial Content Accept-Ranges: bytes, t Content-Length: 802370 Content-Type: video/webm Content-Range: bytes 1264525-2066894/4055466 Content-Range-Mapping: { t:npt 10.0-20.0/0-38.3 } = { bytes 1264525-2066894/4055466 } {binary data}
It is important to notice that the bytes returned are not a playable resource since there is no header information available. If the user agent needs the header, the HTTP Range request can be extended as follows:
GET /Media/example.webm HTTP/1.1 Host: ninsuna.elis.ugent.be Accept: video/* Range: t:npt=10-20;include-setup HTTP/1.1 206 Partial Content Accept-Ranges: bytes, t Content-Length: 804020 Content-Type: multipart/byteranges;boundary=End Content-Range-Mapping: { t:npt 10.0-20.0/0-38.3;include-setup } = { bytes 0-1650,1264525-2066894/4055466 } --End Content-Type: video/webm Content-Range: bytes 0-1650/4055466 {binary data} --End Content-Type: video/webm Content-Range: bytes 1264525-2066894/4055466 {binary data}
When a media fragment corresponds to multiple byte ranges, a multipart byteranges response is returned. Requesting track fragments is similar to the temporal fragment examples.
Existing web proxies have no means of caching the media fragment requests of scenario 2, as they only understand byte ranges. Thus, when we want to use existing web proxies to cache media fragments, they should be requested using byte ranges (i.e., scenario 1). However, when a user agent is not able to do the fragment-to-byte mapping by itself, we need a mechanism to obtain the corresponding byte ranges from the server. Therefore, in this third scenario, the user agent uses the extended HTTP Range header (with time and track units) to request the fragment, but gets a redirect response indicating the corresponding byte ranges. An example:
GET /Media/example.webm HTTP/1.1 Host: ninsuna.elis.ugent.be Accept: video/* Range: t:npt=10-20 Accept-Range-Redirect: bytes HTTP/1.1 307 Temporary Redirect Accept-Ranges: bytes, t Content-Length: 0 Content-Type: video/webm Content-Range-Mapping: { t:npt 10.0-20.0/0-38.3 } = { bytes 1264525-2066894/4055466 } Location: http://ninsuna.elis.ugent.be/Media/example.webm Range-Redirect: bytes 1264525-2066894 Vary: Accept-Range-Redirect
Validate your media fragment URIs now with our W3C Media Fragments validation service.
Thanks to Silvia Pfeiffer for the creation of this screen cast
When media segments are requested using the query parameter, the URI syntax as specified by the MFWG is fully supported. Note that spatial and named segments will be ignored by the server. A number of working examples:
The two ways of requesting media segments can also be combined. An example:
GET /Media/example.webm?t=20,35 HTTP/1.1 Host: ninsuna.elis.ugent.be Range: t:npt=10-20 HTTP/1.1 206 Partial Content Accept-Ranges: bytes, t, track, id Content-Range: bytes 1144646-1689873/1689874 Content-Range-Mapping: { t:npt 10.0-15.2/15.2 } = { bytes 1144646-1689873/1689874 } Content-Type: video/webm Content-Length: 545228 {binary data}
As can be seen in the above example, the media segment resulting from the query parameter has a length of 15.22609977324263 seconds. Requesting a range from 10 to 20 seconds from this media segment results in the bytes corresponding to the time range 10.033333333333333-15.22609977324263. Note that the context of this time is the parent resource (i.e., example.webm?t=20,35).