Performance Testing Low Latency Dash servers with UbikLoadPack

on 30 October CI, CLOUD, DEVOPS, MPEG-DASH and Tags: , , , , with 0 comments

We are proud to announce the new release 7.2.0 of our VideoStreaming plugin.

Thanks to this new version, the performance testing of Low Latency DASH servers was never so easy.

In this blog we will first introduce the existing implementations of Low Latency Dash and then show how our plugin allows you to easily test them.

Low Latency Dash Legacy

The goal of the Low Latency Dash Legacy is to make the availability date of the next chunk earlier than the time it will be emitted so that the player will ask for the chunk in advance. This will make the player receive the chunk as soon as it is available.

As shown in the figure above describing the timeline of a chunk, using Low Latency DASH saves time as the player must not wait for the chunk to be available to request it.

In the DASH manifest, a new variable is declared as availabilityTimeOffset (in seconds) which must be subracted from the availabilityTime of the chunk to know the anticipatedAvailabilityTime.

It allows the client to know when the chunk is supposed to be available on the server and request it earlier. As this time represents a time before the chunk is really available, the server will hold on to the request and send the chunk when it becomes available.

In summary Low latency Dash allows a gain in the following fields:

  • Connection establishment already done at the time the chunk is downloaded
  • SSL Handshake already done at the time the chunk is downloaded
  • The chunk is downloaded as soon as the server makes it available
  • Low latency Dash advises to use shorter chunks (similar to CMAF) also contributing to reduce latency

If you wish to implement this in your live streams, the specification of this feature is available in the following document:

Low-Latency Service Offering

In Low-Latency Service Offering, there are some additional constraints compared to Legacy Setup.

First, there is a new element, ServiceDescription, which is mandatory and which must contain a Latency element with attribute target. Optionally, Latency can contain max and min attribute.

ServiceDescription may also contain a PlaybackRate element with at least max or min attribute, or both.

This addition allows a player to adjust its latency to meet the target latency. This adjustment is done by modifying the player speed within the range PlaybackRate@min and highest speed PlaybackRate@max.

To do so, it has to compute its actual latency :

Then the player has to compare its actual latency to the target.

If it is lower it can slow down, respectively if it is higher it can speed up. Before speeding up, it must be sure to have enough data to play.

Indeed, if the player has not enough data, it will need to wait for further data and hence increase its latency.

Next, other elements which already existed are mandatory for this Low-Latency mode, such as:

  • UTCTiming with particular schemeIdUri
  • ProducerReferenceTime mandatory in AdaptationSet
  • Addressing Scheme must respect certain format, either @duration + $Number$, or SegmentTimeline + $Number$, SegmentTimeline + $Time$
  • and AdaptationSet must follow either Low-Latency Segment Adaptation Set or Low-Latency Chunked Adaptation Set

Finally, this mode gives recommendations, for example :

  • LeapSecondInformation is recommended
  • InbandEventStream with value of 1

More info on Low-Latency Modes for DASH

OTT and streaming services providers challenges

As you can understand, with introduction of Low Latency Dash, providers face multiple challenges:

  • Player will have more aggressive request rate if smaller chunks are used
  • Players requests will pile up waiting for chunk to become available
  • Fine tuning latency and speed rate is needed for Service Offering
  • Ensuring their software works accordingly and scales well

UbikLoadPack VideoStreaming Plugin

Hopefully, our UbikLoadPack plugin for JMeter comes into play to ease the work.

It achieves this goal by simulating how a video player is expected to request your server. It requests the manifest, parses it, requests the chunks and then simulates the reading as a real player would.

It makes the testing of Low Latency Dash streams easier as it does all the complex work described above Out Of The Box.

Provide the manifest URL of your low latency stream to the plugin, and the plugin will do the rest, no need to make a difficult test plan or to use scripting, everything is done internally.

All your energy can be put on on tuning your software stacks and architecture.

Reporting and Custom Metrics

You can see the manifest has been downloaded with several video chunks. and a VideoStreamingSampleResult has been generated. This element provides useful custom metrics.

In this version we introduced the speed rate metric which will allow you to better understand user experience with Low Latency Dash.

The response time of the VideoStreamingSampleResult is the sum of the response time of each chunks and manifests downloaded during the period set in the VideoStreamingSampleResult frequency field.

Aside from the metrics provided by Apache JMeter, the plugin also adds custom metrics relative to video streaming such as :

  • the buffer fill time
  • the lag time
  • the lag ratio (with and without buffer fill time)
  • the speed rates (for Low-Latency dash only)

About UbikLoadPack:

You’ll probably also like: