Introduction to Adaptive HTTP Streaming and Load Testing

Adaptive HTTP Streaming media is split up into many small segments (or "chunks"). Each media segment contains a few seconds of the media. Segments are loaded into a media player as they become needed. Media segments are fetched from a server using regular HTTP requests. The media is usually provided in several qualities (or bitrates) to accommodate playing the media during different network conditions.

The advantages of Adaptive HTTP Streaming is:

Adaptive loading

The media is available in different qualities. Segments with the same index has the same duration for all qualities, making it possible for the player to change media quality at the end of each segment played.

Dynamic Streaming with quality changes

Meta Data

PureLoad/PureTest, and of course real media players, first reads meta data about the stream to determine what qualities are available and to construct URLs for the media segments to be downloaded. Meta data files are usually referred to as Manifests. Manifest files are fetched using HTTP requests.

Different streaming protocols have different formats for the manifests. Some streaming protocols may also split manifests into several files making it necessary to do several HTTP requests to acquire the information. Other protocols use only one manifest file for all the necessary information.
Meta Data Manifest Structure

Audio and Video

Some streaming protocols have different streams for audio and video. This allows e.g. for supporting different languages. There is one media playlist manifest for each audio stream as well as for each video stream. When separate audio is present, audio and video are downloaded and run in parallel.

Load testing Adaptive HTTP Streaming

Manually Adapted Quality

A real-world media player will choose to download Media Segments of the best possible quality with respect to network throughput. As network throughput increases, higher quality media will be downloaded. This behavior is not desirable during load testing since test runs must be comparable.

When constructing a HTTP Streaming Load Test, a fixed media quality is chosen for a fixed number of Media Segments. In this way two test runs will demand the exact same amount of bandwidth. This makes it possible to compare test runs on, for instance, things like the total slack/sleep time or the number of failed downloads.

To mimic adaptivity the media quality can be set up to change as desired using the HttpStreamingXyzSetQualityTask (example here). This means that you could have a scenario that always plays like this:
Fixed quality changes to mimic adaptive streaming

Automatically Adapted Quality

In cases where you do want the test to automatically adapt the quality depending on actual network bandwidth, this can be done by configuring an Expected Bitrate, Downshift Threshold, Upshift Threshold and Consecutive Threshold Exceedings in the HttpStreamingXyzSetQualityTask.

When a segment is downloaded the actual bit rate is measured. If the actual bit rate is lower than the downshift threshold for the specified number of consecutive times, a downshift will occur. And similarly if the actual bit rate is higher than the upshift threshold.

For example say that an expected bit rate of 1000 kbits per second is specified. If the bit rate downloading a segment is more than 1500 kbits per second an upshift will be done, etc.

Down or up-shift will only be done if possible (as specified by read manifests) and never to a higher quality than what is set as Media Quality in the HttpStreamingXxxSetQualityTask.

Audio streams are loaded automatically

To simplify test set up and execution there are no parameters to control audio in the load tests. If there is separate audio media, the first available audio playlist will be chosen. Audio media is then downloaded together with video in a way that guarantees the audio to run at least as long as the loaded video segments.

A closer look at load test execution

A comparison between load test execution and player behavior.
PureLoad/PureTest loads a Media Segment after the previous segment has finished. It then sleeps the time that remains of the currently loaded media segment's running time.

Test execution diagram

And with separate audio it looks like this:
Video + audio test execution diagram