Viewing HLS Adaptive Stream Behaviour
In this post, we will take you through the process of viewing the adaptive switching behaviour of a StreamShark stream using the Google Chrome browser. This will give you an insight into how the browser displays our html5 HLS live streams under various network conditions.
You can test the playback of one of your own streams by following this tutorial and using the html5 playback URLs of your preferred stream.
Enable the developer console
First, open up a new Chrome browser tab. Once the tab is opened, click on the Chrome settings icon (top right) and navigate to More Tools->Developer tools.
Clicking on the Developer tools option opens a panel at the bottom of the browser window. This panel contains a useful bunch of tools for software developers or anyone else interested in what is going on in the browser).
Load the URL for your live stream preview
Stream Setup: I’ve created a stream with two video qualities, 600kbps and 2000kbps. 64kbps AAC was selected for the sound format. Therefore, the combined audio/video stream bitrates are 664kbps and 2064kbps.
Stream Status: I’ve started my broadcast software and I’m streaming to my StreamShark stream using a pre-recorded video.
Load your html5 stream playback URL. If we click on the ‘network’ menu within the bottom panel, then click on ‘XHR’, we can see the network requests being made by the browser to fetch the data for stream playback. Note the HLS manifest files being loaded (*.m3u8). These manifest files tell the player which video segments should be loaded by the player (*.ts files). Click on the play icon to begin playback. The player will then commence playback, switching quality based on network conditions. My computer has enough bandwidth to play the higher 2064kbit stream, hence you can see the 2064* manifests being loaded below.
Simulate different bandwidth conditions
Simulate insufficient playback bandwidth
We can simulate a low bandwidth network by throttling the network connection (e.g. a mobile phone connection). Click on the ‘No throttling’ dropdown to select some canned connection speeds.
Let’s throttle the bandwidth right down to a terrible 2G connection (250kbps). As this is well below the 664kbps stream bandwidth, we will start to see some buffering as indicated by the loading icon (spinning circle). Note: the restricted bandwidth increases the time taken to load the segments beyond the 10s playback length of the segment. This causes buffering as the browser can’t load the segments fast enough to be able to display them in sequence. Hence, it is very important to have lower quality streams if you need to support clients with limited bandwidth.
Simulate low playback bandwidth
We can simulate situations where a client has a fair connection, but not enough bandwidth to play the highest quality stream. For this, select the ‘regular 3G’ option (750kbps) from the throttle dropdown. The ‘regular 3G’ option should be high enough to play the lower quality 664kbps stream but not enough to play the 204kbps. Note that the manifest and segment files loaded by the player should only be the 664kbit stream files. You’ll observe that in this case, playback no longer buffers.
Verify normal playback bandwidth
Flick the throttle option back to ‘No throttling’. You should see the player start loading the 2064kbit manifests and segments as it adaptively jumps to the higher bitrate stream. If we click on one of the segment files we can view the HTTP headers. The X-Cache: HIT header entry here indicates the CDN is caching our segments and we have been served a segment from the cache.
Summary
You have now gained an insight into the playback process involved when viewing HLS streams. Picking appropriate bitrates to cover the expected bandwidth available to your clients is vital for uninterrupted viewing, especially for mobile devices.
A general rule of thumb when using multiple bitrates is to ensure each additional stream uses a bitrate roughly double that of the lower quality stream. Other video parameters such as resolution, frame rate and the devices used by your audience may also need to be taken into account when choosing your bitrates. Some experimentation may also be required.
We do not recommend having very similar bitrates (such as 664 and 764) as this may result in the player constantly chopping between the two bitrates if the available network bandwidth is unstable.
If you have any questions or would like us to cover more topics, please leave your question/comments in the comments section below.
