HTTP Video Streaming

As I have mentioned in my previous post, my dissertation will focus mainly on optimising online video streaming for slow Internet connections. During the first week of December, I finalised my literature review section and I had the chance to learn more about the process of online video streaming. I have also included in my study a detailed description of current initiatives in central Africa for online learning and did a case study on technologies used by Coursera, one of today’s largest MOOC platforms.

I’ll try to describe briefly in this post my findings related to how HTTP video streaming works. First of all, to stream data in general, either video or audio, means to start processing the data you receive, even before the client receives everything. Most commonly, video files are large and it would take probably minutes, depending on the download speed of your Internet connection, until you would be able to play the video and watch. Not a very good experience on the user’s part. Therefore, improvements had to be made.

What is now most commonly used is a protocol of adaptive bitrate streaming. The most popular and effective one at the moment is DASH, which stands for Dynamic Adaptive Streaming over HTTP. DASH was born out of the need of standardising online video streaming. Multiple HTTP delivery platforms, such as Microsoft Smooth Streaming, Apple HLS or Adobe HDS, posed a lot of challenges for content delivery operators that had to resolve multiple compatibility issues. In 2009, the MPEG (Moving Picture Expert Group) decided to develop an industry standard for HTTP streaming, so 2 years later, the DASH protocol was created. The DASH Industry Forum, supported by large technology companies, have developed the Dash.js JavaScript library in order to enable the development of video players that support this standard. Large on-demand video providers such as Netflix, YouTube or Hulu have already used this JS library and adapted it to their platform’s needs.

When DASHis used, the video file is segmented and each segment is saved under multiple resolutions (audio only, 240p, 360p, 480p or 720p). The client can then opt for a better quality, if bandwidth permits. As soon as it senses the Internet connection slightly improved, it can fetch a better video quality segment and adapt again, if necessary. Data is dowloaded through the Transmission Control Protocol (TCP), a much reliable alternative to the classic User Datagram Protocol (UDP), which does not benefit from package retransmission mechanisms. Encoding.com has a very good visual representation on how it actually makes this selection process, depending on the mobile Internet connection:

HLS_timestamp1

The Dash.js library makes use of the HTML5 video tag implementation and is on open-source library with great support from large technology companies such as Microsoft.

In terms of online video players, we can put them in 3 main categories:

  • Microsoft Silverlight
  • Adobe Flash Player
  • HTML5 players

In order to use the first 2 ones, you need to install a plugin into the browser in order to view the video content. With HTML5, however, everything is built-in, as your browser already knows what the HTML5 video tag means and is supposed to do. A lot of HTML5 video players are “out there” on the market, with an Adobe Flash fallback. One just player, especially developed for adverse (mobile) network conditions is the Bitdash. The Austrian company invests a lot in research, implementing the latest developments in online video streaming into their DASH-MPEG player.

I hope this post was informative and hopefully not too long. I will expand more on how online video players work in a future post and decide on which one I will use for my final year project. For the time being, I will focus on developing the project’s poster for our presentation session on the 14th of January.