Table of Contents

What is Adaptive Bitrate (ABR) Streaming?

Adaptive Bitrate Streaming (ABR) is a technology used in modern video streaming applications that can dynamically adapt in real-time, in order to provide the best quality for each individual viewer. ABR streams take into account network conditions, screen size and device capabilities and can adjust on the fly to changes in available bandwidth and device resources. 

Video content is prepared for ABR streaming by encoding different video files or renditions of the same content at different bitrates and video resolution. The video file is split into smaller chunks so the streaming client or video player can select the best video quality depending on its current network connection. This may change several times throughout a viewing session, but by implementing abr streaming, providers can ensure smooth playback for all viewers whether they are mobile users or viewing on 4K televisions at home. 

What is Progressive Video Streaming?

Progressive streaming or Progressive video streaming is a form of streaming that involves using a single video file to deliver content over the internet. Viewers can progressively download video content and begin streaming before the entire file is downloaded. It’s a simple, straightforward approach to deliver video that works with most web browsers, but has some drawbacks. Because it is limited to a single file, the same resolution and bitrate will be delivered to every viewer and device, regardless of its capabilities or available bandwidth.   

What might happen if you don’t use Adaptive Bitrate Streaming?

Progressing streaming using a single file or single video bitrate to deliver video has some limitations when compared to adaptive bitrate streaming. If you choose to prioritize higher quality video by encoding with a higher video bitrate, viewers on slower connections may experience buffering and other performance issues. If you play it safe and encode a low bitrate stream, you will reduce streaming quality for everyone, which will be especially noticeable on larger screens. Either way, using progressive streaming limits your ability to deliver the best video quality to everyone, while adaptive bitrate streaming ensures your video content can be efficiently delivered with the highest possible quality for every viewer.

How Does Adaptive Bitrate Streaming Work?

There are several steps involved with adaptive bitrate streaming. First, content is prepared for video streaming by encoding a direct camera feed or transcoding a master source file into multiple video streams with different bitrates, resolutions, and frame rates. Files prepared for adaptive streaming are also usually split into multiple video segments or chunks. Next, a manifest file is created that contains all the information adaptive streaming clients or video players need to know about the different versions. 

Once video playback begins, the player will monitor things like buffer level and the download speed of video segments, and if the network connection slows down, it will switch to a lower bitrate stream. Once conditions improve, it will seamlessly switch back to a higher quality version. That’s the “adaptive” part of adaptive video streaming, the ability to adjust video quality on the fly depending on changing conditions, ensuring the best possible viewing experience.

Preparation: Video Encoding and Transcoding

Whether you are doing ABR live streaming or preparing video files for on-demand viewing, you’ll need to create different bit rates to serve different devices and network conditions. The process of converting a raw camera feed or uncompressed source is called video encoding. Converting from an already compressed file, sometimes known as a mezzanine file, is known as transcoding. Both involve preparing the source for adaptive bitrate streaming by converting it into multiple formats and splitting it into video segments or chunks. The lengths vary from application to project but are often between two and ten seconds each. 

Codec, target bitrates, resolution and frame rate are all things that need to be considered during this phase. H.264 is the most commonly used and widely supported codec, but newer codecs like H.265, VP9 and AV1 can provide higher quality while using lower bitrates than H.264. It’s also important to consider your viewing audience and application when deciding on your encoding settings. If your streaming service delivers video primarily to Smart TVs and set-top boxes, then you probably have different priorities than a service that only involves mobile streaming. For example, mobile users are more likely to have slower and more challenging network conditions than someone viewing on a home broadband connection, while someone viewing on a 4K television will want content that takes full advantage of their larger screen when streaming video. 

What Video Stream Bitrate Should I Choose?

The best bit rate depends largely on your content and your target audience, but with adaptive streaming, you don’t have to choose just one. By choosing a range of different bitrates and resolutions, you can ensure your video platform is providing the best quality of experience for your entire audience. This range of bitrate and resolution combinations is commonly referred to as an abr encoding ladder. 

Encoding Ladders for Adaptive Bitrate Streaming 

The video assets you’ve prepared for ABR streaming make up your encoding ladder. On the top of the ladder, a high-bitrate, high-quality stream is output to viewers on fast connections, using the latest technology and hardware. At the bottom of the ladder, the same footage can be seen as a lower resolution, low bitrate stream for users with smaller screens or a poor connection speed. Having more “rungs” on your ladder or more versions of the same content can mean switching between them is less noticeable to users, but this comes at the cost of higher storage requirements.

In the early days of adaptive streaming, one-size-fits all ABR ladders were often used, many based on Apple’s default recommendation. Today, the more modern and efficient approach involves using a content-aware encoding technology like Bitmovin’s Per-Title Encoding, which analyzes the content and complexity of each video file, and determines the ideal ABR ladder. This ensures you’re providing the best quality for viewers without wasting any video data or storage capacity.

Which Adaptive Streaming Protocol Should I Use?

A streaming protocol provides a means of displaying audio or video via the internet. The two most commonly used streaming protocols are HLS (HTTP live streaming) and MPEG DASH (Dynamic Adaptive Streaming over HTTP). HLS is more associated with Apple’s streaming technology ecosystem while DASH is more thought of as a universal and open solution, but both are widely used and support the use of multiple codecs, encryption and DRM. 

CMAF (Common Media Application Format)  is a relatively new open standard container format that is compatible with both HLS and DASH. This has simplified workflows, allowing any streaming service to deliver both HLS and DASH streams, without having to perform duplicate encodings. 

Microsoft Smooth Streaming is another streaming protocol that had seen some wide use in the early days of adaptive streaming. But as the popularity of HLS and DASH grew, content providers and streaming services transitioned away from smooth streaming and Microsoft began phasing out support in 2021.   

Manifest File Creation

Manifest files provide all the information a client needs for video playback and dynamic adaptive streaming and are used for both live streaming and video-on-demand (VOD). They contain information about what codecs were used, their bitrates, resolutions, frame rates and where the individual video files are stored on the streaming server. Different streaming protocols use their own manifest file format. HLS uses the .m3u8 playlist and MPEG DASH uses the .mpd (Media Presentation Description) format. 

Most encoding and transcoding products and services can automatically generate your manifest files for you, based on your adaptive bitrate ladder and other settings. They may also provide more advanced users the ability to fine-tune their manifest or create multiple manifests used to target different devices, based on their video playback capabilities. There are also some standalone packaging solutions that can create ABR streaming manifests from previously encoded video files. 

Dynamic Playback to Maximize Video Quality

Video players typically start streaming video at low bitrate and then request higher and lower quality video chunks if the network conditions change, though some platforms will allow you to specify which quality is chosen first. The ABR streaming algorithm determines which version to download next.

There are several variations, but the ABR algorithms video players use typically consider the speed of download and buffer capacity when deciding which video segment to select. This is an area of adaptive bitrate streaming that has gotten more attention recently with video streaming services looking to find a competitive edge by customizing their abr algorithm to provide the best possible quality of experience.Another aspect of ABR streaming getting more attention recently is the environmental impact of streaming video.

New research from Bitmovin and the GAIA project is exploring ways to reduce the carbon footprint of streaming by providing ways for services and end users to adjust the ABR algorithm in their video players to lower power consumption. The image below shows a prototype interface for our Eco Mode, provides extra detail and allows the user to adjust the player properties to use less power.

The Benefits Of Adaptive Bitrate Streaming

Adaptive bitrate streaming offers several benefits for both content providers and their users by making content available to a wider array of devices and improving the viewing experience regardless of network conditions. Whether viewing at home or on a mobile device, content is prepared in a way that makes the best impression on every screen and is able to seamlessly adapt to variable bandwidth. 

Costs are reduced by optimizing the ABR ladder to minimize unnecessary video data transfer, while at the same time improving the quality of experience with less buffering and an uninterrupted viewing session. This also improves viewer engagement and retention, reducing churn for subscription services and increasing impressions for advertising-based services. 

ABR streaming is also highly scalable and is well suited for both live and VOD content, making it the best choice to support popular events and viral videos. ABR streaming is essential for delivering the highest quality content to the widest audience with a diverse assortment of video playback devices and network connections. Implementing adaptive bitrate streaming ensures your content is presented seamlessly and in its best form, creating the best experience for your viewers and outcome for your streaming business.    

Frequently Asked Questions

Does Adaptive Bitrate Streaming Improve Video Quality?

Video quality is largely determined by the encoding settings used, but ABR streaming allows you to encode in multiple bitrates and resolutions to ensure the best quality of experience for all of your viewers.

Does Netflix use Adaptive Bitrate Streaming? 

Yes! Netflix, YouTube and all other modern streaming platforms take advantage of ABR streaming for the best combination of quality of experience for viewers and cost efficiency.

What is Multi bitrate vs Adaptive Bitrate Streaming?

Multi bitrate streaming usually refers to a situation where the viewer can explicitly select which version or quality of the video they want to watch, where Adaptive Bitrate Streaming handles the quality selection automatically based on their device and network connection. 

What is the difference between progressive and adaptive streaming?

Adaptive Streaming involves creating multiple versions of your content to best serve viewers on all types of devices and network connections. Progressive streaming involves the use of a single video file and ultimately means sacrificing quality for some viewers and making your content inaccessible to others.

The post Adaptive Bitrate Streaming (ABR): What is it & How Does it Work? [2023 Update] appeared first on Bitmovin.

Chapters:

• The History of MPEG-DASH?
• What is MPEG-DASH (in a Nutshell)?
• Media Presentation Description (MPD)
• Segment Referencing Schemes
• Conclusion and Further Reading

1: The History of MPEG-DASH (Dynamic Adaptive Streaming over HTTP, ISO/IEC 23009-1)

MPEG-DASH (Dynamic Adaptive Streaming over HTTP, ISO/IEC 23009-1) is a vendor-independent, international standard ratified by MPEG and ISO. Previous adaptive streaming technologies – such as Apple HLS, Microsoft Smooth Streaming, Adobe HDS, etc. – have been released by vendors with limited support of company-independent streaming servers as well as playback clients. As such a vendor-dependent situation is not desired, standardization bodies started a harmonization process, resulting in the ratification of MPEG-DASH back in 2012.

Key-Targets and Benefits of MPEG-DASH:

• reduction of startup delays and buffering/stalls during the video
• continued adaptation to the bandwidth situation of the client
• client-based streaming logic enabling the highest scalability and flexibility
• use of existing and cost-effective HTTP-based CDNs, proxies, caches
• efficient bypassing of NATs and Firewalls by the usage of HTTP
• common Encryption – signalling, delivery & utilization of multiple concurrent DRM schemes from the same file
• simple splicing and (targeted) ad insertion
• support for efficient trick mode

In recent years, MPEG-DASH has been integrated into new standardization efforts, e.g., the HTML5 Media Source Extensions (MSE) enabling the DASH playback via the HTML5 video and audio tag, as well as the HTML5 Encrypted Media Extensions (EME) enabling DRM-protected playback in web browsers. Furthermore, DRM-protection with MPEG-DASH is harmonized across different systems with the MPEG-CENC (Common Encryption) and MPEG-DASH playback on different SmartTV platforms is enabled via the integration in Hybrid broadcast broadband TV (HbbTV 1.5 and HbbTV 2.0). The usage of the MPEG-DASH standard has also been simplified by industry efforts around the DASH Industry Forum and their DASH-AVC/264 recommendations, as well as forward-looking approaches such as the DASH-HEVC/265 recommendation on the usage of H.265/HEVC within MPEG-DASH.

Here is a table showing MPEG-DASH Standards:

Today, MPEG-DASH is gaining more and more deployments, accelerated by VOD platforms such as Netflix or Google which have adopted this important standard. With these two major sources of internet traffic taken into account, 50 % of total internet traffic is already MPEG-DASH.

2: What is MPEG-DASH (in a Nutshell)?

The basic idea of MPEG-DASH is this: Chop the media file into segments that can be encoded at different bitrates or spatial resolutions. The segments are provided on a web server and can be downloaded through HTTP standard-compliant GET requests (as shown in the figure below) where the HTTP Server serves three different qualities, i.e., Low, Medium, and Best, chopped into segments of equal length. The adaptation to the bitrate or resolution is done on the client-side for each segment, e.g., the client can switch to a higher bitrate – if bandwidth permits – on a per-segment basis. This has several advantages because the client knows its capabilities, received throughput, and the context of the user best.

Here’s an example of an MPEG-DASH workflow:

In order to describe the temporal and structural relationships between segments, MPEG-DASH introduced the so-called Media Presentation Description (MPD). The MPD is an XML file that represents the different qualities of the media content and the individual segments of each quality with HTTP Uniform Resource Locators (URLs). This structure provides the binding of the segments to the bitrate (resolution, etc.) among others (e.g., start time, duration of segments). As a consequence, each client will first request the MPD that contains the temporal and structural information for the media content, and based on that information it will request the individual segments that fit best for its requirements.

3: Media Presentation Description (MPD)

The MPEG-DASH Media Presentation Description (MPD) is a hierarchical data model. Each MPD could contain one or more Periods. Each of those Periods contains media components such as video components e.g., different view angles or with different codecs, audio components for different languages or with different types of information (e.g., with director’s comments, etc.), subtitle or caption components, etc. Those components have certain characteristics like the bitrate, frame rate, audio channels, etc. which do not change during one Period. Nevertheless, the client is able to adapt during a Period according to the available bitrates, resolutions, codecs, etc. that are available in a given Period.

Furthermore, a Period could separate the content, e.g., for ad insertion, changing the camera angle in a live football game, etc. For example, if an ad should only be available in high resolution while the content is available from standard definition to high definition, you would simply introduce your own Period for the ad which contains only the ad content in high definition.
After and before this Period, there are other Periods that contain the actual content (e.g., movie) in multiple bitrates and resolutions from standard to high definition.

What are AdaptationSets?

Typically, media components such as video, audio or subtitles/captions, etc. are arranged in AdaptationSets. Each Period can contain one or more AdaptationSets that enable the grouping of different multimedia components that logically belong together.
For example, components with the same codec, language, resolution, audio channel format (e.g., 5.1, stereo), etc. could be within the same AdaptationSet. This mechanism allows the client to eliminate a range of multimedia components that do not fulfill its requirements. A Period can also contain a Subset that enables the restriction of combinations of AdaptationSets and expresses the intention of the creator of the MPD. For example, allowing high definition content only with 5.1 audio channel format.

This graph shows an example of an MPD Model

An AdaptationSet consists of a set of Representations containing interchangeable versions of the respective content, such as different resolutions and bitrates, etc. Although one single Representation would be enough to provide a playable stream, multiple Representations give the client the possibility to adapt the media stream to its current network conditions and bandwidth requirements. This guarantees a smooth playback.

Of course, there are also further characteristics beyond the bandwidth describing the different representations and enabling adaptation. Representations may differ in the used codec, the decoding complexity and therefore the necessary CPU resources, or the rendering technology, just to name a few examples. Representations are chopped into Segments to enable the switching between individual Representations during playback. Those Segments are described by a URL and in certain cases by an additional byte range if those segments are stored in a bigger, continuous file.

The Segments in a Representation usually have the same length in terms of time and are arranged according to the media presentation timeline, which represents the timeline for the synchronization, enabling the smooth switching of Representations during playback. Segments could also have an availability time signalled as wall-clock time from which they are accessible for live streaming scenarios. In contrast to other systems, MPEG-DASH does not restrict the segment length or give advice on the optimal length. This can be chosen depending on the given scenario, e.g., longer Segments allow more efficient compression as Group of Pictures (GOP) could be longer or less network overhead, as each Segment will be requested through HTTP and with each request a certain amount of HTTP overhead is introduced. In contrast, shorter Segments are used for live scenarios as well as for highly variable bandwidth conditions like mobile networks, as they enable faster and flexible switching between individual bitrates.

Subsegments

Segments may also be subdivided into smaller Subsegments which represent a set of smaller access units in the given Segment. In this case, there is a Segment index available in the Segment describing the presentation time range and byte position of the Subsegments, which may be downloaded by the client in advance to generate the appropriate Subsegment requests using HTTP 1.1 byte range requests. During the playback of the content, arbitrary switching between the Representations is not possible at any point in the stream and certain constraints have to be considered. For example, Segments are not allowed to overlap, and dependencies between segments are also not allowed. To enable the switching between Representations, MPEG-DASH introduced Stream Access Points (SAP) on which this is possible. As an example, each Segment typically begins with an IDR-frame (in H.264/AVC) to be able to switch the Representation always after the transmission of one segment.

4: Segment Referencing Schemes

Segments are typically referenced through URLs as defined in RFC3986, using HTTP or HTTPS restricted possibly by a byte range. The byte range can be signaled through the attribute range and must be compliant with the RFC2616. Segments are part of a Representation, while elements like BaseURL, SegmentList, SegmentTemplate, and SegmentList can add additional information, such as location, availability, and further properties. Specifically, a representation should only contain one of the following options:

• one or more SegmentList elements
• one SegmentTemplate
• one or more BaseURL elements, at most one SegmentBase element and no SegmentTemplate or SegmentList element.

SegmentBase

SegmentBase is the most trivial way of referencing segments in the MPEG-DASH standard as it will be used when only one media segment is present per Representation, which will then be referenced through a URL in the BaseURL element. If a Representation should contain more segments, either SegmentList or SegmentTemplate must be used.

For example, Representation using SegmentBase could look like this:

<Representation mimeType="video/mp4"
                   frameRate="24"
                   bandwidth="1558322"
                   codecs="avc1.4d401f" width="1277" height="544">
  <BaseURL>http://cdn.bitmovin.net/bbb/video-1500k.mp4</BaseURL>
  <SegmentBase indexRange="0-834"/>
</Representation>

The Representation example above references one single segment through the BaseURL which is the 1500 kbps video quality of the corresponding content. The index of the quality is described by the SegmentBase attribute indexRange. This means that the information about Random Access Points (RAP) and other initialization information is contained in the first 834 bytes.

SegmentList

The SegmentList contains a list of SegmentURL elements which should be played back by the client in the order at which they occur in the MPD. A SegmentURL element contains a URL to a segment and possibly a byte range. Additionally, an index segment could occur at the beginning of the SegmentList.

Here is an example of Representation using SegmentList:

<Representation mimeType="video/mp4"
                   frameRate="24"
                   bandwidth="1558322"
                   codecs="avc1.4d401f" width="1277" height="544">
  <SegmentList duration="10">
    <Initialization sourceURL="http://cdn.bitmovin.net/bbb/video-1500/init.mp4"/>
    <SegmentURL media="http://cdn.bitmovin.net/bbb/video-1500/segment-0.m4s"/>
    <SegmentURL media="http://cdn.bitmovin.net/bbb/video-1500/segment-1.m4s"/>
    <SegmentURL media="http://cdn.bitmovin.net/bbb/video-1500/segment-2.m4s"/>
    <SegmentURL media="http://cdn.bitmovin.net/bbb/video-1500/segment-3.m4s"/>
    <SegmentURL media="http://cdn.bitmovin.net/bbb/video-1500/segment-4.m4s"/>
  </SegmentList>
</Representation>

SegmentTemplate

The SegmentTemplate element provides a mechanism to construct a list of segments from a given template. This means that specific identifiers will be substituted by dynamic values to create a list of segments. This has several advantages. For example, SegmentList based MPDs can become very large because each segment needs to be referenced individually. Compared with SegmentTemplate, this list could be described by a few lines that indicate how to build a large list of segments.

Here is a number based SegmentTemplate:

<Representation mimeType="video/mp4"
                   frameRate="24"
                   bandwidth="1558322"
                   codecs="avc1.4d401f" width="1277" height="544">
  <SegmentTemplate media="http://cdn.bitmovin.net/bbb/video-1500/segment-$Number$.m4s"
                      initialization="http://cdn.bitmovin.net/bbb/video-1500/init.mp4"
                      startNumber="0"
                      timescale="24"
                      duration="48"/>
</Representation>

The example above shows the number-based SegmentTemplate mechanism. As you can see, instead of having multiple individual segment references through SegmentURL as shown in the SegmentList example, a SegmentTemplate can describe this use case in just a few lines. This is what makes the MPD more compact. This is especially useful for longer movies with multiple Representations where an MPD with SegmentList could have multiple megabytes. This would heavily increase the startup latency of a stream, as the client has to fetch the MPD before it could start with the actual streaming process.

Time-Based SegmentTemplate

The SegmentTemplate element could also contain a $Time$ identifier, which will be substituted with the value of the t attribute from the SegmentTimeline. The SegmentTimeline element provides an alternative to the duration attribute with additional features, such as:

• specifying arbitrary segment durations
• specifying exact segment durations
• specifying discontinuities in the media timeline

The SegmentTimeline also uses run-length compression, which is especially efficient when having a sequence of segments with the same duration. When SegmentTimline is used with SegmentTemplate then the following conditions must apply:

• at least one sidx box shall be present
• all values of the SegmentTimeline shall describe accurate
  timing, equal to the information in the sidx box

Here’s an example of an MPD excerpt with a SegmentTemplate that is based on a SegmentTimeline

<Representation mimeType="video/mp4"
                   frameRate="24"
                   bandwidth="1558322"
                   codecs="avc1.4d401f" width="1277" height="544">
  <SegmentTemplate media="http://cdn.bitmovin.net/bbb/video-1500/segment-$Time$.m4s"
                      initialization="http://cdn.bitmovin.net/bbb/video-1500/init.mp4"
                      timescale="24">
    <SegmentTimeline>
      <S t="0" d="48" r="5"/>
    </SegmentTimeline>
  </SegmentTemplate>
</Representation>

The resulting segment requests of the client would be as follows:

• http://cdn.bitmovin.net/bbb/video-1500/init.mp4
• http://cdn.bitmovin.net/bbb/video-1500/segment-0.m4s
• http://cdn.bitmovin.net/bbb/video-1500/segment-48.m4s
• http://cdn.bitmovin.net/bbb/video-1500/segment-96.m4s
• …

5: Conclusion and Further Reading

MPEG-DASH is a very broad standard and this is just a brief overview of some essential features and mechanisms.
We continue to write informative posts about the MPEG-DASH standard. In the meantime, you can try out MPEG-DASH on your own and encode content to MPEG-DASH through a Cloud-based Encoding Service.
More Readings:

• Multi-Cloud Video Encoding
• Encoding Definition and Adaptive Bitrates 
• HTML5 Video Tag Guide 
• HEVC vs VP9: The Battle of the Video Codecs
• Quality of Experience (QoE)

Did you know?

Bitmovin has a range of video streaming services that can help you deliver content to your customers effectively.
Its variety of features allows you to create content tailored to your specific audience, without the stress of setting everything up yourself. Built-in analytics also help you make technical decisions to deliver the optimal user experience.
Why not try Bitmovin for Free and see what it can do for you.
We hope you found this guide useful! If you did, please don’t be afraid to share it on your social networks!

The post MPEG-DASH (Dynamic Adaptive Streaming over HTTP) appeared first on Bitmovin.

Typical DASH and HLS Chunk Sizes

For the following detailed evaluation of segment sizes, we created a dataset which is encoded and multiplexed using different segment sizes, ranging from 2 seconds (i.e., Microsoft Smooth Streaming) to 10 seconds per segment (recommended by Apple HTTP Streaming) with some steps in between and at the lower and higher end, which results in the sizes of the segments of 1, 2, 4, 6, 10 and 15 seconds, which we took as the basis for the following evaluations.

Segment Length Decision: Encoding Efficiency and Quality?

To enable seamless switching between the different quality representations of adaptive streaming formats such as HLS or DASH, it is required to maintain fixed I-frame positions in the video, e.g., after 48 frames, an I-frame has to be set in a 24 frames-per-second (FPS) video and a segment length of two seconds. This is necessary to guarantee I-frames at the beginning of each segment, which is needed to be able to switch representations between different segments. By doing so at the beginning of a new segment, the decoder does not need any references to previous frames or segments and therefore the new segment can have frames in different resolutions, bitrates, or framerates. Fixed I-frame positions can be achieved by restricting the group-of-picture (GOP) size of the encoder to the desired segment size of the content. As a consequence, from the encoding point of view, smaller segment sizes have a disadvantage because of the higher number of segments in the final encoding, and due to this, there are also more I-frames needed to guarantee representation switching at the segment boundaries. This leads to a lower encoding efficiency because I-frames, which cannot leverage temporal prediction, need more bits for encoding than predicted (P-) frames and so the overall quality of the content gets worse in comparison to conventional encoding at the same bitrate such as used for HTTP progressive download or segments with longer segment sizes. This problem is well-known and needs to be considered in content generation for adaptive HTTP streaming.
As a consequence of this lower encoding performance introduced by the fixed GOP sizes, the following evaluation demonstrates the effect of the different segment sizes on the encoding quality in terms of PSNR. This table shows the PSNR values for different segment sizes and provides evidence that this needs to be considered in the evaluation process for the segment sizes of adaptive HTTP streaming systems.

As shown, small segment sizes can affect the overall quality of the content by up to 1,5 dB of the PSNR value. However, the influence of this effect is reduced significantly by an increase in segment size. As shown in the following figure, segment sizes with lengths smaller than two seconds perform very poorly. In combination with other factors such as network characteristics shown in the following evaluation, such small segments (e.g. 1-second segment length) should generally be avoided.

Segment Length Decision: Avoiding Stalls, Streaming Performance and Web Server/CDN Configuration

From a network/internet perspective, there are also a lot of influencing factors that have to be considered. E.g. longer segment lengths may cause stalls using wireless internet connection with high bandwidth changes, but short segment lengths may result in poor streaming performance due to overhead produced by requests and the influence of the network delay. To investigate this, we built up an evaluation environment to emulate standard Internet connections, in order to show the impact of the segment size of adaptive streaming content, as well as other factors such as HTTP server configuration (e.g. allowing persistent connections). For this purpose, a standard HTTP Web server was used to enable persistent HTTP 1.1-compliant connections as well as non-persistent HTTP 1.0-compliant connections. We also emulated the network characteristics of a last-mile (e.g., ADSL) Internet connection and added a network delay of 150 ms for this evaluation.
The optimal segment size of the given network configuration scenario for both cases, with and without the usage of HTTP1.1/persistent connections, was evaluated. For this purpose, the performance results of the 1, 2, 4, 6, 10, and 15-second segment length versions of Big Buck Bunny of the dataset were analyzed and interpolated to a graph showing the performance of the segment sizes in terms of effective media throughput. As shown in the following figure, the optimal segment size for this network setting would be between 2 and 3 seconds if one uses web servers/CDNs using HTTP 1.1 persistent connections, and between 5 and 8 seconds without using them (e.g. using HTTP 1.0). The effective media throughput of the optimal segment lengths of both configurations differs only by about 50 kbit/s. The reason why the effective media throughput does not improve when increasing the segment size is that the available bandwidth in the evaluation setting changes over time. When longer segments are used, the client is not able to adjust as flexibly and quickly as it would be possible with shorter segments and therefore the overall bitrate deteriorates for longer segment lengths. On the other hand, the influence of the network delay (RTT) increases when using smaller segment lengths. This especially affects the non-persistent/HTTP1.0 connection results, because in this case there is one round-trip-time (RTT) required for establishing the TCP connection to the server after each segment. But also the persistent connection/HTTP1.1 results suffer from the influence of the delay when using very small segments, which is visible in the version with a segment length of one second in the following figure. In this case, half of the RTT necessary for requesting the segment becomes significant and the average throughput decreases.

CONCLUSIONS

Based on the results of these evaluations, as well as our experiences from customer deployments, Bitmovin would recommend using DASh or HLS chunk sizes of around 2 to 4 seconds, which is a good compromise between encoding efficiency and flexibility for stream adaption to bandwidth changes. It is also recommended to use Web servers and CDNs that enable persistent HTTP connections, as this is an easy and cost-effective way to increase streaming performance. Thus, in doing so, the effective media throughput and QoS can be increased without any changes to the client’s implementation, by simply choosing the right segment length.
We hope this blog post helps you when creating your content with the optimal segment length for your use case. If you have further questions on this, please do not hesitate to contact us. You can also have a look at our support section including tips on encoding, the Bitmovin Player in general and analytics.

Encode MPEG-DASH & HLS Content

Encode your content with the same technology as Netflix and YouTube in a way that it plays everywhere with low startup delay and no buffering with the Bitmovin Cloud Encoding Service. 
Best regards,
Stefan from the Bitmovin Team!
[Free Download: Video Developer Report 2020 – Key insights into the evolving technology trends of the digital video industry]
Follow me on Twitter: @slederer
Follow Bitmovin on Twitter: @bitmovin

Video technology guides and articles

• Back to Basics: Guide to the HTML5 Video Tag 
• What is a VoD Platform?A comprehensive guide to Video on Demand (VOD)
• Video Technology [2022]: Top 5 video technology trends
• HEVC vs VP9: Modern codecs comparison
• What is the AV1 Codec?
• Video Compression: Encoding Definition and Adaptive Bitrate
• What is adaptive bitrate streaming
• MP4 vs MKV: Battle of the Video Formats
• AVOD vs SVOD; the “fall” of SVOD and Rise of AVOD & TVOD (Video Tech Trends)
• MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
• Container Formats: The 4 most common container formats and why they matter to you.
• Quality of Experience (QoE) in Video Technology [2022 Guide]

The post Optimal Adaptive Streaming Formats MPEG-DASH & HLS Segment Length appeared first on Bitmovin.

Experience HLS Live and VoD 360º playback on all devices and monetize your content more efficiently with server side ad insertion, in Bitmovin’s 7th major player release. A new skin with new possibilities for customization, improved performance and the possibility to apply custom adaptation decisions, make our HTML5 Player version 7 faster and more versatile than ever!

The Bitmovin team has worked hard in the past few months and, based on customer feedback, have built a lot of minor and major features that have now been integrated into the Player 7 release. Among the most exciting updates are four new major features, VR/360 playback on iOS with HLS for Live and VoD, server side ad insertion, custom adaptation logic and a complete new customizable skin.

VR/360º Live and VoD Streaming on iOS with HLS

360° and VR streaming has received  a lot of attention this year but the technology, as well as the workflows are still in their infancy. Most 360° videos are still delivered through progressive download or RTMP, which is especially painful as 360° videos typically have high resolutions like 4K, as well as high bitrates. 20Mbps and higher is not uncommon. What you usually get is a download and play experience because the videos are slow to start due to the high bitrate. This causes them to buffer very frequently, so most of the time you would simply wait until the video is loaded completely (download) and play it afterwards. That’s obviously a long way from the streaming experience that we have come accustomed to from Netflix and YouTube, as both use adaptive streaming technologies like MPEG-DASH and HLS to deliver their high quality videos. Unfortunately, that is not so easy for 360 videos. They need special treatment on the client side as the equirectangular frame (shown in the figure below) needs to be transformed into an immersive view. This is especially tricky on iOS which only supports HLS, but the Bitmovin team has solved that problem, and because we support HLS and MPEG-DASH you can now stream your 360 videos with Netflix quality to all major devices and platforms.

To achieve a smooth and steady playback of VR and 360º content, we utilize the browser’s built-in HTML5 Media Source Extensions (MSE), or its native video capabilities (e.g., for iOS). However, the player will detect and automatically choose which streaming technology and configuration works best. Besides the different rendering modes, for desktop, mobile and VR headsets, additional parameters, like the start position, or an initial rotation can be set via the HTML5 player configuration. How to enable VR and 360º playback, as well as more detailed information on which content can be used and how it should be encoded, can be found in our end-to-end VR & 360° Video tutorial.

Prevent your Ads from Getting Blocked, using Server-Side Ad Insertion

Monetizing content via advertising is a common tactic in today’s online video streaming industry. The list of abbreviations and acronyms in this area are as long as they are obscure: VAST 3.0, VPAID 2.0, IMA, VMAP, to name just a few. Depending on the level of interactivity required, one can choose the standard that fit’s the targeted use-case best. All the specifications listed above are well supported in our player and are described in the related tutorial, setting up Ads with our player is easy to do.
Considering there is already such a large choice in advertising standards, is there really a need for yet another approach?
The simple answer to this question is: Yes. Without going into too much detail, nowadays most commonly used standards share one major disadvantage: They can be detected and blocked by the client. Although ad providers have come a long way in skillfully disguising ad content, the ongoing race between them and the manufacturer of ad-blockers has given content publishers many sleepless nights. From their perspective every unplayed ad corresponds to a potentially loss of ad-driven revenue. Keeping in mind that the usage of ad-blocking software is not limited to a small number of geeks (anymore), but is increasingly utilized by “normal” users, this can be a big threat for ad driven businesses.
In contrast to the approaches mentioned above, which stitch together the ad and non-ad content on the client side, server side ad insertion intercalates ads on a CMS level. Therefore the client receives a continuous stream with a smooth and broadcast like transition between ad and content video. In practice this can be done using mechanisms called Multi-Period and Discontinuities in adaptive streaming technologies, like MPEG-DASH and HLS. These concepts enable you to split up one stream into different parts (called periods), e.g., ad and non-ad content. Our most recent player version is capable of interpreting such periods and plays different content types in a smooth manner without visual transitions.

New Skinning Possibilities and Performance Improvements

Much like the smell of a (good) wine, the skin is the first impression a user gets from the player. But the player user interface has to be more than “just” good looking. It should be intuitive and enable interaction in a simple manner. Usually more functions than play/pause are needed. Besides simple things, like seeking or time-shifting and changing the volume, subtitles and multi-audio selection or playback speed may be required. For a modern online video player, there are many feature requirements. Another challenge is multi-device compatibility and consistency, in other words, the player has to look (and “feel”) the same on different devices, such as desktop, mobile, TVs, etc. As discussed in our post on building a modern HTML5 video player, all these aspects need to be considered when choosing the right player.
Within our new v7.0 release we have made several major changes regarding skinning. First, and maybe most prominently, the default user interface has been changed. The new and open source available skin, does not only have a fresh look, it also comes with various enhancements and additional features, like a recommendation screen, title and asset information placeholders, a playback speed control and many more. But the changes are more than just visual. The new skin is entirely built using TypeScript.
Not only has the user interface received a major update but the core player has also been refactored to some extent, with low startup delay and performance improvements in mind. In this regard we have been able to reduce the time between hitting the play button and when the first frame of the video is displayed (startup time) by another 250ms. This is especially important, because with each incremental delay of 1 second the abandonment rate increases by 5.8%.
There has also been a change in the basic structure of the player framework itself. Up until now, the player bundle included five physical files (neglecting the two files related to the skin). The bitmovinplayer(.min.js) – loaded first – and was responsible to check device and browser capabilities, user configuration, etc. to decide which player (HTML5/JS based or Flash), as well as which plugins (e.g., VR) need to be loaded. Due to the ongoing movement away from Flash, in the vast majority of cases, the HTML5/JS based player is chosen. In v7.0 we have decided to remodel our design and have removed two unnecessary files and therefore the computational and timing overhead of additional requests.

Custom Adaptation Logic

Creating an adaptation logic that fits all use cases for all of our customers is impossible – trust me we tried it ;-). As we learned that we cannot make every customer happy with a single adaptation logic we started to draft ideas around extending the flexibility of our players adaptation process. At first we added special parameters that you can use to tune the startup behavior of the player (i.e., setting a preferred startup quality), setting a minimum and a maximum bitrate, restricting the adaptation to the current window size, etc. This in itself helped a lot of our customers, but it was still not flexible enough for some. Therefore we decided to give our customers full control over the adaptation logic through a callback based interface. This means that before we download a segment a callback called onVideoAdaptation/onAudioAdaptation will be triggered where our users can register their own functions. This callback provides the current decision of the adaptation logic, i.e., which bitrate and resolution should be downloaded next. In the function that you register you could now overwrite this decision and basically decide for each and every segment which bitrate should be downloaded.
This allows you to create your own adaptation logic and we will also provide several different ones that can be used and also configured or rewritten through JavaScript. An example could be the following buffer based logic:

var currentQuality;
var sameRepCount = 0;
...
adaptation : {
  desktop: {
    onVideoAdaptation: function(param) {
      var qualities = player.getAvailableVideoQualities();
          currentQuality = currentQuality || qualities[0];
          var nextBitrate = currentQuality;
          var bitrates = qualities.map(function(quality) {
            return quality.bitrate;
          }).sort(function(a, b) {
            return a > b;
          });
          if (player.getVideoBufferLength() > 20 && sameRepCount >= 5) {
            // get next better quality if buffer is full (> 20 s) and played the same representation 5 times
            nextBitrate = bitrates[Math.min(bitrates.indexOf(currentQuality.bitrate) + 1, bitrates.length - 1)];
            sameRepCount = 0;
            console.log('switch up to bitrate ' + nextBitrate);
          } else if (player.getVideoBufferLength() < 10 && sameRepCount >= 1) {
            // get next lower quality if buffer is less than 10s and keep that for at least another segment
            nextBitrate = bitrates[Math.max(bitrates.indexOf(currentQuality.bitrate) - 1 , 0)];
            sameRepCount = 0;
            console.log('switch down to bitrate ' + nextBitrate);
          } else {
            // keep the same quality
            console.log('keep same bitrate (' + currentQuality.bitrate + ')');
            sameRepCount++;
            return currentQuality.id;
          }
          currentQuality = qualities.filter(function(quality) {
            return quality.bitrate === nextBitrate;
          })[0];
          return currentQuality.id;
    }
  }
}

This buffer based logic is very conservative. It will switch only to the next higher quality if the buffer is filled with at least 20 seconds of video and if the current quality has been downloaded 5 times. This will make the adaptation process very smooth as there will be fewer switches and no buffering, because 20 seconds is in the buffer in case the decision was wrong. On the other hand if the buffer contains less than 10 seconds of video the logic will switch down to the next lower quality and keep that quality for at least another segment. This will work nicely if there are no rapid bandwidth changes, as you would expect on fixed access connections. However, it could potentially yield problems in mobile scenarios where you need to switch down more aggressively to prevent buffering. BuFor those cases you could design your own mobile logic. If the buffer is in between 10 and 20 seconds the logic will simply download the current quality and stay at its current quality level.

Although this might not be the most sophisticated example, it illustrates how easy our default ABR algorithm can be modified, or customized entirely. So, if you have ever thought about applying different adaptation schemes on different devices, or for a different user-base, etc. Bitmovin’s new player enables it.
Coming soon
For beginning of 2017, we already have more interesting features planned, like a handy debug mode for development, updates to the Chromecast version of our player, and MPEG-DASH and HLS backup stream handling, which enables switching between different stream sources in an error case. Furthermore, we planned to integrate means for slide synchronization, making use of the EXT-X-PROGRAM-DATE-TIME attribute of HLS playlists. So, stay tuned!

All the best,

Reinhard and the Bitmovin Team.


The post Bitmovin HTML5 Player v7: 360° playback with HLS on iOS, server side ads, custom adaptation, new skin and more appeared first on Bitmovin.
]]>
					
		
		




			
		
		
		https://bitmovin.com/blog/hls-news-wwdc-2016/
		
		
		Wed, 15 Jun 2016 21:19:10 +0000
				
		
		
		
		
		http://bitmovin.com/?p=8964

					Apple introduces fragmented MP4 in HLS – a small step for Apple but a huge step for video streaming services HTTP Live Streaming (HLS) is a very important part of our service, (as you can see from our latest HTML5 Player release) so when we heard the news from WWDC16, that Apple’s HLS protocol will be extended to support...

The post WWDC16: HLS Supports Fragmented MP4 – and Becomes MPEG-DASH Compatible! appeared first on Bitmovin.
]]>
										Did you know our video player guarantees playback quality on any screen through our modular architecture, including low-latency, configurable ABR and Stream Lab, the world’s first stream QoE testing service? Check out the Bitmovin Player to learn more.

Apple introduces fragmented MP4 in HLS – a small step for Apple but a huge step for video streaming services

HTTP Live Streaming (HLS) is a very important part of our service, (as you can see from our latest HTML5 Player release) so when we heard the news from WWDC16, that Apple’s HLS protocol will be extended to support fragmented MP4, I think it’s safe to say that we were even more excited than the Apple technicians themselves!
Although Apple still forces content providers to make use of HLS streaming on iOS for assets longer than 10 minutes, the step to introduce fragmented MP4 can be a huge advance from an encoding perspective. Up to now, it has been necessary to encode content in different formats, to maximize browser coverage and reach most of today’s end-user devices. This increases the storage footprint of your content by 2x and reduces also CDN efficiency as content cannot be effectively reused across devices.
In more detail, to enable playback on e.g,. iOS devices, you need to multiplex your content into MPEG-2 Transport Stream, which is (was) required by HLS. You also need to multiplex your content also into fragmented MP4 format to enable native HTML5 playback with MPEG-DASH on e.g., Google Chrome, Firefox, Android and other devices. But with the step towards the usage of fragmented MP4s in combination with HLS, it will be sufficient to multiplex your encoding once to fragmented MP4 and simply use the produced segments for both technologies, HLS and MPEG-DASH – only the manifest files will be different.
So, what will a HLS m3u8 look like with fMP4 segments, as they are used by MPEG-DASH as well. Here is the example directly from the WWDC16 keynote, pretty straight forward:

Apple already published a HLS test asset, using fragmented MP4 segments, which is available at their website, where additional guides and documentation about HLS can also be found.

MPEG-CENC with HLS

But that’s not all! Apple goes even further and will also support DRM-protected fMP4 segments using MPEG-CENC (Common Encryption) in HLS, which is used by MPEG-DASH as well, and supported within all major browsers. Here you can find a recent introduction to DRM on the web, and here you can find a compatibility overview for DRM-systems and browsers, seems we have to update them soon with some more possibilities.

Offline HLS Playback & Offline FairPlay

HLS now also supports offline playback which can be used to persist videos on the user device that can be watched later when no internet connection is available, e.g., in the airplane, train, car, etc. The application has full control of which renditions will be downloaded. This is especially useful for media files that contain different audio tracks and subtitles as the application could download only the tracks that are important for the user. Moreover, offline playback could also be used with FairPlay content that can now be played back without a connection to the license server.

In-Playlist Timed Metadata

HLS now also supports a new metadata format which is called In-playlist timed metadata. It has similar features to ID3 tags but unlike ID3, the metadata information is available in the manifest and not packaged in the media stream. This makes the information available when you download the manifest, which means you get the entire information in advance and therefore it can be used for things like navigation control. It also contains bindings for SCTE-35 tags that can now be carried within In-playlist timed metadata.

Conclusion

Apple announced some very nice HLS features at WWDC16 that could have a huge impact on the media industry. In summary, the most important new features are:

Support for Fragmented MP4

• makes HLS content compatible with DASH and vice versa
• encode and multiplex your content once and use it with HLS or DASH
• increase CDN efficiency while reusing the same content for HLS and DASH
• reduces the storage footprint of your encoded content by half
• minimal changes in HLS playlists

Support for MPEG Common Encryption (CENC)

• supports FairPlay streaming with cbcs mode
• first step to harmonize all DRM technologies
• in the future you should be able encode and encrypt your content once and use it with Widevine, PlayReady, PrimeTime and FairPlay

Offline HLS Playback

• configurable downloading of media renditions
• can be used for watch later functionally in airplanes, trains and other places where no internet connection is available

Offline FairPlay Playback

• encrypted content can be played back without internet connection
• assets must be marked in the backend to allow offline playback

In-Playlist Metadata

• same feature support as ID3 tags
• entire information when you download the manifest and therefore it can be used for things like navigation control
• contains bindings for SCTE-35 tags

We at Bitmovin are now working on some demos using HLS with fragmented MP4 with our player and encoding, to show the huge impact to the streaming ecosystem and its potentials, so stay tuned!
More insights about Apple’s streaming protocol in general can be found in one of our recent blog posts and a detailed overview of streaming technologies and covered platforms in our support section.
Update 17 June 2016: The Bitmovin team has already prepared a demonstration of FMP4 in HLS.

See it in Action!

Below you can see the Bitmovin HTML5 Adaptive Streaming Player in action, playing Fragmented MP4 through an HLS manifest.
Please note that this demo will work on Mac iOS 10 and above, and for PC users, all recent browser versions are compatible, including Edge, FireFox, Chrome and Safari.

All the best,
Reinhard & the Bitmovin Team!

Popular video technology guides and articles:

• Back to Basics: Guide to the HTML5 Video Tag 
• What is a VoD Platform?A comprehensive guide to Video on Demand (VOD)
• Video Technology [2022]: Top 5 video technology trends
• HEVC vs VP9: Modern codecs comparison
• What is the AV1 Codec?
• Video Compression: Encoding Definition and Adaptive Bitrate
• What is adaptive bitrate streaming
• MP4 vs MKV: Battle of the Video Formats
• AVOD vs SVOD; the “fall” of SVOD and Rise of AVOD & TVOD (Video Tech Trends)
• MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
• Container Formats: The 4 most common container formats and why they matter to you.
• Quality of Experience (QoE) in Video Technology [2022 Guide]

The post WWDC16: HLS Supports Fragmented MP4 – and Becomes MPEG-DASH Compatible! appeared first on Bitmovin.

Apple HLS File Formats

Apple HTTP Live Streaming (Apple HLS) uses M3U8 playlists as a manifest file for their content files, which is an extension of the M3U format used for MP3 playlists. HLS is the only system that uses MPEG-2 Transport Stream (MP2TS) which adds a significant overhead in relation to the audio/video data, instead of MP4 or another ISO Base Media File Format based container. MPEG-2 TS consists of packets with 188 bytes in size, where each packet has headers with a varying size of 4 to 12 bytes. Therefore, the overhead caused by these headers increases proportionally with the segment size, which means that relative overhead does not tend to zero with increasing bitrates. Moreover, each MPEG-2 TS stream consists of several other data beside audio and video, such as Program Association Tables that introduce additional overhead. Additionally, audio and video streams are encapsulated in Packetized Elementary Streams (PES) which introduces an extra overhead per audio sample or video frame.

Manifest – M3U8

Apple HTTP Live Streaming (HLS) uses an M3U8 playlist as its manifest, which is a little bit different to the other approaches, e.g., MPEG-DASH or Microsoft Smooth Streaming that use an XML based manifest. VOD content with one quality can be described through the basic playlist feature, which means that the individual segments URLs are available in the main M3U8. If you want to offer multiple qualities as intended with adaptive multimedia streaming, you will have to use the variant playlist. Typically, a variant of a stream is the quality of the stream in a specific bitrate and/or resolution. Variant playlists are structured in the following in that there is one root M3U8 that references other M3U8s that describe the individual variants (qualities). The root M3U8 will then contain several EXT-X-STREAM-INF tags that indicate that the following URL is referencing another M3U8 playlist. Additionally, the EXT-X-STREAM-INF tag could contain several attributes such as bandwidth, codec, etc. Advertisements are supported in HLS through the EXT-X-DISCONTINUITY tag. This tag indicates a discontinuity in the media stream between the actual media segment and the one that follows. Furthermore, a basic encryption method is also available that allows AES-128 encryption of the media segments. The key server can be signaled in the M3U8 with the EXT-X-KEY tag and the URI attribute.

Generate your own Apple HTTP Live Streaming (Apple HLS) Content

The get started link below offers you a free trial with Bitmovin. With our Cloud Encoding Service and HTML5 Adaptive Streaming Player, you can get up and running with your first Apple HLS in a matter of minutes. Try it now!
Further Readings:

• Video Developer Report 2019
• Cloud Encoding Datasheet
• Video Player Datasheet
• Video Analytics Datasheet

The post Apple HTTP Live Streaming appeared first on Bitmovin.

Considering CPU in Adaptation Decisions

Interestingly, Microsoft also includes the CPU utilization as an indicator for the stream switching decision which is especially valuable for mobile devices such as smartphones and tablets. This means that if the CPU utilization is high, the client reduces the stream quality and resolution which furthermore reduces the CPU performance needs of the decoding process and guarantees a continuous decoding without stalls. For those devices, CPU adaptive streaming becomes useful in multiple ways. First and foremost, they have limited CPU as well as GPU capabilities and sometimes even restricted decoding features, e.g., only H.264 baseline profile support. In such cases, the client can choose the representation which fits best for their resources and provides the best capability and quality of experience to the user. Nevertheless, mobile devices become more and more powerful due to high-end mobile CPUs. However, the energy consumption of mobile video playback still remains high, which leads to the next use case considering the CPU of a device in the stream switching decision. Due to the restricted battery capacity of most mobile devices, it may also be necessary to switch to a lower complexity stream during playback to reduce energy consumption of the decoding process and therefore extend the remaining running time of the battery. Such lower complexity streams could be produced by reducing the bitrate and/or resolution on the one hand. But when going into more detail in video coding, there are further and more sophisticated possibilities. So in the case of H.264/AVC, it is conceivable to choose lower complexity entropy coding methods, e.g. the usage of CAVLC instead of CABAC, use a lower sub-pixel precision or to disable the deblocking filter. Due to such methods, the CPU utilization of the video decoding process may be reduced significantly and as a consequence of this, the battery of the device lasts longer.

File Formats

Microsoft Smooth Streaming leverages three different file types for their streaming system which will be described in the following:

• Fragmented MP4 files for media content: *.ismv and *.isma
• Server manifest file:  *.ism
• Client manifest file:  *.ismc

The media files of Microsoft Smooth Streaming are based on fragmented MP4. MP4, which is based on the ISO Base Media File Format (IBMFF), is basically organized using boxes as units for data as well as metadata and offers a wide range of arrangement possibilities of those boxes in a file. Especially for streaming scenarios, MP4 offers the possibility to split up the metadata and media-data of a continuous stream into several fragments, each consisting of a metadata and a media-data block, also labeled as fragmented MP4 (fMP4) in the context of Smooth Streaming. Therefore, it is possible to store separate media segments, which correspond to one or more Group of Pictures (GOP), by using a Movie Fragment Box (moof) and a Media Data Box (mdat).

All chunks of the same representation are stored together in one MP4 file that allows random access. This file starts with a Movie Metadata Box (moov) containing metadata information for the whole file, followed by the different fragments. At the end of the file, there is a Move Fragment Random Acces (mfra) Box enabling fast random access to the different fragments.

Those chunks are requested via the IIS webserver which carries out an address translation of the incoming URL and responds with the appropriate Movie Fragment. These URLs of the segment requests are in the following form, where <bitrate> signals the representation and <segment time offset>  signals which segment is requested. An example request could look like this:

http://cdn.bitmovin.net/content.ism/QualityLevels(<bitrate>)/Fragments(video=<segment time offset>)

At this point, an IIS webserver is necessary. Although HTTP 1.1 range requests would be an alternative, working without any address translation on the server side. Unfortunately, this address translation seems to be intended to limit the use of Smooth Streaming to CDNs using Microsoft products.
In addition to the media files, Microsoft Smooth Streaming uses a client manifest file containing the metadata of the different representations and basic chunk descriptions of the video stream. This file is based on XML and basically contains the information about the used codec, bitrate, resolution, etc. of the different available quality versions of the content. Furthermore, there is a server manifest file used for the relationship of representations, segments and contained media tracks, which is not transferred to the client and only used by the IIS. It contains the information about the bitrates, the associated filenames/paths on the server, track ids and further metadata. This file is used for the URL translation of the HTTP requests to media files. It is necessary because the HTTP requests of Microsoft Smooth Streaming do not contain file names or byte ranges for the segments and so they have to be translated to a file read operation of the IIS using this server manifest file. As already mentioned, this mechanism could be omitted in general using HTTP/1.1 range requests.
Follow Bitmovin on Twitter: @bitmovin

The post Microsoft Smooth Streaming appeared first on Bitmovin.