In this post, I will provide a very high level overview of the core differences and challenges between broadcast DTH/SetTopBox systems versus OTT platforms. OTT has become a hot topic, with the nascent rise of OTT (Over-the-Top) internet streaming platforms that many a traditional PayTV operator is now transitioning to, in light of the growing competition for eyeballs & cord-cutters driven by the likes of primarily SVOD (Subscription Video On Demand) players like Netflix, Amazon & the like. The challenge though, is that these PayTV operators tend to trip up by bringing PayTV/DTH thinking into the OTT-world, hence my post.
The main aim of this post is targeted at senior executives who come from a broadcast world, and may not fully grasp the nuances of an online streaming world, specifically pointing out the spectrum of control of the end-to-end platform that PayTV operators generally enjoyed much comfort in that world, in contrast to the new world of online, where it becomes impractical to expect the level of control previously enjoyed - basically you can't control all the components of the internet, unless you invest in owning a large part of the network, which some operators have attempted & haven't really succeeded!! Simply put, the internet was not designed for Live TV streaming unlike traditional broadcast TV - the internet is somewhat chaotic & messy to say the least. In addition to this level of infrastructure control & lack thereof, an OTT platform is largely software systems designed for internet-scale (i.e. massively distributed server-side backend components) which requires a different skillset and experiences traditionally enjoyed in the closed ecosystem of broadcast & set top box device software development teams.
Another point of this post responds to the standpoint from traditional PayTV executives who may have spent a large part of their work in building broadcast systems with an engineering mindset anchored to a past era that is no longer relevant in the OTT world. Expressing opinions such as "engineering systems either work or they don't, it's either a 1 or 0, no in between states..with an expectation of 100% always-on availability..." in my view is somewhat misinformed & borders on belittling the engineering challenges faced in the online world. Whist every responsible engineer understands such demands and expectations of any system, a key point to remember is that broadcast TV has benefited from many years of refinement, standardisation, systems & processes specialised for the domain of TV - and when it comes to the internet - well, it was never really designed for video consumption, the speed of innovation has outpaced the development of standards & so is a much more messy world compared to traditional broadcast TV (satellite/terrestrial).
Disclaimer: This post is not about downplaying the broadcast engineering world, in fact, a lot of OTT operations highly depend on the upstream capabilities from PayTV operator's existing broadcast engineering infrastructure. Broadcast engineering systems are a marvel of engineering in its own respects, systems are highly complicated & superior engineering. OTT systems, and the point of my post, is to show the extension of the value chain, highlighting the new software & systems engineering challenges that present itself in the OTT world, that will be new concepts for existing broadcast engineering teams to learn & appreciate.
Key points for TL;DR folks (especially the PayTV Exec CXOs)
- It's not a simple thing to compare OTT platforms wearing hat of a traditional DTH broadcast guy, it is not simply a like-for-like comparison.
- Don't be naive and pass value-judgements just because you were an engineer in the broadcast TV world (Headend or Set Top Box) does not necessarily make you qualified to understand OTT engineering domain. You can't bring broadcast/STB-thinking-mindset to the world of OTT.
- PayTV operators have historically enjoyed a high level of end-to-end control, not so in OTT world.
- There are far more components in the value chain of OTT than broadcast (backend, frontend and device software stack is more complicated in OTT than STB software).
- High level of device & platform fragmentation in OTT that a traditional PayTV operator must consider.
- The internet was never designed for TV consumption & has innovated at a much faster pace than traditional broadcast TV, the internet is a messy place, broadcast TV is somewhat cleaner and more determinstic.
- OTT engineering teams have different challenges compared to traditional broadcast & set top box engineering.
- PayTV operators need to plan carefully the convergence (DTH & OTT) of engineering teams and be prepared for a "clash of worlds".
- Set Top Box software systems enjoy far more security control & protection than its OTT sibling.
- Peak events & load challenges are unique to OTT platforms compared to broadcast DTH STB (scaling challenges don't really exist in DTH/STB).
- Redundancy, Fast Rollbacks, Failover & Disaster Recovery are easier to achieve in OTT than in broadcast DTH/STB systems.
Why do I write about this stuff anyway?<#humbleBrag If you're looking for an DTV technology expert, happy to have a chat for CTO roles!>
I've been working in engineering Digital TV software systems all my professional life of twenty years. Starting in the early 2000s, where there were just a handful of technology platform providers available (compared to today's world in online streaming where almost every Joe provides a streaming platform off-the-shelf), I have seen almost every transition in this space. I started with writing set-top-box applications built on middleware SDKs (then OpenTV & NDS MediaHighway platforms), to writing middleware & operating systems code for these embedded devices, called Set Top Boxes (STBs). I branched out into broadcast headend software systems that provided the necessary signalling that is core to powering STB applications, like the classic EPG (Electronic Program Guide). I studied and mastered the various IEEE MPEG & ISO/DVB standards in detail, as the middleware software had to implement the protocols (transport stream specifications) from scratch so the STB could interpret the data. I once implemented from scratch, STB client-side for decoding the full specification for signalling terrestrial networks (UK-D Book), which included a driver hardware abstraction layer, graphics library, application engine management and signalling.
I later branched out further to join the IPTV wave, building real-time streaming engines that converted these satellite broadcast streams into IP packets (entailed transforming MPEG packets, signalling, wrapping over IP packetisation - converting an MPTS to SPTS, adding transcoding & encryption then playout of IP), doing live streaming encryption on-the-fly in real-time as well as media file-based offline-encryption packaged VOD (Video On Demand) assets for consumption over the network. Back then we built all these systems from the ground up on standard hardware, running on standard servers (it was truly pioneering stuff). The network streaming was primarily over UDP multicast. We had to build everything, from the control plane managing the clusters with seamless failover, full management console for administrating the IP headend, etc. We built our own transcoding engines, taking in the MPEG source and converting to other formats - all before the time that internet streaming started to become mainstream. This meant going down to the detail of coding the MPEG signalling standards down to the bits & bytes of the video containers, timestamping & metadata signalling. We built these distributed computing platforms from scratch, there weren't any widely available frameworks for abstracting the network & infrastructure as we have today. CDNs were just being built around the same time keeping pace with the ever changing landscape of web technologies, back then IPTV systems took the form of traditional "headends" that sat in telco/broadcast data centres, Live TV was mostly UDP multicast, with VOD files being stored close to the edges. The consuming devices at the time were still STBs, and we were just starting on the web browsers as the client. I can truly say I've experienced just about the full journey of these systems, apart from writing any security-side code for conditional access & digital rights management (and also the distribution satellite systems was not my thing, I focused on building software). I then transitioned into engineering management roles that was all about software delivery of these value chains, and became quite an expert at it. In the last few years, my focus has been online, which is really the future of TV. There was actually a period in between for Mobile-TV broadcaast, DVB-H which tried to precede OTT, some PayTV operators gambled this would take off, in hindsight, that time and investment could have been better spent learning & developing their OTT platform instead. In my opinion the classic broadcast TV systems using unconnected STBs is dead, time to move on. This technology is now commodity, PayTV operators shouldn't invest too much in this world, they should rather sweat their assets and drive all operating costs down to be lean & efficient, stop manufacturing bespoke custom STBs & applications IMHO. The days of closed proprietary STB middleware software is also dead, time to openly embrace more modern stacks, that come very close to seamless integration with the online apps world.
How TV is PayTV changing?Today, the world is different and changing all the time. With the rise of the browser, "streaming over the top" has advanced at a much faster pace than the traditional broadcast world. There are so many topics I can talk about, which might become future posts. Take for example how software patterns for distributed systems had to evolve for internet web scale. A mistake often made in the early development of online-equivalent of traditional TV streaming, is one where the software stack for the streaming world emulated that of a STB, expecting real-time processing, synchronous calls to APIs, etc. Depending where you started, you might have a lot of legacy code to clean-up & undo design patterns that worked previously, but can't scale sufficiently to deal with exponential growth of online users. Some PayTV operators may have anticipated this online streaming by building their own online streaming platform, maybe 5-7 years back, resulting in some legacy already. Today, with the rise of cloud providers, and the constant comparison with the god of streaming (Netflix), PayTV executives expect the same level of performance & reliability from their in-house engineering team. Deciding whether your legacy online platform has reached the end of its shelf life, whether to continue to the restructure journey (e.g. migration to cloud), or hit refresh, starting from scratch build, or use off-the-shelf platforms, is a topic that has kept me awake many a sleepless night. A topic for another day. Another topic that makes traditional PayTV executives a little uneasy, is that the engineering, development, delivery & operational management for OTT platforms are much more dynamic & agile in nature, the fact that apps can be patched and upgraded quickly, that deployments to production happens almost daily, challenging traditional governance and change control procedures that demand varying levels of sign-off & approval, that developers can access production environment, etc. are topics IMHO that every senior executive from the old-world of PayTV, needs to come to terms with - i.e. don't expect your digital OTT engineers to behave the same way as your broadcast engineers! Anyway, these topics are best left for future posts...
Right, now that's off my chest, let's look at the big topics that speak to differences in traditional broadcast satellite TV platforms compared to OTT platforms: