From the Venue to the
Ad Decisioning Layer

Data-Driven Markers

Turn real-time data into SCTE-35 with an Edge App

A marker does not require a button press. LiveEdge exposes SCTE-35 insertion through a REST API and runs containerized applications on the same platform that encodes the event. The Edge App receives data, applies customer-defined rules, and invokes the local SCTE-35 API when a condition is met.

Potential trigger inputs

LiveEdge provides the programmable execution environment and marker-insertion interface; it does not imply that every scoreboard connector, data provider, detection model, or business rule is included as a built-in feature.

1. A containerized Edge App receives the webhook or polls the authorized data source.
2. The application validates the event, source, event identifier, and timestamp.
3. It checks local state or policy—for example, that the production is live, the correct output is enabled, and an equivalent event has not already been processed.
4. A rules engine maps the timeout to a 30-second placement opportunity with four seconds of preroll.
5. The application calls the local LiveEdge SCTE-35 splice_commands endpoint.
6. LiveEdge constructs and inserts the splice_insert command into the MPEG-2 transport stream.
7. The application records the decision, API request, device response, and correlation identifier.
8. Downstream monitoring confirms that the cue reached the packager or SSAI service and that the expected manifest and ad-decision events occurred.

IF event.type == "official_timeout"
AND event.status == "started"
AND output.primary.state == "streaming"
AND event.id has not already been processed
THEN request splice_insert(preroll=4000 ms, duration=30000 ms)
AND record event.id, request, response, and UTC timestamps

The Edge App should retain an event or correlation identifier and implement idempotency, debounce windows, and state-transition logic so one real-world event produces one marker sequence.

Explainable Automation

Data-driven signaling and auditability belong together

Every automated decision should be explainable after the event. In addition to LiveEdge device logs, the Edge App should record the source data, rule version, decision, exact SCTE-35 request, timestamps, and API response.

The record traces source data → automation rule → marker request → edge execution → downstream observation.

Configuration

Configuring the SCTE-35 Data Encoder

The REST API is exposed on port 2020. Before creating a profile, an application should enumerate the existing Data Encoders. If the response already contains a Data Encoder whose codec is scte35, reuse its returned identifier—attempting to create a duplicate can return an HTTP 500 error.

GET http://[IP_ADDRESS]:2020/v2/encoders/data_encoders

POST http://[IP_ADDRESS]:2020/v2/encoders/data_encoders
Content-Type: application/json

{
  "name": "SCTE-35 Data Encoder",
  "codec": {
    "value": "scte35",
    "scte35": {
      "splice_duration": 30000
    }
  }
}

splice_duration is expressed in milliseconds. In this example, the default opportunity duration is 30,000 milliseconds, or 30 seconds. The POST response returns the Data Encoder identifier needed for subsequent configuration and splice-command requests. JSON sent to the device must be valid JSON—comments used in documentation examples are not valid JSON and must be removed from actual requests.

PUT http://[IP_ADDRESS]:2020/v2/encoders/data_encoders/[DATA_ENCODER_ID]
Content-Type: application/json

{
  "name": "SCTE-35 Data Encoder",
  "codec": {
    "value": "scte35",
    "scte35": {
      "splice_duration": 60000
    }
  }
}

Attach to a running output

1. Create or select the SCTE-35 Data Encoder.
2. Select an input source when using SCTE-104 translation.
3. Add the Data Encoder as a data source on the desired output.
4. Save the configuration.
5. Enable the output and verify that it is streaming successfully.

End-to-End Validation

Downstream integration and resilient operations

Before production deployment, test the complete workflow with the actual SCTE-104 source, LiveEdge configuration, contribution transport, downstream platform, and commercial requirements. AWS Elemental MediaPackage, for example, can process SCTE-35 in source content and produce corresponding markers in HLS, CMAF, and DASH outputs—but only if the origin or packager is configured correctly.

• Accepted command type and message structure
• Required preroll and duration handling
• Cue-out, cue-in, and cancellation behavior
• Event identifier expectations
• SCTE-104 compatibility and translation
• Preservation through SRT, Zixi, multicast, unicast, or RTSP
• Behavior during packet loss or reconnects
• GOP and splice-point alignment requirements
• Conversion into required HLS or DASH tags
• SSAI interpretation and ad-decision behavior
• Slate or underlying program when no ad is returned
• Multi-destination behavior across platforms
• Clock synchronization and timestamp correlation
• Source, transport, packager, SSAI, and playback logging

Production practices

Design for an observable, managed service

For one event, an operator pressing a button may be sufficient. At hundreds or thousands of venues, cue generation should be treated as an observable, managed service.

• Synchronize devices to reliable NTP and monitor clock health
• Attach the correct SCTE-35 Data Encoder from a configuration template
• Validate that the intended output is active before accepting a cue
• Use authenticated, access-controlled applications to call device APIs
• Record trigger source, parameters, device identity, response, and timestamps outside the device
• Use stable event identifiers across scheduling, control, edge, and downstream systems
• Make operator controls idempotent or protected against double presses
• Display acknowledgements and error states rather than assuming success
• Monitor the outgoing MPEG-2 TS independently for SCTE-35 presence
• Validate the downstream HLS/DASH manifest and SSAI transaction
• Define fallback behavior for missed cues, incorrect duration, and lost connectivity
• Test the complete workflow as far in advance of go-live as possible