HLS is coming.

In a major step forward for our access mission, we’re transitioning to adaptive bitrate video streaming. This is a significant upgrade to our viewing experience, and should enable viewers everywhere to watch high-quality video content with minimal buffering, and in a stream quality that is perfectly suited to the learner’s bandwidth.

What is HLS?

HTTP Live Streaming (HLS) is a method of delivering video to users wherein the video player uses buffering and connection speed to determine the best-quality stream that is deliverable with no, or minimal, pauses in playback. The player adjusts video quality in set time intervals (in our case, around 9 seconds) as the video is played back, constantly improving or reducing video playback quality as the connection speed fluctuates. Simply put, it matches video quality to connection speed, and adjusts as the connection changes.

How does it work?

Streaming:

HLS is adaptive bitrate video. When a client player calls for an HLS stream, instead of downloading a single static video file, the player retrieves a manifest file (typically an .m3u8 playlist). This manifest has resolution and bandwidth information. (In our case, we use 7 independent streams, ranging in size from 216p to 1080p.)

manifest.m3u8

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=162411,RESOLUTION=1280x720
48df96ce-77b5-4c3b-b2d9-b6c96bca6660_1_.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=293614,RESOLUTION=1920x1080
48df96ce-77b5-4c3b-b2d9-b6c96bca6660_0_.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=38644,RESOLUTION=640x360
48df96ce-77b5-4c3b-b2d9-b6c96bca6660_3_.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=86772,RESOLUTION=960x540
48df96ce-77b5-4c3b-b2d9-b6c96bca6660_2_.m3u8

Each list item is a relative URL to a more detailed transport stream, also an .m3u8 playlist file, which contains timing information:

48df96ce-77b5-4c3b-b2d9-b6c96bca6660_1_.m3u8

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:9.609611,
48df96ce-77b5-4c3b-b2d9-b6c96bca6660_0_0.ts
#EXTINF:8.742078,
48df96ce-77b5-4c3b-b2d9-b6c96bca6660_0_1.ts
#EXTINF:9.609611,
48df96ce-77b5-4c3b-b2d9-b6c96bca6660_0_2.ts


…,


#EXT-X-ENDLIST

The video player then starts downloading and playing back the chunk of video that is best suited for the bandwidth conditions, constantly looking ahead and adjusting the quality of video as the stream is fed into the buffer.

As the video player buffers, it attempts to pull the largest file it can, stepping down until the highest-quality version for the data rate is selected and fed into the buffer. On the client side, the viewer will see a seamless uninterrupted stream of video, possibly with minor changes in quality every few seconds, as the player attempts to adjust to the best-quality stream available. Generally, the stream is very quickly buffered ahead of playback, and will rapidly improve as the viewer watches. However, if the viewer has severe data limitations, or wildly fluctuating data speeds, the video quality will appear to degrade occasionally as the video is played back.

Infrastructure:

Manifests, index files, and transport streams are all served via HTTP (in our case, in AWS S3 with a Cloudfront distribution). The HTML5 player JavaScript checks data speed and requests the next-appropriate video chunk object to buffer.

We encode the transport stream via a modified ffmpeg build, with some logic in Python determining the average bandwidth for each stream, and generating the manifest and transport files. The HLS library we use builds a static ffmpeg distro on *nix machines, and is meant to operate as a standalone, or can work in conjunction with an extant encode worker.

Rollout:

We are planning to roll out an updated desktop player in June 2017. As of February 1, 2017, we are encoding all new edx.org videos with an HLS encode option, and have a plan to backfill legacy videos during rollout.

HLS is compatible with both iOS and Android native mobile video players, and we’re working on rolling the new HLS features into mobile, with some adaptations to limit bandwidth usage for users who have high-speed but limited-volume connections (e.g., small mobile data plans).

All of this will happen behind the scenes without user intervention. We will not be making any changes to our current encoding schema. We will continue uploading videos to YouTube and allowing file downloads for courses who want to make downloads available. This is simply additional functionality without any feature regression.

---

Browser not supported