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:
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.
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.
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.
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:
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.
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 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.
And with separate audio it looks like this: