Video transmission: WebRTC and HTTP-DASH

What this lesson covers

This lesson covers how servers send video. A video is too large for one response, so it is broken into packets, and asking statelessly for each packet in turn wastes resources, as the notes also point out. Whether to use TCP or UDP depends on the use case: live streams are real time data suited to UDP, while a film where two missed seconds matter needs guaranteed ordered delivery over TCP. For ordered delivery the most popular protocol is HTTP-DASH (dynamic adaptive streaming over HTTP), which runs over TCP. The client sends control signals at connection establishment and during the connection: a device that can show at most 720p gets 720p rather than 4K, and a slow network that can only receive 360p per second gets 360p, since continuous viewing beats buffering. HLS works the same way with an adaptive bitrate. The second application is video conferencing. Routing all video through the Google server wastes processing, adds latency and is a single point of failure, so WebRTC removes the server from the media path. The server still authenticates both users and gives each the information to connect to the other's browser, and after that the browsers talk directly. WebRTC runs over UDP and handles connection establishment behind firewalls and network address translation, with STUN and TURN servers mentioned. A media server avoids the order n squared connections of broadcasting to many people.

• Video is sent as packets, over TCP when order matters and over UDP for real time data
• HTTP-DASH and HLS run over TCP and adapt the bitrate to the client's maximum resolution and current network speed
• Relaying conference video through a central server wastes bandwidth, adds latency and is a single point of failure
• WebRTC runs over UDP and lets browsers exchange media directly after the server authenticates both users
• A media server avoids the order n squared connections of broadcasting to many participants