NinSuna illustrating W3C Media Fragments delivery

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.

Segments via the HTTP Range header

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.

  1. Byte Range requests

    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}

  2. Time Range requests

    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.

  3. Time and Track Range Redirect requests

    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.

Screen cast showing the retrieval of Media Fragments from NinSuna

Thanks to Silvia Pfeiffer for the creation of this screen cast

Segments via query parameter

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:

Test the delivery of Media Fragments using the query parameter here

 

Combining the query parameter and the HTTP range header

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