Q&A
It’s a process used to insert ads into a piece of long form content. It allows for a buffer-less transition from content, to ad, then back to content in an OTT streaming environment, providing the same user experience as broadcast TV. This process is managed by Nowtilus as a SSAI vendor. We „sit“ between the Online Video Player, Content Origin and Ad Server to mediate the stitching of the ads into the content. By doing so we enable personalization of each single stream containing precisely targeted ads.
SSAI is used by broadcast-quality media owners. This includes media owners that stream live events, stream live-linear cable TV, and have Video On Demand (VOD). This content is typically high quality and long form.
SSAI content can be accessed across all devices in both web or app environments. This means users can stream SSAI content on desktop, mobile, and connected TV devices.
We support HLS and MPEG-DASH for both Live and VOD content. Because this is primarily concerned with the server-side manipulation of manifest files, it is largely agnostic to DRM systems, which are usually concerned with protection of the content segments. Our customers operate with either full "studio grade" DRM (Playready, Widevine, Faiplay) or encrypted HLS.
Our solution leverages your existing ad server and audience tracking solutions to perform the user targeting. We are pre-integrated with ad-servers and SSP platforms such as Equativ, Google AdManager and SpotX. In general, VAST 3.0 and 4.x compliant ad platforms are supported. A wide range of configuration options make integration and validation really straightforward.
We support ad-tracking and reporting from server-side with tracking beacons as a response back to the ad-serving / SSP platform once stitched into the personalized stream. At the same time we can insert tracking metadata into the stream manifests for client-side ad-tracking from the player.
As a roadmap item and if supported by your ad-serving partner we are going to support VAST 4.0 ad-verification tags for measurement and brand safety. In addition for Client-side tracking we’ll support Open Measurement SDK and Library of the IAB, as a replacement for former VPAID implementations.
Yes, we handle that. Our SSAI platform service is cloud-native and scales on request. It can be geographically deployed and distributed in all regions of Microsoft Azure cloud. It is specifically designed to support the large audiences that are associated with live sport and event television. It is designed to work alongside your existing single or multi-CDN strategy for the delivery of the content source video data to end users.
Ad transcoding is a core function of our solution. By normalizing ad content we can not only better guarantee the user experience from a qualitative perspective (such as audio level normalization), but it also guarantees stream integrity -- ensuring that an ad cannot "break" a user's streaming experience. Ad transcoding is processed with Azure Media Services, although we have an ad-asset-management to allow pre-loading of ad assets as part of the ad trafficking process by your ad operations teams.
Yes, we do. However please bear in mind that many packager vendors have yet to support SCTE-35 signaling for live MPEG-DASH, so you should check with your packager vendor for their support and roadmap. If you are packager vendor and would like guidance on how to implement SCTE-35 signaling support within your product, please speak with us. If required we can also support you with setting up a cloud-based live encoding and packaging workflow enabled for SSAI.
For source signals that don’t already have in-band SCTE-35 signaling identifying ad breaks, we provide a software component, a 3rd party ad-recognition service, that provides automated ad-recognition and signaling of ad-breaks. Besides it can integrate with broadcaster live playout automation to determine program and ad breaks, which are then injected into the stream for onward processing by your encoding workflow.
No. The content segments itself will be not processed, stored or cached by serverside.ai at all.
For some features it is required to keep the playlist/manifest for a defined period of time, see timeshift/startover.
Our solution is designed for highly dynamic ad break patterns. Unscheduled breaks, early or crashed returns into content are supported as long as signaled in you source feeds.
We require that you have encoded your VOD catalogue in either HLS or MPEG-DASH – how you achieve that is entirely up to you. To achieve frame-accurate ad insertion, your VOD encoding should ensure that segment boundaries coincide with the known insertion points.
We support acquisition and encoding of VOD titles as part of the solution which includes frame-accurate segment conditioning.
Yes, and this is our recommended approach. We do however support single pod VAST responses in combination with a "placement template" that you define.
Yes. For an ad media encoding workflow with Bitmovin or ffmpeg (need to be configured by DevOps during the onboarding process), serverside.ai can provide a storage as an origin for the CDN, or upload the medias to a customer AzureBlobStorage.
Serverside.ai can use the same SCT35 marker as for the live-channel. In addition the side load marker via mRSS (ad cue points) can be used as well.
Each and every GDPR related information like consent, consent string (including TCF 2.0) will be forwarded by serverside.ai transparently to the ad server in order to ensure the correct handling of the data privacy and protection rights.
This applies to every other data privacy regulation as well, like US Privacy, CCPA (California Consuemr Privacy Act), LGPD (Lei Geral de Proteção de Dados), POPI (Protection of Personal Information Act).
Last modified 1mo ago