Introduction
SCTE-35 carries timed cue messages that distribution systems can use to mark ad opportunities, program boundaries and other events. Detecting the binary message is only the first monitoring step. Operations teams must verify that the cue appeared in the right service, carried expected fields, aligned with presentation time, survived packaging and produced the intended downstream behavior.
An evidence-based workflow follows the event from automation through encoder, compressed stream, manifest and ad-insertion systems. That makes it possible to locate the handoff where a cue was lost, changed or interpreted differently.
Key Takeaways
- SCTE-35 signals an event; it does not contain or select the replacement advertisement.
- Monitor both the raw cue and its parsed fields.
- Compare expected events with observed cues, manifest markers and downstream decisions.
- Time checks must account for presentation timestamps, delays and transformations.
- Retain correlated evidence so operations can diagnose failures after the event.
Table Of Contents
- What SCTE-35 signals
- End-to-end signal path
- Fields and message patterns to verify
- Monitoring points
- Troubleshooting playbook
- FAQs
What Does SCTE-35 Signal?
SCTE-35 defines cueing messages used in compressed media workflows. Common patterns include splice_insert commands and time_signal commands with segmentation descriptors. The message can carry identifiers, timing information, duration and descriptors that downstream systems interpret according to the agreed workflow.
The current SCTE-35 Part 1 catalog entry is the primary source for the standard’s published scope and revision. Implementers should consult the licensed standard and the profiles required by their partners.
The cue marks an opportunity or boundary. It does not make the business decision about which ad to play, fetch the creative or prove that a viewer received it. Those actions occur in downstream packaging, ad-decision, stitching and playback systems.
The End-To-End SCTE-35 Signal Path
Broadcast automation may originate an event request, often through SCTE-104 before compression. An encoder converts the relevant instruction into SCTE-35 within the transport workflow. A packager reads the cue and represents it in HLS or DASH according to its supported configuration. Server-side ad insertion or another downstream component makes a decision and prepares the replacement experience.
| Stage | Expected Evidence | Common Failure |
| Schedule and automation | Event ID, expected start, duration, source command | Wrong route, missing trigger, stale schedule |
| Encoder input | Received automation message and mapped service | Port, service or mapping error |
| Compressed stream | Raw SCTE-35 section and parsed fields | Missing, malformed, duplicated or late cue |
| Packager | Manifest marker and matching time range | Unsupported message or packaging configuration |
| Ad-insertion system | Recognized event and decision log | Rule mismatch, unavailable decision, timing conflict |
| Output and playback | Resulting media and viewer-facing transition | Discontinuity, slate, gap, overlap or wrong content |
AWS MediaPackage’s SCTE-35 documentation is one product-specific example of how input messages can be handled and represented. Do not assume another packager accepts the same command set or emits the same manifest markers.
Which SCTE-35 Details Should Monitoring Verify?
Start with command and descriptor type. A downstream system may act on time_signal plus selected segmentation types but ignore a different command. Capture event identifiers so a start, end, update or cancellation can be related.
Check timing in presentation context. The parsed splice time, PTS adjustment and observed media timeline need to be evaluated together. Network and processing delays can make wall-clock comparison misleading if the monitoring system does not model them.
Review duration and pairing. Some workflows use a declared break duration, explicit start and end signals, or both. Operations should know the expected pattern and detect an orphaned start, unexpected end or material duration mismatch.
Verify service and stream placement. A valid cue on the wrong service is still an operational failure. Record program, input, output and distribution identifiers so evidence can be traced without relying on one PID or packaging assumption.
Finally, preserve the raw payload. A parsed dashboard field is useful for triage, while the source bytes and capture context allow deeper inspection when different decoders disagree.
Monitor Every Transformation
MonitorIQ is Digital Nirvana’s broadcast monitoring and compliance-logging product family. SCTE-35 monitoring belongs in that operational evidence layer, alongside signal observation, ad verification and proof of performance.
An effective view correlates expected schedule events, observed cues and downstream output. Alerting should distinguish at least these states:
- Expected cue missing from the monitored service
- Unexpected cue with no matching schedule or policy event
- Malformed or unsupported message
- Cue detected outside the allowed timing tolerance
- Duplicate event or repeated action
- Start without end, end without start or duration mismatch
- Stream cue present but manifest marker absent
- Manifest marker present but downstream decision or output failed
Digital Nirvana’s guide to AI broadcast monitoring, compliance and QoE explains the broader need to connect automated detection with reviewable operational evidence. Its article on multiviewer monitoring covers visual and signal views used by broadcast teams.
A Troubleshooting Playbook
First, confirm the event definition: service, expected time, duration, identifier and message pattern. Second, check whether automation emitted the trigger and whether the encoder received it. Third, capture and decode the stream at the earliest available point after encoding.
Fourth, compare the same event before and after each transformation. If the stream cue is correct but the HLS marker is missing, focus on packager support and configuration. If the marker exists but no ad decision follows, inspect downstream recognition, availability rules and decision logs.
Fifth, preserve a time-bounded evidence package. Include raw cues, parsed fields, manifest excerpts, schedule data, alerts, output recording and operator notes. This lets engineering investigate after a transient live condition has passed.
The AWS MediaTailor HLS ad-marker guide shows that manifest marker behavior is implementation-specific. Match troubleshooting to the actual packager and insertion stack.
FAQs
SCTE-35 is a standard for timed cue messages in compressed digital media workflows. Distribution systems can use the cues to identify ad opportunities and other events.
No. It signals an event. Downstream systems apply business rules, select or prepare replacement content and manage playback.
It is a component that parses the binary message into readable commands, timing and descriptors. Monitoring should retain both the decoded view and raw payload.
SCTE-104 commonly carries automation information before compression. An encoder can translate the applicable instruction into SCTE-35 for the compressed stream.
It may appear on the wrong service, use an unsupported message pattern, arrive outside timing tolerance, fail packaging or conflict with downstream rules.
Retain expected event data, source triggers, raw and parsed cues, stream context, manifest markers, downstream logs, output recording and operator actions.
Conclusion
SCTE-35 monitoring must follow the event, not only detect the packet. Correlating schedule, automation, stream, manifest and output evidence shows whether a cue was correct and where downstream behavior diverged. That reduces guesswork during live incident review.
To discuss SCTE-35 monitoring, ad verification and proof-of-performance workflows, contact Digital Nirvana.
