HTML5 DASH and buffering options
We are now able to retrospectively add DASH packaging where previously only HLS was generated. If you are not familiar with DASH or HLS, they are rival formats for streaming video using HTML5 (HLS vs DASH). Both offer adaptive streaming, letting the quality of the video automatically change seamlessly during playback depending on the available connection speed. DASH is selected when its manifest is available, else we fall-back to HLS, and finally to an MP4.
DASH is now supported on all the major desktop browsers including Google’s Chrome, Mozilla’s Firefox, Microsoft’s Edge and IE11, and Apple’s Safari.
If the connection becomes poorer, a lower quality rendition is automatically selected which should avoid the dreaded “buffering”. Plus, our HTML5 video player supports giving the viewer the option of overriding that decision. They can manually select a rendition such as “360p”, regardless of their connection speed.
Buffering goal
As part of this update we added a new player setting to let you decide how much of your video the player should attempt to buffer. This gives you greater control over how much data is transferred. By default we set the goal as ten seconds. We have found that to be a reasonable compromise. So that means when the player loads, it will load the first ten seconds of the video so it is ready to play as soon as the viewer wants to. Then, while the video is playing, the player will continually make sure that there is ten seconds of video ahead of their current position. The reason why this setting is useful is you may want to increase it if you would like the player to load further ahead - for example you may want the next sixty seconds of video buffered in advance. A larger buffering goal may suit lower speed connections, where there is a greater chance the viewer will catch up with the buffer - at which point the video may stall as it attempts to load the next segment. However a longer buffering goal does result in more wasted data - since the player is downloading part of the video that the viewer has not watched, and may not do so.
To allow more flexibility and more opportunity for switching renditions during playback, we have reduced the segment size too. This makes each separate segment within the DASH manifest smaller in size, meaning it downloads faster and so is available to play sooner. This does come at the expense of having to make more HTTP requests, however since we make extensive use of the new HTTP/2 protocol (where requests can be executed in parallel and with far less overhead than the older HTTP/1.1) this overhead is minimised.
The buffering goal is set within your player settings. To modify it, simply click on Content > Players, and then on the player your content is presented in. If you click on the relevant tab in the editor and scroll down, you should see the option to specify the number of seconds the player should attempt to buffer:
If you then watch a video presented in that player, assuming DASH is being used, you should see the bar showing the data buffered (the grey bar ahead of the round play-head) pauses roughly that number of seconds ahead of the play-head. So here, the player has indeed maintained that goal, buffering roughly 10 seconds of video ahead of where the viewer has currently reached:
There are a couple of things to be aware of:
1) The buffering goal is merely a target. Due to the segment length being longer than a single second, it may not be possible to exactly reach it.
2) iOS does not support DASH, nor the browser extensions needed to add support for it using JavaScript. As such, it plays the HLS variant and since this is played natively within its own built-in player, there is no option for us to specify the buffering goal. It is left to the OS to decide this for itself.
If you have any questions about using DASH within our online video platform, please contact us at [email protected]. You can try our business video hosting for free: click the button on the home page to request a trial.
Updated: March 5, 2017