Technological stability in a volatile OTT market
An Over the Top reaction to OTT changes?
(We’re sorry, it’s practically copywriting law that you include an OTT pun when you’re writing about OTT services. We promise there won’t be any more).
Market fragility demands technical stability
Just when viewers had started to take OTT for granted and the market seemed pretty settled, everything seems to have changed. Issues such as password sharing, season renewal strategy, investment in original content, and the increasing fragmentation of OTT providers into more niche content groups mean that where once there were two or three market giants who all-but-guaranteed their stake in the market, now the attention of audiences is up for grabs. A far more competitive market landscape and negligible switching costs mean that every business decision has the potential to bring about big consequences when it comes to audience retention. The market is more fragile than it has been for a while.
But what it also means is that on an engineering level, there is now absolutely no margin for error. If the ‘big picture’ policy decisions – password sharing, series renewal, subscription brackets, ad insertion – are putting customers on a knife-edge about whether they see a future in their subscription (subscriptions that many customers will have held for a decade), then it is very clear that any compromise to the fundamental technical quality of the service offered could end up being decisive. A hint of frustration over buffering, lip-sync lag or service interruption can be the difference between continuing or cancelling your subscription next month. Signal and network stability need to be absolute if broadcast businesses – be they OTT, IP, traditional or otherwise – are to have any hope of building their market share.
And of course, ensuring stability is where we at Bridge Technologies come in.
OTT: the basics
We assume you know the basics of OTT, but just in case you don’t: OTT simply refers to the delivery of media content using the public internet, as opposed to IPTV, which does the same through a privately managed network. Where the private management of IPTV networks allows for much greater control over the variables that can impact ultimate delivery, with OTT there are an immense range of factors that can cause packets to get dropped and lost: not least the variability of bandwidth over different geographies, different times, and different stretches of the journey.
Various standards seek to deal with this in various clever ways, each with their own distinct advantages and disadvantages. But whether it’s Adobe HTTP Dynamic Streaming (HDS), Apple HTTP Live Streaming (HLS), Microsoft SmoothStreaming (MSS), or the international standardized solution MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH), pretty much all of them take the same approach; convert the broadcast into multiple ‘profiles’ (essentially differing resolutions and speeds that result in the videos delivery with various different bitrates) and then divide the video into ‘segments’ (typically lasting between 10 and 2 seconds). From here, all standards then apply ‘Adaptive Bit Rate streaming’ (ABR). ABR allows for switching between the aforementioned profiles: if bandwidth is clogged, the receiving client device can request to switch down, and if things are flowing smoothly, it can switch up. Although this may result in visibly diminished image quality, what is imperative is that the continuity of the broadcast is maintained without interruption.
How we monitor
It makes sense then that one of the key monitoring activities that needs to be undertaken on an OTT network is how well this ‘profile switching’ is being achieved at any given moment, amongst other things (particularly latency between origin, CDN and final client).
For us at Bridge, this is largely achieved through the use of ‘active testing’ processes, which can be applied to all of the standards listed above – HLS, HDS, MSS and MPEG DASH. Passive testing – which is generally incredibly difficult to scale – still has its uses though, and Bridge’s OTT probes have the capacity to make use of this passive testing by introducing a filter which can set parameters – based on source, destination or a range of other criteria – to select only a portion of traffic for examination. But in terms of active testing, Bridge’s OTT probes – be they the Nomad, VB120, VB220 or VB330 – essentially act as if they are either the end customer (or at least, their device) seeking out a stream from a CDN, or they act as if they are that CDN making a request directly from the originating server. For full spectrum insight across the entire network, you ideally want two probes occupying both of these positions.
What differs though is that where normally a customer would only be requesting one stream at a time, the probe requests multiple streams and all their associated data; including their initial manifest file, the manifest profile, and all of their associated ‘chunks’. On the VB330, a maximum of 50 OTT engines are available with each probe, and each engine can monitor up to 10 OTT streams. So a bit of quick maths tells us that’s 500 streams which can be monitored simultaneously (with the caveat that some engines need to be devoted to latency measurement). That’s quite some capacity.
Now, it might be readily apparent to you: if the probe is demanding all of this data from the origin server or CDN, then this too becomes an additional burden on the network. But as always, Bridge probes are built with flexibility and adaptability in mind; so functionality includes the ability to simply check whether individual chunks are available, without downloading the actual media itself. Whilst this precludes in-depth content analysis, it allows for lightweight application of the probe when needed.
What we monitor
With all of these streams harvested as efficiently as possible – with next to no latency and optimally minimised load on the server and traffic on the network, that’s when the probe starts doing its job: seeking out error events which – if the probe was a human viewer rather than an impassive grey metal box – might impact the final viewing experience, either immediately or in the near future. Whether it’s failure of a profile to meet its stipulated bitrate, a lack of profile alignment or any number of other potential packet problems and parameter breaches, you can be sure that Bridge probes will flag them immediately.
What’s particularly important – and impressive – about Bridge probes though is not just what they do and how much of it they can do at once, but how easy they make it to understand. Whilst the processes outlined above can seem unduly complex when written down in paragraphs, presented visually on the VB330 timeline, everything is instantly intuitable. A timeline – which can be set to show historical data over the course of two hours, 24 hours or four days – highlights in red when an error event has occurred, and marks exactly what type of error it was. These ‘alarms’ are split into three categories; Transport, HTTP and XML, and each has fully customisable threshold parameters. Bars for each stream’s set of profiles show if one of them specifically is malfunctioning, and one click through gives deep-dive information on the performance of each profile, including expected and actual bitrate. Thumbnails can also be accessed at a click, with the possibility to check that each profile is suitably aligned (meaning when ABR switching occurs, the transition is seamless for the viewer). And latency for each stream can be measured throughout points on the network, giving at-a-glance understanding with just the click of a tab.
To what end?
So it’s all very well and good to outline how Bridge probes measure OTT streams (of which we’ve provided an ‘explain it like I’m five’ explanation), what Bridge probes measure (of which we’ve barely scratched the surface), and how we present this to users in a way that makes intuitive and usable sense (which becomes ever more clear from an active demonstration).
But so what? Why bother?
Well, that brings us back to the point we made at the beginning. Whilst a little bit of uncertainty and instability at the business-level might be expected in the world of OTT content deliver, there is almost zero tolerance for instability at the technical level. Whether it’s live streaming or on-demand content, users want the highest quality of image, unblemished audio, and no interruptions. In an increasingly volatile and precarious market, maintaining exceptional QoE can end up being the difference between a subscriber for life, or a disgruntled viral TikTokker swearing off your service for eternity, and telling everyone who will listen about it.
And the one weapon against that is a Bridge OTT probe; because we keep our innovation agile, so that your technology can remain stable. There’s nothing over the top about it. (whoops, sorry…).
