Streaming Video Trends: Finally, We Have a Standard
For some time, streaming video has been dominated by three formats or has been proprietary. The dominating formats are Microsoft’s Smooth Streaming (Silverlight), Adobe HDS (HTTP Dynamic Streaming), or Apple’s HLS (HTTP Live Streaming). Since they are similar but not exactly the same, an effort has been made to standardized methods that behave like these three. The standard is DASH (Dynamic Adaptive Streaming over HTTP), published as ISO/IEC 23009-1.
When video was first delivered to computing devices it was downloaded completely and then played. Generally a file on a server was delivered in form of file transfer, not necessarily FTP (file transfer protocol). A module of software called a player then rendered the audio and video for output to the speakers and monitor. Real Networks and Adobe added the idea that play out could begin before the entire file was delivered. That was called progressive download. As long as the network and server could deliver the video at a rate that exceeded the bit rate at which the video was being viewed, everything was fine.
However, if network conditions deteriorated or the computer playing the video became busy with other tasks, the play out might pause. To overcome deteriorating conditions, the manufacturers took a new approach: let the client player decide the amount of video it was able to process and play. In other words, the client might start playing standard video at 720X480, 30 fr/sec but suddenly decides it could only handle 320X240, 15 fr/sec for an interval of time. Since the lower resolution would take one-fourth of the bandwidth in the network and one-fourth the processor cycles in the receiver, the video was less likely to pause. In this new scheme, when the client requested a particular program, the server could first deliver a manifest, a list and descriptions of video. The standard refers to this manifest as the Media Presentation Description and Segments. However, nearly everyone calls it the manifest in conversation. The client would select a profile and the video would be delivered and played. Typically ,the delivery would be in incremental small files call chunks, representing about two seconds of video. That means the client could ask for a different profile every two seconds. Since this adaption could be exercised continually across time, it was called dynamic adaptive streaming. In addition, these techniques all streamed over the HTTP (Hypertext Transfer Protocol.) Hence, the general name applied to these types of transfers was DASH. What was missing was standardization of two key things: the format, syntax and structure of the manifest and the method of the delivery. While HTTP was the protocol in use for transport, Apple used a packet layout conforming to mpeg transport (MP2TS), commonly used in IPTV while Adobe did not use that. The standard also allows for a transport format call Base Media File Format (ISOBMFF).
So, the principle features of DASH are:
(1) IT is a pull technology. The client decides what it wants delivered and instructs the server to deliver it.
(2) The manifest is the key to what is possible.
(3) Nearly any codec can be used to encode and decode the video, as long as it is announced in the manifest.
(4) The file container used and the transport format must be indicated in the manifest.
The basic steps in DASH delivery are the following:
What types of video can DASH be used for?
Prerecorded video is a natural for DASH. That’s essentially on-demand video. But live video is possible as well. Typically live video is delivered with a few seconds of delay, that gives the DASH client more than enough time to accomplish its tasks. A live feed can be sent to a file in a server and the DASH component of the server can build and deliver the manifest in several seconds, making it available to DASH clients.
The D, dynamic, and the A, adaptive, in DASH were used to make streaming work effectively. But the real potential lies in the H, HTTP. By using this for transport a standard web enabled device can receive the stream. Of course, that includes computer devices. However, with recent innovatioons it could include televisions. A recent study published by DisplaySearch says that 47% of TV’s in 2015 will be web enabled.
A second key feature of DASH video is that it will work over networks that could not support IPTV. Networks experiencing 1-2% packet loss (for example, this is common for Wi-Fi connections), can handle DASH delivery without much difficulty. That’s because HTTP is always run over TCP (transmission control protocol). And, TCP makes sure the data arrives by using a sophisticated algorithm that includes retransmissions of lost packets. On the other hand, IPTV uses UDP (user datagram protocol) with RTP (real time protocol) or just UDP alone. Neither of these protocols have any means of dealing with lost, misrouted, or erred packets.
A third important feature of DASH is based on the fact that it uses HTTP. Because of this, many attributes of standard web interaction are inherited by DASH traffic. These include:
• DASH traffic flows through firewalls just like any web server response.
• Firewall proxy features and address translation happen transparently without any special configuration.
• DASH traffic can be cached like other web traffic, decreasing the drain on origin servers that have the original video files.
This third point brings up the role of a content delivery network (CDN) provider. These advanced networks can cache the chunks nearer to the play out device. This can significantly improve TCP performance because TCP uses round trip time (RTT) as a measure of how fast it should feed data from the server.
The standard has been published as ISO/IEC 239001-1 by the International Organization for Standards and the International Electrotechnical Commission. The DASH Industry Forum (DASH IF) consists of representatives from over 60 companies. These include a broad cross-section of the network equipment, network providers, software companies and video processing manufacturers. Headed by Dr. Iraj Sodagar of Microsoft, they advocate for use of the standard by spreading the word about DASH through conferences, white papers and publications. They also interface with standards organizations and efforts such as the MPEG Group and the IETF.
What impact will DASH have?
A DASH compliant client will be able to request a video from a server of any manufacturer, as long as the server is building the manifest correctly. The vendor who manufactures the client should make little difference except in the performance of the player. Notice, we never said how the client should handle the issue of adaption. It can use any metrics it chooses to estimate how much it can receive and play. It need only understand the server’s options as described in the manifest and use a codec listed in the manifest.
But even with a standard in place, we will continue to have certain issues. For the most part, those companies that make tools to manage and troubleshoot IP networks haven’t begun to plan for DASH traffic. And, network engineers will look at the traffic and see that it is using TCP and assumes it should behave like traditional data applications rather than real time traffic. This also shows why TCP traffic has traditionally received the lowest levels of priority.
A DASH standard has been ratified. It’s an important advancement and has lots of significant support. Most of us are tired of being required to update versions of three or four players.