In the early days of the internet, video advertising was primarily implemented through Flash animations or GIF images on websites. These ads were typically static and lacked sound or animated effects.

With the development of internet technology, advertisements started to integrate more with the video content itself and could be inserted before the video playback (pre-roll), during the video playback (mid-roll), or after the video ends (post-roll). The choice of ad placement depends on the video service provider and the desired combination of ad positions. They can also choose to combine videos into ad pods, allowing advertisers to play multiple ads consecutively during the ad slot.

ad insertion

Two methods to insert ads

In the field of streaming media advertising, there are two methods for inserting ads into videos: Client-Side Ad Insertion (CSAI) and Server-Side Ad Insertion (SSAI).

CSAI is a method of delivering ads to the client-side, where the client (video player) directly requests ads from the ad server when it detects ad markers in the video stream or playlist. The ads are then played during the specified time slots.

When the ad server receives a request from the client, it uses data analysis to deliver the appropriate ads to the specific client and responds with the ad information. Subsequently, the video player pauses the video, plays the ad, and then resumes video playback.

basic flow of CSAI

basic flow of CSAI

SSAI is also an ad insertion method: Unlike CSAI, which inserts ads on the client-side, SSAI directly splices the ad media files into the video stream on the server-side (instead of the client-side).

The advantage of SSAI lies in its resistance to blocking or tampering, as the client-side does not need to make server API calls to initiate ad insertion. In CSAI, the client needs to send API calls to the ad server, which can be easily blocked by plugins or other means, thereby reducing the revenue for content publishers.

In SSAI, all operations are performed on the server-side, and ads are directly inserted into the video stream, making it impossible to be blocked. However, SSAI has a more complex workflow and requires higher stability and quality standards for the server-side.

basic flow of SSAI

What is SCTE-35?

As mentioned earlier, both CSAI and SSAI require the program to be able to recognize ad cue points, which can be achieved through SCTE-35.

SCTE-35 is a digital broadcasting standard developed by the Society of Cable Telecommunications Engineers (SCTE) in the United States. It is used to insert and transmit time and event information in digital video broadcasting. The SCTE-35 standard defines a binary message format for identifying upcoming ad insertion points and ad termination points within a video stream. This enables ads to be seamlessly inserted and removed from the video stream without affecting the continuity of the video.

SCTE-35 diagram

SCTE-35 diagram

SCTE-35 consists of a SpliceInfoSection, which can be represented as structured data in XML or binary format. The SCTE-35 standard defines various specific time types and fields, with common types being splice_time and time_signal, which will not be further elaborated here.

The composition of SCTE-35

The ad insertion process requires parsing XML and generating corresponding tags and metadata within the MPEG-TS encapsulated video stream.

SCTE-35 tags are also supported in HLS/DASH manifests, indicating the switch to ad content at specified time intervals. Here, let's take HLS as an example to introduce several commonly used tags.

EXT-X-DATERANGE
This is one of the newer recommended ways to encapsulate SCTE-35 in HLS according to the HLS standard, for example:
#EXT-X-DATERANGE:ID="", START-DATE="", DURATION=15.000,SCTE35-OUT=0xF
EXT-X-CUE-OUT and EXT-X-CUE-IN
This is currently a more popular usage method, where "OUT" represents the start of playing an ad, and "IN" represents the end of the ad. For example:
#EXT-X-CUE-OUT:DURATION=100
...
#EXT-X-CUE-IN
Typically, the use of "EXT-X-CUE-OUT-CONT" indicates that the subsequent segments are still part of an ad.
EXT-X-SCTE35
This method is specified in the SCTE-35 RFC, but it has not yet been adopted as an official RFC standard for HLS.

Here are two examples.

SCTE-35 in HLS

SCTE-35 in DASH

Once the event identifier is available, the program, upon recognition, needs to retrieve ad information from the ad decision service. This is where the standard between the ad player (or an ad insertion server) and the ad decision service comes into play.

What is VAST?

VAST (Video Ad Serving Template), VPAID (Video Player-Ad Interface Definition), and VMAP (Video Multiple Ad Playlist) are the primary advertising service standards established by the Interactive Advertising Bureau (IAB). By utilizing these standards, the entire advertising ecosystem operates seamlessly in the process of creating, editing, delivering, and tracking ads.

Here, we primarily introduce the fundamental and crucial standard, VAST. It serves as the standard between the ad player and the ad serving service, an open protocol developed by the Interactive Advertising Bureau (IAB). VAST aims to connect content creators, content distributors, and ad trackers. Initially created by DoubleClick, VAST became the advertising standard for YouTube after being acquired by Google and has since become the de facto industry standard.

VAST

VAST supports multiple ad formats:

Linear Ads: Linear ads are the most common video ad format where the ad is displayed in the same area as the video content, but with different durations. When displayed before the video content, it is called a pre-roll ad. Additionally, there are mid-roll and post-roll ads.
NonLinear Ads: Nonlinear ads, also known as In-Stream ads, are displayed simultaneously with the video content. They typically cover a portion of the bottom or top of the video player and can be in the form of text, images, or interactive ads.
Companion Ads: Companion ads are banner ads or rich media ads that appear outside of the video player.
Skippable Linear Ads: These ads allow viewers to skip the ad within the first few seconds and continue watching the video content. This ad format can enhance the effectiveness of the advertisement while reducing viewer dissatisfaction and annoyance towards the ad.
Ad Pods: Ad Pods are a sequence of linear ads that can be played back and forth.

VAST contains the following key points:

VAST Ad Requests : VAST primarily defines the data format for responses and does not have specific requirements for requests. Typically, requests for ads (Ad Decision Server) in VAST are made using formats such as HTTP/HTTPS or OpenRTB. The Ad Decision Server, which is part of the ADX advertising exchange platform, makes real-time decisions and delivers ads based on the needs of advertisers and the inventory of ad media, combined with client-side user profile information. When making a VAST request, the ad insertion endpoint includes client information, such as X-Device-IP (the IP address of the player) and X-Device-User-Agent (the user agent of the player), through methods like HTTP headers.
Extracting MediaFile Nodes from the Response : After receiving a response from the ADS, the VAST requesting endpoint parses the XML and extracts key information such as MediaFile and Tracking URLs. If the response includes a <Wrapper> element, it indicates that the target address provides a method to redirect the media player to another ad server to retrieve an ad, multiple ads, or another VAST Wrapper. The <Error> element allows the media player to provide feedback to the ad server when it is unable to serve an ad. The VAST RFC provides detailed error codes and formatting specifications.
Tracking : After the video player obtains ad information following the VAST specifications and displays the corresponding ad video, it is necessary to accurately report the ad's tracking information to the ad server according to the VAST specifications. The tracking information of the ad is crucial for cost settlement and performance measurement. Advertisers and publishers rely on accurate tracking records for billing, campaign performance measurement, market analysis, and other important business data statistics. The absence of correct ad tracking information can lead to a series of settlement issues between ad service providers and video media providers.

Using Tencent MPS Stream Service

On Tencent MPS Stream Service, it is possible to implement CSAI (Content-Segmented Ad Insertion) based on SCTE-35 event signaling, as well as dynamic ad insertion based on SSAI (Server-Side Ad Insertion). Below are the playback comparison results from four different players after ad insertion using Tencent's Stream Service platform. As shown, each player inserted different ad videos at the same playback time point.

There are two ways in which Stream Service generates SCTE-35 markers. The first method is when using MPEG-TS streaming protocols such as RTP/SRT/UDP, where the source stream already contains SCTE-35 data. In this case, Stream Service can be configured to pass through the SCTE-35 data (SCTE-35 passthrough) and generate corresponding protocol tags in HLS/DASH playback protocols.The second method involves using Stream Service's scheduling and orchestration feature. It allows for the insertion of desired SCTE-35 events at specified times or the current moment (SCTE-35 insert), followed by further processing.

workflow of SSAI

The approximate workflow of SSAI is as follows:

The streaming source pushes the live stream to StreamLive for transcoding, packaging, and insertion of SCTE-35 ad event markers, and then transfers it to StreamPackage. If there are no further processes, it means that all server-side steps in CSAI have been completed.
The player requests the manifest (m3u8/mpd), and StreamPackage receives the relevant information for backhaul while parsing the m3u8/mpd and checking the SCTE-35 tags.
StreamPackage requests the Ad Decision Server, parses the VAST/VMAP response, and retrieves the ad video URL.
Download the ad video, transcode it, and store it.
Update the transcoded ad segment URLs by inserting and replacing them in the m3u8/mpd files, and distribute them. An example of the modified m3u8 content after replacement is as follows.
After playing the ad on the client-side, StreamPackage reports to the ad tracking service for tracking purposes.

Additionally, if using the CSAI method, the player needs to support SCTE-35 parsing and VAST standard to retrieve the ad video URL. If using the SSAI method, where insertion and replacement are done on the server-side, the player does not require any special mechanisms and can support regular HLS or DASH playback (with support for parsing the EXT-X-DISCONTINUITY tag).

If you have relevant business needs or would like to further understand Tencent MPS, please let us know. You are welcome to Contact Us for more information.