The correct way to stream videos
In the beginning, when a web site wished to deliver a video to a client, a single video file was placed on the web site and the client downloaded the complete file and then played the file from local storage. This was a bad user experience as the whole file had to be downloaded before the user could watch the video.
An improvement was to progressively stream a single bitrate video file. Depending on your network the video buffers and then starts to play before the whole video has downloaded. This is a big improvement over waiting for the whole file to download. If your network slows the buffer is used. Ideally the buffer never empties, otherwise you have a stalled video as the buffer is refilled. Unfortunately far too often the network slows and we are left waiting for the video to play. This should never happen and if it does it is because your content distributor is not using the 3rd approach - Adaptive Bitrate Streaming.
The best way to stream video today is to use a form of Adaptive Bitrate Streaming over HTTP. This type of delivery is a combination of server and client software that detects a client’s bandwidth capacity and adjusts the quality of the video stream between multiple bitrates and/or resolutions. The adaptive bitrate video experience is superior to delivering a static video file at a single bitrate, because the video stream can be switched midstream to be as good or bad as the client’s available network speed (as opposed to the buffering or interruption in playback that can happen when client’s network speed can’t support the quality of video). In addition, the lack of firewalls, special proxies or caches, and its cost efficiency have increased its popularity and use.
Typically a source 1080p30 video asset is encoding into the following different bitrates such that the client can switch between them as the network conditions allow, Typically every 2 seconds. In the future H.265 will be added as well as UHD 2160p 4K.
|Encoded Variant||Codec||Resolution||Bitrate (Mbps)|
Today there are 3* main Adaptive Bitrate Streaming over HTTP protocols. Two proprietary (Apple and Adobe) and a new emerging open standard called MPEG Dynamic Adaptive Streaming over HTTP (DASH).
|MPEG DASH||Apple HTTP Live Streaming (HLS)||Adobe HTTP Dynamic Flash Streaming (HDS)|
|Type||Open, standards-based||Single-vendor controlled||Single-vendor controlled|
|Device support||Any, Open source code available||iOS, OS X, Xbox, Playstation, STB, TV, Android||iOS, Windows, TV|
|Source Video Codecs||H.264, (H.265) + others (agnostic)||H.264 (H.265)||H.264, VP6, (H.265)|
|Source Audio Codecs||AAC + others (agnostic)||AAC, MP3||AAC, MP3|
|Package/Segment format||MP4 fragments + MPEG-2 TS||MPEG-2 TS||MP4 fragments|
|File storage on server||Contiguous or individual files per segment||Contiguous or individual files per segment||Contiguous|
|Audio/video/text packaging||Multiplexed or separate segments for audio, video||Multiplexed in 1 segment||Multiplexed in 1 segment|
|Segmentation and Delivery||Multiple vendors. Standard HTTP or Streaming servers (+ Helix)||Multiple vendors. Standard HTTP or Streaming server (+ Helix)||Adobe Interactive Server (or Adobe tools + Apache module for on-demand)|
|Playback||3GPP-Rel 9 or MPEG clients (+ Helix)||Apple iOS, QT X (+ Helix)||Flash, Air|
|Protection||Flexible (e.g. OMA or UV)||AES-128 encryption||Flash Access|
|Typical Segment Duration||Flexible||10 sec||2-4 sec|
Already companies like NetFlix and Google YouTube are using MPEG DASH. Given its open standard and cross platform support it is the format we would recommend. You can download example reference and demonstration MPEG DASH players, player libraries and packagers from the MPEG DASH organization
So the next time your video stalls and starts to buffer complain to the web site and ask them why they are not using Adaptive Bitrate Streaming.
*In the past Microsoft had Smooth Streaming but it is much less common.