With the advancement of streaming media technology and applications on internet, it is apparent that Ad-supported streaming media delivery has become a major monetization strategy. In this article, we will introduce a solution for dynamic advertising insertion in live streaming media.

Dynamic Ad Insertion on the Server-side
Tencent Cloud Media Services supports dynamic Ad insertion by using the server-side Ad insertion. The following are the playback comparison effects of four players with the Ad insertion through StreamService, the streaming media platform of Tencent Cloud Media Services. As you can see, four different advertisements were displayed simultaneously.

The following is an introduction to how to implement this dynamic advertising solution in live streaming media.

Streaming Media Advertising Evolution
First, let's briefly understand the architecture and process of advertising delivery in a streaming media platform.

How are Ads exchanged

The key roles in advertising exchanging and delivery include DSP (Demand Side Platform), SSP (Supply Side Platform), and ADX (Advertising Exchange System).
DSP, Demand Side Platform, is the demand side of advertisement exchanging, typically referred to advertisers.
SSP, Supply Side Platform, is the content publishing platform that provides content resources and Ad spaces. It is generally composed of content copyright holders (such as film and television producers, news publishers, sports organizers, etc.) and publishing platforms.
ADX, ADvertisement Exchange (AdExchange), is the online advertising exchanging system responsible for connecting content publishers and advertisers, as well as handling billing and transactions. Due to the progressive automation of advertising systems, RTB (real-time bidding) is also employed to refer to AdExchange.

The Method of Streaming Media Advertising Displaying

In the early stages of the Internet, video advertising was mainly implemented through Flash animations or GIF images on websites. These Ads were usually static, without any sound or animation effects.
As a result, advertising became more integrated with the video content itself, and Ads could be inserted either before video playback (pre-roll), during (mid-roll), or after (post-roll). The choice of Ad insertion positions depends on the combination of Ad positions that the video service provider wants to use. They can also choose to combine videos into Ad-pods, allowing advertisers to insert multiple Ads consecutively during Ad time.

In the streaming media advertising field, there are two methods for inserting Ads into the live streaming: CSAI (Client-Side Ad Insertion) and SSAI (Server-Side Ad Insertion). CSAI refers to the progress of inserting Ads on the client side, where the client (such as a video player) directly requests Ads from the Ad server when it reaches a cue for Ad insertion (in the video stream or playlist) and plays the Ads during the specified time period. Upon receiving a request from the client, the Ad server provides the optimal Ad to the specific client and responds with Ad information through data analysis. Consequently, the video player pauses the video, plays the Ad, and resumes video playback.

CSAI

Another Ad insertion method is SSAI: unlike CSAI, which inserts Ads at the client-side, SSAI directly stitches Ad media files into the video stream (on the server-side rather than on the client-side). The advantage of SSAI is that the Ad content is not easily blocked or tampered with, and the client does not need to make server interface calls to initiate Ad insertion tasks. In CSAI, the client needs to make requests to the Ad server, which can be easily blocked by plugins or other Ad blockers, thereby reducing the revenue of 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 complicated workflow and requires higher stability and quality for the system.

SSAI

Related Technical Standards
As mentioned earlier, both CSAI and SSAI require the program to recognize the Ad cue or the Ad event markers, which can be realized through SCTE-35.

SCTE-35
SCTE-35 is the core signaling standard for advertising and distribution control of content for content providers and distributors, which is developed by the Society of Cable Telecommunications Engineers (SCTE) in the United States. The SCTE-35 standard defines a binary message format for identifying upcoming Ad start points and Ad end points in a live or vod stream. This allows Ads to be seamlessly inserted and removed from the video stream without affecting the continuity of the video playback.

SCTE-35 Schematic
SCTE-35 is composed of SpliceInfoSection, which can be represented as structured data in XML or as a binary structure. The SCTE-35 standard defines a variety of specific time types and fields, which will not be elaborated on here.

SCTE-35 in HLS/DASH
SCTE-35 tags are supported in HLS/DASH manifests, indicating when to switch to Ad content during a specified time period. The following sections provide more information about the SCTE-35 tags used in the HLS manifest.
1. EXT-X-DATERANGE This is a newer way of encapsulating SCTE-35 in HLS recommended by the HLS standard, for example. #EXT-X-DATERANGE:ID="",START-DATE="",DURATION=15.000,SCTE35-OUT=0xF
2. EXT-X-CUE-OUT and EXT-X-CUE-IN This is a more popular usage, where OUT represents the start of Ad playback, and IN represents the end of the Ad, for example #EXT-X-CUE-OUT:DURATION=100 ... #EXT-X-CUE-IN Usually,
EXT-X-CUE-OUT-CONT is used to indicate that the following segments are still Ads.
3. EXT-X-SCTE35 This method is specified in the SCTE-35 RFC but has not yet been adopted as an HLS RFC standard.
Here are two examples of an HLS/DASH manifest with SCTE-35 Ad markers generated from Stream Service.

SCTE-35 in HLS

SCTE-35 in DASH
With the Ad markers, the program can get the Ad information from the Ad decision server after reaching the Ad cue. Here, a standard needs to be defined between an Ad playback client (or a server that performs Ad insertion) and an Ad decision server.

VAST
VAST (Video Ad Serving Template), VPAID (Video Player-Ad Interface Definition), and VMAP (Video Multiple Ad Playlist Protocol) are the main Ad-serving standards established by the IAB (Interactive Advertising Bureau). By using these standards, all participants in the entire advertising ecosystem work closely together in the process of creating, editing, delivering, and tracking Ads. VAST, which is the standard between the Ad playback end and the Ad service provider, is the most basic and critical standard. It is an open protocol developed by IAB to connect content producers, content distributors, and Ad statisticians.

Ad types that comply with VAST are as follows:
1. Linear Ads, the most common form of advertising in live streaming, displayed in the same area as the video content but at different times. The Ads displayed before the video content are called pre-roll Ads. In addition, there are mid-roll and post-roll Ads.
2. NonLinear Ads, also known as In-Stream Ads, are displayed simultaneously with the video playback content, usually covering a part of the bottom or top of the video player. They can be text, image, or interactive Ads.
3. Companion Ads, banner Ads or rich media Ads that appear outside the video player.
4. Skippable Linear Ads, the Ads that allow viewers to skip within the first few seconds of playback and continue watching the video content. This form of advertising can improve Ad effectiveness while reducing viewer dissatisfaction and resentment.
5. Ad Pods, a sequence of linear Ads that can be played back and forth.

VAST Ad Requests
Historically, VAST mainly specifies the response data format and has no specific requirement for the request mechanism. It usually sends HTTP/HTTPS or OpenRTB requests to ADS (Ad Decision Server, a part of the ADX, used to make real-time decisions and deliver Ads based on advertiser demand, Ad media inventory, and the user profile information). In addition, in SSAI, when making a VAST request, the Ad insertion server should send client personalized information with HTTP headers, such as X-Device-IP (playback end IP), and X-Device-User-Agent (playback end user-agent), etc.

Extraction of Ad Address
Upon receiving the ADS response, the VAST requester will parse the XML, extracting the required information such as MediaFile and Tracking URLs. If a Wrapper response(with a <Wrapper> element) is received, the player makes a secondary request to another server. The secondary response may be an InLine response or another VAST Wrapper. The <Error> element allows the media player to provide feedback to the Ad server when it cannot provide an Ad. More detailed error codes and format specifications are elaborated in the VAST specs. Eventually, after a series of requests and responses, an Ad server response with an InLine node, which means the advertising address has been successfully obtained by the requester. Ad address can be only provided with a URI under <MediaFile> element.

Tracking
When the video player retrieves the Ad information complying the VAST specification and displays the corresponding Ad video, the video player also needs to correctly report the Ad tracking information to the Ad server according to the specification. Ad tracking information is an important basis for Ad cost settlement and effectiveness measurement. Advertisers and publishers rely on accurate tracking records for billing, campaign effectiveness measurement, market analysis, and other important business data statistics. A lack of correct Ad tracking information will lead to a series of settlement issues between Ad service providers and video media providers.

How Does StreamService Performs Server-side Ad Insertion
On Tencent Cloud's audio and video product StreamService, you can implement CSAI Ad insertion based on SCTE-35 Ad markers, as well as dynamic Ad insertion based on SSAI.
There are two ways in Stream Service to generate SCTE-35 markers. One is the to use the Ad marker passthrough when the source stream already has SCTE-35 Ad markers, generally packaged in MPEG-TS over RTP/SRT/UDP, and generate Ad cue tags in the playback protocol such as HLS/DASH. The other is to use Stream Service's plan scheduling management to insert the required SCTE-35 Ad markers (SCTE-35 insert) immediately or at a specified time, which can be triggered by a web console or API. For more information about SCTE-35 insertion, see Plan Management | Tencent Cloud.

The complete general process of SSAI is as follows:
1. The publisher pushes the live stream to StreamLive for transcoding, packaging, and inserting SCTE-35 Ad markers, and then transmits it to StreamPackage. If there are no subsequent processes, step 1) has already completed all server-side steps in CSAI.
2. The player requests the manifest (m3u8/mpd), and StreamPackage fetches the origin manifest while parsing the manifest and checking the SCTE-35 Ad markers.
3. StreamPackage send the request to the Ad Decision Server, parses the VAST/VMAP response, and obtains the Ad video address.
4. StreamPackage downloads the Ad video, transcodes and stores it.
5. StreamPackage updates the transcoded Ad segment url in the manifest by inserting and replacing, and then distribute it. An example of a replaced m3u8 content is shown below.

6. After the Ad is played on the client-side, StreamPackage reports to the Ad Tracking service for tracking the event.
For more information about SSAI, see Server-Side Ad Insertion | Tencent Cloud.

What Should the Player Do?
In CSAI, the player needs to support SCTE-35 and VAST standard to obtain the Ad video address. However, in SSAI, since the insertion and replacement are performed on the server-side, the player does not require any special mechanism and only needs to support HLS or DASH (only support for parsing the EXT-X-DISCONTINUITY tag).