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 access.

...

HLS (HTTP Live Streaming) is a method of delivering video to users wherein the video player uses buffering/connection speed to determine the best-quality stream that is deliverable with no, or minimal, pauses in playback. The video quality is constantly adjusted in set time intervals (in our case, around 9 seconds) as the video is played back, constantly improving or degrading video playback quality as the connection speed is either improved or degraded. 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 is retrieves a manifest file (typically a .m3u8 playlist). This manifest has resolution and bandwidth information (in our case, we use 7 independent streams, ranging in size from 216p to 1080p).

Streaming:

#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:

#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 HTML5/HLS 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 a wildly fluctuating data speeds, the video quality will appear to degrade occasionally as the video is played back.

Infrastructure:

Transport 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. 

Encoding:

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 will build builds a static ffmpeg distro on *nix machines, and is meant to operate as a standalone library that works , or can work in conjunction with our an extant encode workersworker.

Roll Out:

We are planning on rolling out an updated desktop player in early Summer 2017. We are currently encoding all new edx.org videos (As of Feb 1, 2017) with an HLS encode option, and have a plan to backfill legacy videos during roll-out. 

...