Share this
by Mathias Craps on May 18, 2021
Over the next three years (by 2024), global online advertising revenue is expected to hit almost $120 billion (€99bn), consistently outperforming subscription-based video services by just over 20%. This estimation is also in line with the growth of global AVOD active monthly user, two-thirds of which access such services on the TV screen.1 However, as we have learned from our deep dive two of the most popular Smart TV platforms, Samsung Tizen and LG WebOS, delivering reliable video experience to these platforms is not an easy task. Unfortunately, these quirks and limitations will also be present in the monetisation of contents.
In the first part of a two-part series blog, we are going to explore the challenge, observations made and suggested solutions one can make to ensure a smooth CSAI ad playback on Samsung Tizen and LG WebOS.
THIS IS A SNIPPET FROM OUR “HOW TO OPTIMISE CSAI ON TIZEN AND WEBOS IN 3 STEPS” MINI GUIDE WHICH YOU CAN DOWNLOAD HERE.
Why invest in an offering for smart television applications?
Generally speaking, you can monetise video content in two ways: either the end-user (partly) pays for it, and/or you get the revenue by attracting a pool of companies willing to pay to sponsor a promoted message. Amidst the corona pandemic, consumption of media content through smart TVs surged significantly. According to the latest State of Streaming report of Conviva (Q1 2021), viewing time on smart televisions has shown a year-over-year growth of a whopping 115%.
Graphic 1. Growth in viewing time in Q1 2021 compared to Q1 2020 by device2
While OTT consumption through smart televisions is still a young, developing segment, it has been growing consistently over the last years, making it an interesting new market to invest in. If your business model is based on advertising revenue, it also raises other questions: can I use sponsored content here as well? And are there quirks?
On more established platforms such as desktop and mobile devices, client-side is still the dominant approach compared to server-side ad insertion. If you are unsure what the difference is, make sure to read this article.
On smart TV web applications, we observed additional challenges getting client-side ad insertion working. In this article, we take a deep dive into the biggest problem we encountered: start-up performance.
Challenge: higher start-up time
We observed that on platforms such as Tizen, the start-up time of advertisements in progressive download formats (such as MP4 or WEBM) tend to be significantly higher. With slower, we mean up to 8-10 seconds time-to-first frame. As a typical ad break exists of multiple ads, this makes this experience unbearable.
Progressive downloads also pose a second challenge: you cannot change the quality of advertisement videos while you play them. If the bandwidth changes, the advertisement cannot scale up or down to match this without redownloading the full advertisement. As 4k is becoming the new standard resolution for televisions, picking a low conservative size to avoid issues is not desirable.
Our investigation efforts were mostly focused on Tizen, as the start-up time was the highest on these devices. We figured out that WebOS has similar limitations and that a broader solution would be justified.
Observation
We noticed that the Tizen platform only allows one active video element at the same time. When you interact with a second element, it simply deactivates the first one. This means that the content is rendered as a black rectangle and has to be reactivated by the player. This introduces a visual glitch we wanted to avoid.
Interestingly, there is a difference between versions: Tizen 3.0 does not allow preloading through video elements across the board. Tizen 5.0 is more tolerant and only deactivates the main content when you assign a new source to another video element.
As a cross-platform player, we need to support the lower versions. This would force us to assign the ad source at the very last moment. No preload means extra delays. Combine this with factors as extra network latency and decoding time, and the delays count up to eight to ten seconds. Mainly the download turned out to be the biggest culprit. It is plausible that the start-up time could be further increased by variances in how the segment is encoded. For instance: if essential data is stored at the end, the platform needs to do a full download. In our testing, we did not observe such a deviation.
We understand the value of advertising for our customers, so we investigated if there is a better way to make this work. After all, the high start-up time would drive end-users away and result in less revenue.
Solutions
Upon further investigation, we figured out that two approaches worked like a charm:
- Preloading through a native player (f.i. AVPlay on Tizen), where one instance plays the current ad and the other preloads the next one. They would then swap as the ad pod plays.
- Using streaming advertisements variants found in VAST-manifests, by downloading the streaming manifest and segments up-front, but only append it when switching to an ad break. The advertisement would then play via MSE on the video element.
We weighed both options and settled on streaming advertisements. The reasoning was practical: AVPlay would be restricted to just the Tizen platform, while the latter approach would work on all platforms that support MSE.
Other considerations included:
- The AVPlay-pipeline uses a different API, which would require us to internally bridge the differences between the AVPlay pipeline and our own universal API.
- We would not have any control over the AVPlay-pipeline in case anything would not work out in the longer term. With our own MSE-based pipelines we have full control, making it easier to anticipate future requirements.
- The AVPlay-implementation differs across versions. This may introduce inconsistencies, especially because native support for HLS and MPEG-DASH differs vastly.
In short: using standard MSE-playback allows us to target more devices and stay in control of the playback.
Implementing The Solution
In the next blog, we will walk you through the 3 steps to implement this solution. In short, we approached this project in three steps. The first two were preparation steps. The last one was glueing everything together. Luckily, we were able to reuse big parts of our code-base, making the development process much shorter.
You can download the complete version of this topic in our “HOW TO OPTIMISE CSAI ON TIZEN AND WEBOS IN 3 STEPS” guide here.
1) AVOD Consumption Behaviours Report (Omdia, 2020); 2) Conviva's State of Streaming Q1 2021 (Conviva, 2021)