How to Optimise CSAI on Tizen and webOS in 3 Steps (Part 2)

In the previous article, we have explored the challenges, observations made, and the suggested solutions one can make to ensure smooth CSAI ad playback on Samsung Tizen and LG WebOS. In this article, we will guide you through the 3 steps of the suggested solution implementation and touch on the available alternative approaches.

THIS IS A SNIPPET FROM OUR “HOW TO OPTIMISE CSAI ON TIZEN AND WEBOS IN 3 STEPS” MINI GUIDE WHICH YOU CAN DOWNLOAD HERE.

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.

Step 1: Enable streaming advertisements

Previously, we played advertisements based on the native video playback capabilities of the platform. In practice, this meant we played them back in MP4 or WEBM-formats, among others. For the initial phase, we wanted to also enable the usage of our own streaming playback capabilities (MPEG-DASH and HLS).

As this would be an impactful change, we made this option an opt-in. We already had the allowedMimeTypes API in our player configuration for the Google IMA integration. We added support for this option in our own VAST ad playback system so APIs would be consistent.

Finally, we added a preference picker: when both MPEG-DASH and HLS are allowed, the player will pick the MPEG-DASH variant. If this is not possible, it falls back to HLS. If neither is allowed, the player picks a progressive media file the exact same way it used to do until now. 

Why MPEG-DASH over HLS? In HLS, it is quite common to have MPEG-TS segments. Remuxing these takes time and CPU cycles, things that aren’t abundantly available on most smart TV platforms. With MPEG-DASH, this transmuxing step is often not needed. In order to avoid having to spend CPU cycles on remuxing, MPEG-DASH became our go-to choice.

In the end, we were able to play streaming advertisements, but without the optimisations of preloading the advertisements yet.

Step 2: Allow the caching API to store segment in RAM

Given the smart TV platform limitations, we wanted advertisements to start loading before we append data to the mediabuffer. When we considered the different options, we figured out that the most efficient way was to internally reuse the Caching API. This API allows us to cache parts of a stream up-front and do offline playback. Instead of using Cache API in a standard way, which stores data on the disk, we wanted to store it in non-persistent (RAM) memory.

In this phase, we internally extended the Caching API to allow such capabilities. 

Storing data in a non-persistent way allowed us to work around writing complex logic for handling edge cases such as handling insufficient storage memory, or cleaning ups segments if the application would close unexpectedly.

Step 3: Implementing ad preloading

The last part was glueing everything together. At this point, we were already able to play streaming advertisements and indicate that we want to download a stream up-front without appending it to a mediabuffer. What remained was integrating the components together and fine-tuning the package. In our own ad VAST ad player, we download VAST metadata slightly before the ad starts. So we added logic to hook into this and download the first ad when the VAST data is available.

A streaming advertisement download will only start when:

• The VAST manifest contains streaming variants
• The allowedMimeTypes-configuration enables it (disabled by default)
• The platform supports one of the allowed streaming mime-types. 

When an advertisement is too short - less than five seconds - we download the start of the consecutive streaming ad as well. As ads play, we clean up the cached data and schedule the upcoming advertisements until the end of the ad break is ended. As we only preload the start of the advertisement, the rest of the asset follows regular ABR logic. When the bandwidth changes, the player can anticipate this and switch quality. This was not possible with ads in a progressive download format, such as MP4.

The result works quite well, as the start-up time is noticeable faster. We don’t have exact metrics, but in our testing lab, we noticed the start-up time would down to a maximum of two seconds. Coming from eight or more, this is a significant reduction. As our playback pipelines are continuously improved, the ad player will be able to reap the benefits from this as well.

This change is available in our web SDK as of 2.84.0. iOS and Android SDKs are, for now, disabled from this offering.

Alternative approaches

We went all the way to support this use case, but it certainly is not the only way to do advertising on smart televisions. For completeness, we list alternatives:

• Server-side ad insertion is a viable alternative for targeting smart televisions, although it is slightly more complex to set up. In this scenario, the advertisements are part of the stream. The player integrates with metadata provided by the SSAI-server to build a full ad experience. This includes adding a link to a landing page, adjusting the user interface, showing how long advertisements still take and tracking progress using standard ad beaconing. The set-up for SSAI is more complex than client-side ad insertion but pays itself back in a higher fill rate and better user experience.
   
• There are less common alternatives as well: static non-media advertisements, such as non-linear (banners) or companion ads (ads shown outside the player). Thinking out of the box, there are much more options to earn money from free content: sponsored product placement, paid bonus content, selling merchandise… You could even show a non-intrusive banner advertisement while the content is paused.

You can download the complete version of this topic in our “HOW TO OPTIMISE CSAI ON TIZEN AND WEBOS IN 3 STEPS” guide here.

Want to try out our new streaming CSAI-ads? Contact us and we'll get you started.