More articles in this series and about OTT/Streaming:

TVs have always been central to our media consumption experience. Even if mobile devices have taken over a big share of today’s minutes viewed (some reports suggest as much as 60% of video views are on mobile), the TV remains core to the home viewing experience, the long-form content viewing experience, and the community viewing experience. But like other important technologies involved in Streaming (e.g., the internet), the TV was not purpose-built for streaming video. From a broadcaster perspective, the way TVs are designed places various obstacles in the way of delivering a great consumer experience on a broadcaster’s Streaming App. In particular, PSBs (Public Service Broadcasters) need to grapple with the TV ecosystem in a complicated way that requires some serious simplification.

The Browser Situation

The basic building block of visualizing a Broadcaster Streaming App on a Smart TV is a web browser. Each TV has a web browser function that Broadcasters use as the platform for their App. The browser presents all of the various interfaces, menus, content, and features to users.

But, browsers can be very different between TVs.

First, there is a long and growing list of browsers in the market. There are the “Computer Web Browsers” that can be found on TVs (and are used in the broad array of computers and mobile devices). The big 5 are Safari (Apple), Firefox (Mozilla), Chrome (Google), Edge (Microsoft), and Vewd (Sony). Vizio TVs, for example, use Safari, Firefox or Chrome. Then there are the “TV Web Browsers” that different TV manufacturers are embedding. These include Samsung Internet and LG Web Browser. Panasonic does not have a web browser but has recently introduced a new operating system called Titan OS. Sky Glass has a proprietary system and no web browser, but customers can add peripheral devices like Google Chromecast or Amazon Firestick for additional services.

Second, different TVs that use the same browser can have many different versions of the browser deployed. Different operating systems and bug fixes need to be supported across these different versions. This is particularly true for TVs of different ages. Older TVs have older browsers that generally cannot be updated.

While the web browser is a standard building block for Streaming Apps, there is therefore a long list of different variants that must be addressed by Streaming App developers. For Broadcasters in general, and particularly for PSBs that have the most diverse national audiences to serve, supporting many years of Smart TVs, PCs and Mobile devices with all their different web browser deployments is a very resource-hungry activity.

The Processor Situation

The basic building block of delivering the data and content into a Broadcaster Streaming App is processing power, or computing power. Each TV, PC and mobile device has on-board processors that process and present data to the user. The more modern devices have more power, given chipset-level technology advances that continuously consume less resource and yet deliver more output.

Processing power is measured in Hertz (the German word for “heart” and representing how a computer’s on-board clock feeds a constant flow of pulses into the on-board microprocessor). These pulses are electromagnetic waves, also known as cycles. One Hertz (Hz) means one cycle per second. One Giga Hertz (GHz) is 1 billion cycles per second.

Modern Streaming Apps typically require about 1.5GHz to 2.0GHz for good streaming delivery, and about 1.5GHz to 2.5GHz for advanced streaming features like 4K, HDR, and Dolby Atmos. To include gaming and interactivity within the App typically needs more than 2.0GHz.

Smart TVs produced around 2020 generally had about 1.2GHz to 1.8GHz of on-board processing power. In 2016, this number was about 1.0GHz to 1.5GHz. It’s not surprising that older TVs have a harder time delivering excellent streaming experiences.

In addition, many “budget” Smart TVs that have price and basic streaming features prioritized over more advanced specifications generally sell in higher volumes. These TVs tend to have simpler processors, and again may struggle to deliver a full and excellent streaming experience.

Living With Complexity

The mix of older TVs and budget TVs creates a customer base for Streamers that cannot easily use a Streaming App to its full effect. Important basic features (e.g., high-resolution graphics, animations) might not be available from one TV version to the next or might perform poorly on one TV and not another. Therefore, Streamers must design in a graceful deprecation of their App’s more optional features as a TV’s capability to run the App reduces. While this is potentially an elegant solution to a technical domain outside of the Streamer’s control, it adds more complexity to the App design which adds risk to the App’s stability and performance. Streamer decisions generally tend towards protecting playback and protecting content as non-negotiable engineering requirements, while providing full personalization, monitoring individual customer streaming performance, and offering new types of interactivity and 3rd-party app integrations, are the types of functions that can be deprecated – but only if absolutely necessary. There is a fine-line to walk between removing functionality and losing the viewer.

The combined Browser and Processor situations create a significant technical development and support challenge for Streamers. PSBs, with their obligation to deliver their content very widely across national populations, face the biggest challenge. One PSB interviewed for this article stated that their current Smart TV support list, categorized by Brand, Screen Size, Browser version, and Processor version, now numbered 13,000 individual line items. And as many people keep TVs for 10 years or more, the list is expected to continue growing in the years ahead. Fully testing new App releases and new features across all these devices is impossible, leaving Streamers exposed to the risk of customer dissatisfaction on a large scale, and needing to be prepared to react quickly to technical customer service issues. Managing the technology stack and the subsequent consumer satisfaction (or lack of) is becoming increasingly complex for Streamers.

But the complexity doesn’t stop here. The mix of TVs on the market leads to complexity for content protection, video playback, and even playback analysis.

Content Protection:

• Different devices require different protection profiles. This results in large amounts of testing over many months to know how to turn on copy protection in the right way on different devices to meet studio requirements to distribute the content.
• Some devices can enable HDCP (High Bandwidth Digital Content Protection), but if analog standards are enabled on a device without an analog output, then the device’s operating system will give a generic error, and Streamers won’t know why the failure occurred. The technical support resource requirements keep piling up.

Consistent Live Video Playback:

• While VOD content can have multiple profile variants prepared in advance (e.g., bitrates, encryption keys) that will cater for most viewers, Live Video is not as easy. For Live Video the delivery formats are often more restricted in order to control complexity and costs. This is particularly true when Cloud-based encoding and origination platforms are used, where costs can add up fast for extra variants to be produced and egressed into the CDNs for onward delivery to the viewers. So, the various devices receiving the content get what they get, and the results are what they are.

Understanding Playback Quality KPIs:

• Streamers work hard to gather and interpret data about their viewers’ experience of the Streamer’s App. Playback quality is a priority KPI for any Streamer, given that Playback is a fundamental expectation of any media consumer. In the Smart TV world, it is possible that devices playback perfectly well, but sometimes data about playback is inaccurate. One PSB reported that they recorded a playback score of “zero” with one manufacturer, but ultimately found that the reading was wrong. Streamers work with TV manufacturers to fix these types of issues, with mixed results. Unfortunately, this reality means that playback data accuracy can often be under suspicion, and time is spent double-checking and filtering data.

We are moving to D2C Streaming at scale. This is when most broadcaster TV services have most of their audience consuming content via streaming services. This is likely to be 4-6 years from now in most countries with mature multi-platform TV services. The current expectation is that bigger audiences are unlikely to add many more device types that have not yet surfaced in the list of 13,000. What is likely is that scaling up the audience by 5-10 times from today’s peak Streaming audiences will exacerbate the current situation and lead to a higher absolute number of issues. The direct-to-consumer nature of streaming will probably lead to more complaints coming back to the Streamer rather than the TV manufacturers, given that most consumers will blame the content brand that potentially delivers a different experience compared to another brand they engage with on the same TV.

Mirroring The Global Streamers

Juxtaposed to the “PSB Browser” situation is the “Global Streamer Binary” situation. While national broadcasters need to adapt to the TV manufacturers, the TV manufacturers must adapt to the biggest global streamers. Netflix is a prime example. Netflix have set the global gold standard for delivering excellent Quality of Experience, across both older and newer devices. They have built their own UI (User Interface) abstraction layer that is the equivalent of a web browser, but that is optimized for Netflix requirements (i.e., not generic websites). The proprietary design for Netflix use cases gives a final layer of optimization that other Streamers struggle to achieve.

The Netflix web browser is integrated into TVs by the manufacturers, following the integration specifications of Netflix to optimize performance of the App and the viewer experience. Additionally, Netflix have their private CDN, “Openconnect”, in which they have invested over $1 billion. This combination of proprietary browser and CDN provides Netflix with control over compute, storage, and streaming capacity that can optimize both App and Video delivery.

Can PSBs follow the Netflix way somehow? The short answer is: yes, in two primary ways. The first way is to push as many App functions as possible away from the device and into the centralized back-end compute environment (i.e., the Cloud or CDN). APIs for specific classes of device can be used to deliver only the data that a device class needs. The second way is to move from Cloud computing to Edge computing wherever possible. Distributing App Delivery and Media Delivery across an Edge network will provide latency, load balancing, and resilience benefits to PSB Streaming Apps. Even if a national broadcaster does not build its own Web Browser or its own CDN, new technologies and business models are now becoming commercially available to help broadcasters get much closer to the gold standard in streaming.

Part 2 in this article will consider the latest Web Browser development tools and the emergence of Edge Computing for Video use cases that will continue improving the viewer experience as Streaming scales.