QC for Adaptive Streaming Content in file-based workflows

Introduction

Increasingly, viewers are now consuming content over heterogeneous devices and networks. This ranges from low end hand-held devices running over traditional wireless networks to high-end televisions streaming HD content over IP networks. Many of these viewers/users also sit behind corporate firewalls that do not allow anything other than HTTP content to pass through. Content providers serving these customers need to ensure an optimum and uninterrupted experience for the viewer on these heterogeneous platforms. Clearly, the required content encoded properties are different for different devices & network conditions and no content with a singular encoded profile can meet the demands of all the viewers on these various devices and network speeds. This has led to encoding of multiple flavors/profiles of the same content, to meet the user needs. Consequently, content providers also need a platform that can automatically identify the most suitable profile of the same content for a particular viewer and can dynamically switch to a different encoded flavor of the content if the network or device CPU conditions are not optimum. This is becoming a necessary requirement, in the absence of which users will experience continuous interruption in their viewing experience, leading to severe degradation of the customer satisfaction.

Adaptive Streaming

HTTP based Adaptive streaming technologies such as Apple HTTP Live Streaming (HLS), Microsoft Smooth Streaming, and Adobe HTTP Dynamic Streaming are today’s answers to the above requirements. MPEG-DASH is also picking pace and is expected to become the standard in the near future for interoperability. All these technologies allow content providers to create multiple flavors of the same content that can be dynamically switched by player applications depending on local playback conditions. These conditions can be affected by changing network conditions, leading to insufficient playback buffer or the local CPU condition leading to frame drops.

Content preparation process for creating an adaptive streaming content passes through several steps as shown in the diagram below:

Each flavor shown in diagram above has multiple fragments, the format of which depends on the adaptive streaming technology. In case of HLS, each fragment of a flavor is a separate file. A typical HLS content looks like:

Following are the key encoding parameters that should be checked for adaptive streaming content:

• • Bitrate. CBR is typically recommended for organizations that are beginning to use Adaptive Streaming. But these organizations are likely to move towards using constrained VBR to achieve better quality. They need to ensure that data bursts are under a well-defined limit, otherwise the player may unnecessarily switch the content leading to poor viewing experience.
• • Resolution. Resolution of the content is decided based on the device resolution. A typical streaming content may consist of multiple resolutions for different display conditions. Content creators need to ensure that coded resolutions are as per specifications.
• • Profile/Level. Content may be encoded at different profile/levels depending on the capability of target display devices. Content creators need to check that profile/level constraints are respected; otherwise content may not playback properly on these devices.
• • Key frame interval & alignment. It is necessary that fragments across different flavors are perfectly aligned with key frame at the beginning of each fragment. Content creators need to ensure that this necessary condition is met; otherwise viewer experience can be severely affected.
• • Audio sampling frequency and bitrate. Audio configuration is chosen for optimum experience. Typically, a single audio profile is used for all the flavors because changes in audio properties may be easily noticed by the viewers, leading to degraded experience.

In addition to the parameters above, content creators also need to ensure that the quality of the content is optimum at different bitrates and resolutions. This is necessary in order to ensure the end user is satisfied with their experience. Some of the issues content creators may like to check before the content is published include:

• • Blockiness. Encoding artefact that may result due to encoding configuration
• • Freeze Frames
• • Unwanted Black Frames
• • Drop Frames
• • Audio Loudness. Audio levels should be under defined limits for optimum experience
• • Unwanted Audio mute or silence zones
• • PID Mapping. Different streams should be placed with proper PIDs

While the content creators need to check the above parameters for the content before it is published, the challenge for them is to perform efficient & effective QC on such content. Typical recommended fragment duration for HLS adaptive streaming content is between 3 to 10 seconds. Assuming duration of 5 seconds of each fragment, a two hour movie title will have 1440 fragments per flavor. If five flavors are created for a given content, then a total of about 7200 separate files need to be tested for one movie. A movie library with 1000 titles, translates to 7.2 million files! The content QC challenge is apparent for content creators and they need an efficient way of handling such content.

Pulsar Adaptive Streaming Support

Pulsar^TM allows content creators to QC adaptive streaming content in a fast, simple, flexible and integrated manner. Using Pulsar, all the above parameters can be easily verified. Pulsar treats one manifest file as one content; the user can simply provide manifest files and assign different templates to different flavors. Pulsar automatically extracts the content referenced from the manifest files and verifies all the flavors and fragments behind the scene while creating a uniform, integrated report for the entire content. For example, in the case of the 1000-movie library, Pulsar would create 1000 reports, and not 7.2 million reports (had the fragments been treated as separate files) which would be clearly unmanageable. Also, many issues span across multiple fragments and can’t be detected by treating fragments independently; Pulsar stitches all fragments and treat each flavor in an integrated manner.

The entire process of testing content compliance for adaptive streaming content is simplified by Pulsar. It is not only easier to set-up content QC using manifest files, but it is also very simple to use integrated Pulsar reports to make decisions on the content.

To summarize, Pulsar allows:

• • Easy QC set-up for streaming content by recognizing the manifest file as one content.
• • Flavor-wise QC rules, all your required tests can be tailored to each flavor.
• • Checking of issues that overlap fragment boundaries by treating a set of fragments as one content.
• • Manageable QC by producing one integrated report (per manifest file) for all the of fragments and flavors of a content.