SCTE 104/35 Codex

Carrying SCTE 35 in HLS and DASH

14

Once a signal leaves MPEG-2 transport for adaptive streaming, carry the whole message rather than a stripped subset, so nothing is lost when more of it is needed later. Base64 of the full splice_info_section preserves every byte exactly; the SCTE 35 XML round-trips the defined structure faithfully but is best-effort for unknown or private data, so treat it as a structural copy rather than a guaranteed byte-for-byte one. SCTE 67 recommends that every rendition in an adaptive set carry the same signals, matched by both identifier and presentation time, and that any audio-only fallback carry them too so signaling survives a drop to audio; PTS timing is converted to the streaming timeline. In DASH many events line up with Periods and ride in an MPD EventStream or in-band emsg boxes; the presentation timing declared in the EventStream or emsg governs the streaming timeline (clause 14.1.4.4), so processors should trust those event times, not the raw PTS in the message. In HLS, EXT-X-DATERANGE is the recommended tag: it carries the SCTE 35 as a hexadecimal string in its SCTE35-CMD, SCTE35-OUT, and SCTE35-IN attributes, per RFC 8216 section 4.3.2.7.1. The older EXT-X-SCTE35 tag is the legacy path, and there the message rides Base64-encoded in the CUE attribute; either way, segment boundaries align to the splice in and out points. The byte-level SCTE 35 message stays authoritative; the streaming tags only map its timing onto the presentation timeline.

Related fields