Delivering a great live streaming experience to mobile devices starts with a great implementation of the mobile-centric technical standard called HTTP Live Streaming, or also known as HLS.
This blog post will provide a short introduction to HLS as seen through its server implementation on Adobe Media Server and its mobile device implementation using web browser technology.
HTTP Live Streaming (HLS)
HTTP Live Streaming (HLS) sends audio and video over HTTP from ordinary web servers and content delivery networks for playback within web browsers or native apps, especially on mobile devices. HLS supports the following:
- Live broadcasts and pre-recorded content (video on demand, or VOD)
- Multiple alternate streams at different bit rates. Intelligent switching of streams in response to network bandwidth changes or after initial playback of a purposefully lower quality stream.
With that background, let’s talk about the concepts involved.
The first concept is that of manifest files that provide a roadmap for the player to a) choose an appropriate quality stream and b) request the video segments (see Server Packaging below) for that stream needed to provide seamless playback as the user interacts in various ways with the video (e.g. skipping ahead in a larger VOD stream).
Think of this manifest as a playlist that lists the different sizes/types of streams available. The playlist describes the quality of streams available and points to individual media manifests for all of the streams.
Having chosen an appropriate quality stream, the media manifest provides the player an index of the video segments. The player downloads each available segment file in sequence. Once it has a sufficient amount of data downloaded, the player begins presenting the reassembled stream to the user.
For VOD, this media manifest does not change throughout playback for a user, but for Live, this media manifest is updated by removing links to segments as new segments are created and made available. The set of segments in the media manifest are referred to as that stream’s sliding window. Players cannot seek beyond the sliding window length and some players use the sliding window to configure the seek bar.
A key concept in HLS is the segmenting of video files into smaller chunks such that a player can easily switch between streams of differing quality (e.g., as a user moves to a location with less or more bandwidth) without having to completely download a new stream.
This segmenting of video files and then subsequently providing them to a player is generically referred to as packaging.
As an example implementation of packaging, the Adobe Media Server (distributed exclusively by Veriskope) has a real-time stream segmenter and a set of Apache modules to access those segments that together facilitate Live HLS playback. For Adobe Media Server, this can be as simple as configuring the following RTMP URL in your encoder:
And, then configuring your player to play the HLS stream(s) with this URL:
Playback in Browsers
There’s native support for HLS in 97.4% of tracked mobile browsers. But, on tracked desktop browsers, that support drops to 13.2%. To mitigate that low desktop support, browser-based polyfills like Video.js http-streaming exist. (Increasingly, these polyfills are being incorporated into larger browser playback libraries.) Using a high-quality polyfill like this should give you a level of overall browser support that is more than acceptable.
The image below shows a portion of Adobe Media Server’s HLS Live playback activity as seen in a web browser’s dev tools. Additionally shown is the media manifest as it is being updated as new segments become available.
Next Blog Post: Troubleshooting HLS
With that conceptual foundation, in our next blog post, we’ll dive deeper into running an HLS Live/VOD service with discussion of common sources of issues across customer mobile devices and servers and how to effectively isolate those issues.