AVOD: Advertising-based Video on Demand

As online streaming platforms continue to grow in popularity, delivering targeted advertisements to viewers has become crucial for both content providers and advertisers. Two primary methods used for ad insertion are **Client-Side Ad Insertion (CSAI) **and Server-Side Ad Insertion (SSAI).

In this comparison guide, we will explore the differences between CSAI and SSAI, their unique features, and the advantages they offer to streaming services. Understanding the distinctions between these two methods will help you make informed decisions on how to best integrate advertisements with your video content to ensure a seamless and personalized viewing experience for your audience.

Let’s delve into the world of advertisement insertion methods and discover which approach aligns with your goals.

Client-Side Ad Insertion vs Server-Side Ad Insertion

Client-Side Ad Insertion (CSAI) and Server-Side Ad Insertion (SSAI) are two different methods used to insert advertisements into video content for online streaming platforms. Both methods serve the purpose of delivering personalized ads to viewers, but they work differently and have distinct advantages.

Client-Side Ad Insertion (CSAI):

• Client-Side Processing: In CSAI, ad insertion occurs on the client-side, which means the video player on the user’s device handles the process. When the video is played, the player communicates with an ad server to fetch the relevant ads, and then it switches between the ads and the main video stream. As a result, ads are seamlessly integrated into the playback.
• Dynamic Ad Selection: CSAI enables easier dynamic ad selection based on real-time data and user behavior. The ad server can analyze user information and preferences, allowing for more personalized and targeted ad placements.
• Interactive Ads: Rich interactive ads can be served based on the capabilities of your video player and ad service provider.
• Ad Blocker Impact: CSAI is more susceptible to ad blockers since the ad requests are made by the client’s video player. Ad blockers can interfere with these requests, potentially leading to ad-skipping or blocking.

Server-Side Ad Insertion (SSAI):

• Server-Side Processing: In SSAI, ad insertion occurs on the server-side of the streaming platform. The video content, including the ads, is stitched together (pre-packaged) on the server before reaching the viewer’s device. The player simply receives the pre-packaged stream and plays it back, this means less logic is needed to be built and maintained around handling ads on each device.
• Seamless Integration: SSAI provides a seamless ad experience, as ads are seamlessly stitched into the video stream on the server. This method often eliminates buffering between the main content and the ads.
• Ad Blocker Resistance: SSAI is more resistant to ad blockers since the ad insertion is done on the server-side, and ad blockers typically have limited control over the server-to-client data flow.
• Uniform Playback Quality: SSAI ensures that all viewers receive the same ad experience, regardless of their device capabilities or network conditions.

Choosing Between CSAI and SSAI:

The choice between CSAI and SSAI depends on various factors, including the platform’s technical capabilities, business goals, ad targeting needs, and viewer preferences. Many streaming services use a combination of both methods to optimize ad delivery and provide a satisfying viewer experience. CSAI may be favored for dynamic and rich ad targeting, while SSAI might be preferred for ad blocker resilience and consistent ad experiences.

Using VIA for Client-Side Ad Insertion (CSAI)

Easily add ad markers to assets for client-side advertising via the VIA UI (Chapters) or automated API integrations. Use Feed Ingest to specify index points and/or segments per asset for precise ad placement within the content.

Example of defining ad markers in an Atom Media RSS feed:

<?xml version="1.0" encoding="UTF-8"?>
<feed
    xmlns:at="http://purl.org/atompub/tombstones/1.0"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:vimond="http://www.vimond.com/vimondFeedExtension/1.0"
    xmlns:fn="http://www.w3.org/2005/xpath-functions"
    xmlns:media="http://search.yahoo.com/mrss/"
    xmlns="http://www.w3.org/2005/Atom">
    <title>My example feed</title>
    <updated>2023-03-11T11:47:44.803Z</updated>
    ...
    <entry>
        ...
        <!-- Index points -->
        <vimond:indexPoints type="ad">
            <vimond:indexPoint>
                <vimond:title>First commercial break</vimond:title>
                <vimond:offsetTime>PT10.035S</vimond:offsetTime>
            </vimond:indexPoint>
            <vimond:indexPoint>
                <vimond:title>Second commercial break</vimond:title>
                <vimond:offsetTime>PT30M</vimond:offsetTime>
            </vimond:indexPoint>
        </vimond:indexPoints>
        ...
    </entry>
</feed>

For more details on how to ingest ad markers, please see How to ingest Asset with index points and/or segments

Once an Asset has been populated and published with ad markers, your front-end application will be able to fetch all the ad metadata such as startTime for each ad position by adding the query parameter extraFields=markers to the search request.

Example of direct asset lookup, where we wish to have the timeline markers included in the response:

curl -X GET 'https://{tenant}.content-discovery.cf.{domain}.vmnd.tv/api/v1/assets/173781?extraFields=markers

The response now contains a markers array containing all of our ingested ad markers.

{
  "data": [
    {
      "id": "173781",
      "timestamp": "2019-09-12T06:22:39Z",
      "createTime": "2019-03-26T11:31:30Z",
      "category": {
        "link": "https://{tenant}.content-discovery.cf.{domain}/api/v1/categories/129025",
        "id": "129025",
        "path": "999 129025"
      },
      "labeledAsFree": false,
      "drmProtected": false,
      "duration": 43.848396734121124,
      "assetType": "Trailer",
      "isLive": false,
      "transmissionTime": "2019-03-26T08:15:52Z",
      "relatedAssets": [],
      "qualities": [],
      "markers": [
        {
          "title": "First commercial break",
          "type": "ad",
          "startTime": 10.035,
          "endTime": 10.035,
          ....
        },
        {
          "title": "Second commercial break",
          "type": "ad",
          "startTime": 1800.000,
          "endTime": 1800.000,
          ....
        },
        ...

      ],
      "version": {
        "available": [
          "main"
        ],
        "type": "main"
      },
      ...
    }
  ]
}

For more API details please see Non-default asset fields

You now know how to fetch all ad markers from VIA and the next step of displaying them to end-users depends on the video player in use and the syntax they require for inserting ad breaks.

Using VIA for Server-Side Ad Insertion (SSAI) using SCTE-35 and ESAM

SCTE-35 (Society of Cable Telecommunications Engineers-35) is a standard that defines messages used for digital program insertion (DPI) in broadcast and streaming services. It allows for the insertion and removal of content such as ads, program promotions, and local programming. It also allows for precise timing and synchronization of these messages.

ESAM (Event Signaling and Management) is a standard that provides a framework for signaling and messaging between different components of an OTT (over-the-top) streaming service. It allows for the communication of information such as program schedules, content metadata, and user data between the different components of the streaming service.

Together, SCTE-35 and ESAM provide a powerful toolset for managing and delivering content in OTT streaming services. They enable the delivery of targeted advertising, program promotions, and other content to specific audiences. They also allow for the seamless integration of different components of the streaming service, ensuring a high-quality user experience.

To ingest video with ad markers using ESAM (Event Signalling and Management API) XML files, you can include the ESAM files in your feed. ESAM files provide SCTE-35 messaging that should be included in the end-user playout streams produced by VIA Orchestrate.

There are two types of ESAM files that can be included:

1. Signal processing notification XML: This is a required file and is used to insert time_signal messages into the TS (Transport Stream) segments.
2. Manifest confirm condition notification XML: This file is optional and is needed to add information about the SCTE-35 markers into the produced HLS media manifests.
   You can include ESAM files in the ingest for pipelines where transcoding is managed by AWS Elemental MediaConvert and the output is HLS.

Here’s an example feed that demonstrates how to ingest video with ESAM files:

<feed xmlns:at="http://purl.org/atompub/tombstones/1.0"
      xmlns:dcterms="http://purl.org/dc/terms/"
      xmlns:vimond="http://www.vimond.com/vimondFeedExtension/1.0"
      xmlns:fn="http://www.w3.org/2005/xpath-functions"
      xmlns:media="http://search.yahoo.com/mrss/"
      xmlns="http://www.w3.org/2005/Atom">
    <title>Test Feed</title>
    <link href="http://www.vimond.no" rel="self"/>
    <updated>{{FeedUpdateTime}}</updated>
    <entry>
        <id>{{YOUR_UNIQUE_ID}}</id>
        <title>ESAM TEST</title>
        <vimond:drmProtected>false</vimond:drmProtected>
        <updated>{{FeedUpdateTime}}</updated>
        <media:group>
            <media:content url="https://video-ingest-test-public.s3.eu-central-1.amazonaws.com/ESAM_integration_test_sample.mp4" type="video" pipeline="3341123830"/>
            <media:content url="https://video-ingest-test-public.s3.eu-central-1.amazonaws.com/esam_mcc.xml" type="esam_mcc" pipeline="3341123830"/>
            <media:content url="https://video-ingest-test-public.s3.eu-central-1.amazonaws.com/esam_scc.xml" type="esam_scc" pipeline="3341123830"/>
        </media:group>
    </entry>
</feed>

In the above example:

• The <media:content> elements specify the URLs of the video source file and the ESAM files. The type attribute is used to identify the ESAM files with the values esam_mcc for Manifest confirm condition notification XML and esam_scc for Signal processing notification XML. The pipeline attribute specifies the pipeline ID.
• The esam_mcc.xml file provides information about the SCTE-35 markers that should be included in the produced HLS media manifests.
• The esam_scc.xml file contains time_signal messages that should be inserted into the TS segments.

Ensure that your VOD pipeline template includes an encoding profile that uses AWS Elemental MediaConvert, as indicated by the AWS_MEDIA_CONVERT type. You can review your active encoding profiles in the Content Configuration module in the CMS.

By including the ESAM files in your feed, you can ingest video with ad markers and provide SCTE-35 messaging for your content.

References for further reading:

• OpenCable Specifications Alternate Content Real-time Event Signaling and Management API, OC-SP-ESAM-API-I03-131025.
• Specifying SCTE-35 markers using ESAM XML (AWS MediaConvert documentation)

For more details about Feed Ingest please see the link.

For more details on how to get started with CSAI and SSAI using VIA, please reach out to our support team.