These days, it’s hard to imagine communication media without using audio and video content. Moreover, all significant events are broadcast in live mode for a wide audience all over the world. Since this audience is constantly growing, it’s really important for content providers to be aware of the quality of their media stream delivery and know the breaking point of their streaming services. To make sure a streaming service can handle an expected audience, it’s a good idea to simulate a number of users accessing the media stream.

Load Testing Approaches

There are multiple ways that audio or video content can be delivered. Users can stream media in a web browser using any number of online media streaming services, such as YouTube or Netflix. On the other hand, media streams can be accessed via static URLs in a browser or in the media players that support network connection and external links, for example, the VLC media player. Therefore, the right load testing approach should be chosen to set up a load test correctly. In this article, we will focus on two main approaches for testing audio and video streaming service performance and scalability using LoadView:

  • Streaming media load testing using an actual media resource path.
  • Real browser-based load testing.

Access to a stream source can be provided by a static RTP link to the media file. For example, the media source can be linked directly from the HTML, similar to the images on a web page. Generally, one can play a static stream in any browser that supports the corresponding codecs, or by a compatible online or desktop media player, such as Windows Media Player or VLC.

Example of static RTP links:

https://multiplatform-f.akamaihd.net/i/multi/will/bunny/big_buck_bunny_,640x360_400,640x360_700,640x360_1000,950x540_1500,.f4v.csmil/master.m3u8
https://cph-msl.akamaized.net/hls/live/2000341/test/master.m3u8

If you have a static RTP link to the media source file or playlist, it is recommended to set up a Streaming Media load test. LoadView will hit the static URL with a number of concurrent users trying to download the first 30 seconds of the stream. If the source server is unavailable, or the system failed to download the stream playback, an error will be generated.

Note that in some cases, a stream RTP link can be generated randomly by the server for each new streaming session and can’t be used as a static stream URL in load testing. In this case, select a real browser-based load testing strategy.

Real Browser-based Load Testing

Sometimes, a media file URL is not publicly available. For example, a media stream application can require authentication to play the stream. Since the stream URL is available for only logged in users, it will be refreshed every time when the authentication token expires. In terms of load testing, it means that you need to provide the user credentials to access the media stream file on each load test session.

At the same time, many media content providers use plugins or embedded native video players (e.g., proprietary YouTube player) to stream audio and video content. In this case, the link to the streaming source is not available directly from the page HTML.

In the cases when a static RTP link to a media source is not available, opt for web application UI testing in a real browser. For these purposes, LoadView provides the EveryStep Web Recorder to capture the video of media streaming in the browser window.

To create the load test, select the Web Applications load testing type and record the script:

  1. In the Everystep Web Recorder, navigate to the web page that contains a streaming media and select the play button to start streaming.
  2. Stop recording and click OK in the pop-up to skip playing the script.
  3. Go to the Script Code section in the Everystep Web Recorder, and right-click the last script line.
  4. From the inline menu, select Delay and set up the delay in the end of the script. The system will wait for the streaming playback during the specified time duration on a test run.
  5. Save the script and proceed with the load test scenario configuration.

To specify a the appropriate delay value, take into account the ramp-up rate of the number of concurrent users and the type of streaming. For example, in the case of testing a live stream, users tend to stream considerably longer than playing saved content. In general, the delay must be long enough to simulate concurrent streaming.

Once the load test has started, browse and review the media stream page. This approach allows you to catch any quality losses in audio or video under applied load as they appear for real users in real-time.