Using ESAM for SCTE 35 signal conditioning
In modern linear workflows, event signaling and management (ESAM) is used to enrich the conditioning of SCTE 35 signals within a live stream. The SCTE 35 standard—created by the American National Standards Institute (ANSI) and the Society of Cable Telecommunications Engineers (SCTE)—states, “SCTE 35 is the core signaling standard for advertising, program, and distribution control of content for content providers and content distributors.” With the increased maturity of channel playout systems, content providers are able to produce their linear channels with SCTE 35 signals for the advertising and content replacement use cases mentioned above. Likewise, service providers are starting to use ESAM for SCTE 35 signal conditioning in order to produce more advanced content replacement workflows, using a combination of over-the-top (OTT) manifest decoration and manipulation. Although the various signaling types are enhancing linear workflows in general, they also introduce the need for refined conditioning. Below are some reasons for using ESAM in linear workflows to condition SCTE 35 signals:
- Filtering/removing unwanted SCTE 35 signals
- For example, a service provider may want to remove provider advertisement signals to not confuse downstream ad insertion components.
- Converting the SCTE 35 signal
- For example, a service provider needs to convert a “splice_insert” signal to a “time_signal” for greater compatibility.
- Creating or modifying program SCTE 35 signals based on schedules
- For example, a service provider needs to modify SCTE 35 signals based on an event scheduling and notification interface (ESNI) IO2 schedule for program replacement or an SCTE 224 schedule for content replacement rules/policies.
- Modifying the parameters of an SCTE 35 signal
- For example, some SCTE 35 signals for ad insertion are missing duration, which is required for OTT ad insertion. The missing duration may be a result of the translation of an SCTE 104 signal to SCTE 35. Modification might also include removal or addition of flags that influence downstream components (e.g., “delivery_not_restricted”) and adding relevant data to the “segmentation_upid” field in the SCTE 35 signal.
This post focuses on ESAM using Amazon Web Services (AWS) solution AWS Elemental Live, which lets users encode live video on premises for events and 24/7 streams and supports the ESAM I03 standard. ESAM is the interface that an encoding appliance or service would use to contact a placement opportunity information service (POIS). POIS is a service that contains a repository of information and/or rule sets for each channel, outlining how to respond to conditioning requests from the encoder. These conditioning requests are called signal processing events (SPEs). AWS Elemental Live is a linear encoding application that lets you create live outputs for broadcast and streaming delivery. The AWS Elemental Live encoder has a robust ESAM interface and provides detailed logging for POIS interactions and SCTE 35 signal conditioning. AWS Elemental Live supports two types of ESAM API interactions:
- Signal confirmation and conditioning (SCC)
- AWS Elemental Live sends a conditioning request (an SPE) containing details on the received SCTE 35 signal to the POIS. The POIS then sends a conditioning response signal processing notification (SPN), instructing AWS Elemental Live on how to process the SCTE 35 signal.
- Manifest confirmation and conditioning (MCC)
- The MCC interface is required at the packaging (fragmenter) level. In most linear workflows today, the encoder and the packager are decoupled, so the MCC interface would typically reside on the packaging application. An ESAM MCC API is integrated in AWS Elemental Live because it can create multiple bitrate (MBR) streams and packages to various formats in real time. AWS Elemental Live sends a manifest confirmation containing details on the received SCTE 35 signal to the POIS. The POIS responds with conditioning information, instructing the AWS Elemental Live encoder on how to decorate the Hypertext Transfer Protocol (HTTP) Live Streaming (HLS) manifest.
The ESAM SCC interface on AWS Elemental Live has exclusively been used for SCTE 35 signal validation and conditioning for the aforementioned use cases. A call to the POIS is made once the SCTE 35 signal is seen in the active input stream. AWS Elemental Live conditions the SCTE 35 signal accordingly and places the updated SCTE 35 signal in the output stream.
Using ESAM for input switching
In addition to SCTE 35 signal conditioning, AWS Elemental Live can now use the ESAM SCC interface to switch the active input on a running event. AWS Elemental Live supports both synchronous ESAM, which provides frame-accurate switching based on inbound SCTE 35 signals, and asynchronous ESAM, which involves POIS-driven input switches based on schedule data. This feature lets an operator switch from one program within a multiprogram transport stream (MPTS) to a different program, for cases such as switching between a national broadcast feed and a localized station feed.
If you don’t have a POIS vendor, you can deploy a POIS reference server from GitHub to get started. The POIS reference server has some rudimentary POIS functionality for SCTE 35 signal conditioning and should be used for testing purposes only.
In this blog post, you learned how ESAM can be used in modern live streaming workflows using AWS Elemental Live. Stay tuned for Part 2: SCTE 35 signal conditioning in AWS Elemental Live, and Part 3: Virtual input switching in AWS Elemental Live.