HLS Security
Menu

Search Our Site

Menu
The Product Creator for MMCart has a built-in transcoder, which converts all uploaded videos and audios to ABR HLS compatible m3u8 playlists.  

ABR HLS or Adaptive bitrate streaming is used in streaming multimedia over public or private networks. In the past most video streaming technologies utilized streaming protocols such as RTP with RTSP, today's adaptive streaming technologies are almost exclusively based on HTTP;  designed to work efficiently over large distributed HTTP networks such as the Internet.

ABR works by detecting a user's bandwidth and CPU capacity in real time and adjusting the quality of a video stream accordingly. It requires the use of an encoder which can encode a single source video at multiple bit rates. The player client switches between streaming the different encodings depending on available resources. The result: very little buffering, fast start time and a good experience for both high-end and low-end connections.

In MMCart's transcoding process, the source content is encoded at multiple bit rates after the original video is uploaded, then each of the different bit rate streams is segmented into small multi-second parts. The video is then published on a media server that supports HLS, MPEG-DASH or other HTTP compatible protocol. 

The viewing client is made aware of the available streams of differing bit rates, and segments of the streams by a manifest file.

When starting, the client requests the segments from the lowest bit rate stream. If the client finds the download speed is greater than the bit rate of the segment downloaded, then it will request the next higher bit rate segments. Later, if the client finds the download speed for a segment is lower than the bit rate for the segment, and therefore the network throughput has deteriorated, then it will request a lower bit rate segment. The segment size can vary depending on the particular implementation, but they are typically between two (2) and ten (10) seconds.

About ABR

The underlying benefit of streaming video is that it can be viewed by a customer without having to download a video file.  Instead of a large video file, small fragments or segments of media may be transmitted to a media player for playback in order to achieve the same effect. The media must be received as fast of the player plays. Furthermore, because the higher quality content consumes more storage and bandwidth;  a faster network connection is able to play higher quality. 

Because many customers access the Internet with a variety of devices and connection speeds,  ABR was developed to deliver the best quality stream possible at any given time. The introduction of Adaptive Bitrate (ABR) streaming technology has revolutionized the delivery of streaming media. There are two fundamental ideas behind ABR:

Multiple copies of the content at various quality levels are stored on the server.

The client device detects its current network conditions and requests lower quality content when network speeds are slower and higher quality content when network speeds are faster.

These principles are quite simple, but there are many technical challenges involved in producing a functional design for an ABR system. First, the media segments on the server must be created in such a way that the client application is allowed to switch between higher and lower quality versions at any time without seeing a disruptive change in the presentation (e.g. video “jumps” or audio “clicks, pops”). Second, there must be a way for the client to “discover” the characteristics of the ABR content so that it knows what sorts of quality choices are available. And finally, the client itself must be implemented so that it can smartly detect network speed changes and potentially switch to a different quality stream.

HLS

Today, a large portion of video streaming over the internet is using one of several ABR formats. Apple’s HTTP Live Streaming (HLS) and MPEG’s Dynamic Adaptive Streaming over HTTP (DASH) are the predominant technologies. Adobe’s HTTP Dynamic Streaming (HDS) and Microsoft’s Smooth Streaming (MSS) were once quite popular, but have fallen out of favor recently. As you can see, most ABR technologies rely on HTTP as the network protocol for serving and accessing data due to the near-ubiquitous support in servers and clients. All ABR technologies specify some sort of descriptive file or “manifest” which describes the locations, quality, and types of content available to the client.

MPEG-DASH was developed through an open, standards-based process in an effort to incorporate input from all industries and organizations that plan to deploy it. CableLabs, once again, played a critical role in representing the needs of our members during this process. We will focus on the details of MPEG-DASH technology for the remainder of the article.

MPEG-DASH

The MPEG-DASH specification (ISO/IEC 23009-1) was first published in early 2012 and has undergone several updates since. As in other formats, media segments are stored on a standard web server and downloaded using the HTTP or HTTPS protocols. While DASH is audio/video codec agnostic, there are profiles in the specification that indicate how media is to be segmented on the server for ISOBMFF and MPEG2 Transport Stream container formats. Additionally, both live and on-demand media types have been given special consideration.