Our player has been re-built from scratch. Our previous one had become increasingly bloated, becoming harder to manage and increasingly inefficient. The new player benefits from a plugin-style architecture and as such makes it far simpler to deploy additional modules as required. The interface looks very similar however there have been many subtle improvements including a new gradient background, a new volume control and a play-head to make seeking much easier. There are further improvements planned to make it even faster too.
One of the main reasons for developing our new player was to make it far simpler to switch how both HLS and DASH were managed. Both are under development and so it was important to be able to easily switch to the latest code-bases without having to make extensive changes to the rest of the player. If you are not familiar with HLS and DASH, they are rival formats for delivering video. HLS is short for HTTP Live Streaming. As its name suggests, it is used for live streaming, however it can also be used for video-on-demand (VoD). DASH is short for Dynamic Adaptive Streaming over HTTP and again, can be used both for live and for video-on-demand. We have written a short article comparing HLS vs DASH if you would like to know more about the technical details.
Streaming protocols like HLS or DASH have many benefits over simple progressive download of a single MP4 file. The key benefit is adaptive streaming. That is the ability for the stream to adjust to the available network conditions without interruption. The stream contains multiple versions of the same video and if the connection speed fluctuates, the quality can be adjusted higher or lower to avoid delays for the dreaded “buffering”. However there are many other benefits, including more efficient use of bandwidth (avoiding wasted bandwidth on pre-fetching content that is not watched) and support for content protection technologies like DRM.
The roll-out of HLS also means that we could offer an extra layer of protection. For larger enterprise packages that are using the Cloudfront CDN, we can support using a cookie to protect individual segments. A cookie is simply a small bit of data stored within your browser. These file cookies do not track or identify your viewers - they are simply used to authenticate that they are permitted to access the file requested.
An additional benefit is that if someone sent the direct URL to a manifest or segment to someone else - or included it on their own web page - the link would fail immediately (as opposed to expiring X minutes later) because they would not have that cookie our system sets.
If you would like to find out more about how this works and how it could benefit your organisation, please do visit www.vidbeo.com and request a trial. Or you can contact us directly.
In addition to these primary updates, we have also resolved many small issues throughout the online video platform to provide the best professional video streaming solution we can. One such issue that we had noticed was that when users requested a custom frame from a video (to replace the one our system picks for them as part of its transcoding pipeline) it would often take a long time to return. It was being generated very quickly - it just appeared to take a long time due to caching. The previous image file was cached both in the viewer’s browser and at our end, from the content delivery network’s edge servers. Clearing both is simple to do, however takes additional minutes. Now that process should be almost instant.
We have covered quite a lot and so if you have any questions or would like a free trial of the online video platform, please visit www.vidbeo.com. Alternatively you can always email us at [email protected].
Updated: June 29, 2016