Bringing IPTV to users requires a managed network: working multicast and constant bandwith. This is something hard to achieve outside of telco networks or local area networks. This is the reason for the emerging of Over-The-
Top TV (OTT) which enables providers to deliver live TV and VOD through the Internet. Any connected device
can then watch TV: PC, connected TV, smartphones, tablets, ... There are various protocols to deliver OTT:
• Apple HTTP Live Streaming (HLS) • Microsoft Smooth Streaming
• Adobe HTTP Dynamic Streaming (HDS) • MPEG DASH
Principles
The Over-The-Top formats have some common principles: • use HTTP over TCP
• adaptive streaming
• short video fragments (chunks) downloaded via independent HTTP requests • streaming enabled file formats (MPEG2-TS or MPEG4-part12 plus extensions)
The streaming server hosts a set of chunks with different bitrates (usually video compressed using various resolutions). It also hosts a playlist listing the URL of the chunks.
The client downloads the playlist, and then downloads the first chunk of a quality. If it is not able to download it fast enough (download time superior to the duration of the chunk), it usually switches to a lower quality. If the download time is largely inferior to the duration of the chunk, it may switch to highest quality. This behaviour depends of the client.
Figure 53: Over-The-Top streaming example
In case of live, the playlist must be refreshed regularly. A playlist provides an available live window of a fixed duration, usually 30 seconds. In case of VOD, a single playlist will list all the chunks for a single movie.
In the example Figure 53, the client started by downloading the playlist, then downloaded the first chunk of the highest quality (1.5 Mbps). Since the download time was too long, it switched to the lower quality (1 Mbps) and then switched again to the lowest (0.5 Mbps)
Pros:
• it is unicast, so there is no multicast routing issue, which means it can be used over an uncontrolled network, especially over the Internet and wifi.
• contrary to what happens with RTSP and unicast UDP streaming, there is one single TCP connection for both control and download. This avoid many firewall and NAT issues
• the client can adapt the bitrate and can still see the video even with a bad connection • the protocols allow video in "live" and "VOD" mode
• HTTP is a well-known and powerful protocol. The ecosystem is strong. There are some good solutions to cache it. HTTPS can be used for security
Cons:
• it is unicast, so there is no way to "broadcast" the live TV. Each client will create a new TCP connection. This requires powerful servers and smart caching
• you have to encode or re-encode each stream several times to have multi-bitrates • not easy to do fast forward with adaptive streaming.
To understand the various OTT formats, we will first have a deeper look at two standards that are used by many OTT protocols: HTTP and the MPEG4 file formats. We will then review the various OTT protocols.
HTTP
Hyper Text Transfer Protocol (HTTP) is a layer 7 (application) defined by the IETF.
It is a request/answer protocol: the client makes a request over an Internet resource (URL), the server answers with a status code and the requested file if needed. HTTP requires a connected transport protocol (TCP). See TCP. The default TCP port for HTTP is 80.
HTTP is very similar to RTSP. In fact RTSP was inspired by HTTP.
Requests
The requests are of two types:
GET download a file from a URL POST send a file, data, to a URL
Other kinds exist but are rarely used (HEAD, PUT ...). Requests begin by a request line:
• the request type: GET or POST • the requested path: /path/to/file.ts
• the version of the HTTP protocol: HTTP/1.0 or HTTP/1.1 and then:
• some headers, one per line. Example: User-Agent: Chrome • an empty line
• and file/data if this is a POST request. Can be of any type (text, binary). Example This is a 33 bytes long
Answers
Answers are formed of a status line:
• the version of the HTTP protocol: HTTP/1.0 or HTTP/1.1 • a 3-digits status code: 200, 404, 500 ...
• a status message: OK, File Not Found, Internal Server Error and then
• some headers, one per line: Content-Length, Content-Type ... • an empty line
• file/data. Can be of any type (text, binary). Example: This is a 33 bytes long text file The status codes are sorted by the first digit:
• 1XX for temporary answers • 2XX for OK status
• 3XX for redirections • 4XX for invalid requests • 5XX for server errors
Headers
Find in Figure 54 some useful HTTP headers, used in both requests and answers
Header Meaning Example
Transfer-Encoding Indicates that the file is split in chunks that will be sent in several requests
Transfer-Encoding: chunked
Content-Length If omitted or 0, no file is included. If not 0, tells the size in bytes of the file carried.
Content-Length: 59
Content-Type Tells the file type (known as mime-type) Content-Type: text/html
User-Agent A description of the client User-Agent: Chrome 3.1
Server A description of the server Server: Apache2
Cache-Control for dynamic content, tells the server how long it can keep a copy of the file
Cache-Control: None
Authorization Gives an encoded user and password for authen- tication
Authorization: Basic QWxhZ==
Range Allows a client to request only a part of a content Range: bytes=500-600
Figure 54: Some useful HTTP headers
Example Request: GET /live/disk1/mezz/DASH/dash/DASH-audio_eng=96000-video=800000-4991.ts HTTP/1.1\r\n Accept-Encoding: identity\r\n Host: 172.27.115.90\r\n Connection: close\r\n User-Agent: Python-urllib/2.6\r\n \r\n Answer:
Accept-Ranges: bytes\r\n Connection: close\r\n
Content-Type: video/MP2T\r\n \r\n
[email protected]. ..0... [truncated]