The document discusses SCTE 35 markers, which are used to signal ad breaks and programming changes in live linear video streams. It describes the different types of SCTE 35 messages, including splice insert commands, segmentation descriptors, and time signal commands. It also explains how these messages can be combined and nested to indicate complex events like ad pods within breaks. Finally, it shows how SCTE 35 markers can be conveyed to clients via tags in HLS and DASH manifests to synchronize playback with the broadcast stream.

1. Hi and thanks for reading along! These slides are from a talk I gave at Demuxed in October 2017.
I’m Allison Deal, I work as a soEware engineer in the video space, and I wanted to share some of
my personal learnings on the topic of ad signaling in live linear streams. I’m going to dig into the
SCTE 35 spec and show how integraMon of ad markers might look in a streaming service,
including some irregulariMes to look out for and what keep in mind when working with in-band
ad cues.
---
Demuxed Video Engineering Conference: hQps://demuxed.com

2. I’ll start with defining our main challenge here, which is taking the input of tradiMonal broadcast
television and creaMng a personalized OTT experience.

3. In order to create a seamless, familiar product for users, and perhaps due to business goals or
contracts, we have some potenMal, related elements of the user experience we might want to
incorporate into our service, in addiMon to the obvious goal of video playback. Maybe we want
the user to have visibility of what live content is currently available to them. Like the tv program
guide, we want a real-Mme view of what is airing on a given channel. To achieve this, we need to
have schedule flexibility for cases like program extensions (where a sporMng event goes into
overMme and runs long) or unscheduled events (like breaking news). We also need precise
informaMon for program distribuMon control, including blackouts (where a sporMng event can’t
be shown in a parMcular area if the stadium isn’t sold out), or device restricMons, where certain
content contractually can’t be shown on one or more devices. We may also want to know the
precise Mming of adverMsements in order to do things like freeze transport controls (and
prevent fast forwarding through a commercial), incorporate an ad countdown in a UI, or
personalize the user experience by incorporaMng dynamic ad inserMon.
I list all of these because they can be implemented using the same type of marker messages
that I’m going to go through in detail now.

4. Broadcast television has the capability to dynamically replace the network feed with ads, which
will vary based on the air Mme available and a household’s geographic locaMon.

5. Historically, local ads were indicated using dual tone mulM frequency, or DTMF signals, and in
order to describe these DTMF signals digitally, in an MPEG-2 transport stream,

6. SCTE, or the Society of Cable TelecommunicaMons Engineers, defined the Digital Program
InserMon Cueing Message for Cable, beQer known as the SCTE 35 standard. This standard
defines the signaling technique for adverMsing breaks and programming content at a frame
accurate level.

7. So how can we uMlize this signal to automate the experience goals we set earlier? And when I
say “automate” I mean that we don’t want to require someone to be watching the channel 24/7
and confirming that an ad started, or a baseball game went long, for which we would be difficult
to manually scale across hundreds of channels.
I’m going to walk through a generic message flow of consuming these messages, decoding,
parsing and understanding them, and then noMfying the client of the state of a channel. And
this isn’t a specific implementaMon, only high level design concept.

8. First, I’ll mainly focus on this porMon of the workflow, which is the ingesMon, decoding, and
interpretaMon of the markers.

9. The ad cue messages are someMmes carried in binary format, and mulMplexed with the audio
and video in a MPEG-2 transport steam.

10. In HLS and DASH, the cue messages usually get converted to base64 or hex strings. If stream
ingesMon is done using HLS format, it’s also common to include these markers in either the EXT-
X-DATERANGE tag or a custom SCTE 35 tag of the HLS media playlist.

11. And least common, but there is a defined way to include parsed cue details into the XML.
However we’re going to assume this isn’t the case for the parsing porMon of the discussion.

12. When you hear SCTE 35 message, or ad marker, it oEen refers to the contents of what’s called
the splice info secMon. This message contains all of the details we need to know about the splice
point, which is the source switch point: where an ad or ad break starts or ends, or a a new
program or chapter starts or ends. In this talk, I’m going to dig into two of the most-used
secMons of this message, which are the splice insert splice command (in blue) and the splice
descriptors (in red).

13. Let’s look at the splice insert command first.

14. Splice insert was the first command implemented because it solved for the simple scenario of
instrucMng local affiliates and MVPDs when to switch from the network source to the local ad
playout and then back to network. The splice event id is an idenMfier to keep track of the event.
The splice event cancel indicator will indicate whether, if there have been any events previously
sent with this id, to cancel them, which makes last minute schedule changes and updates
possible. The out of network indicator indicates whether we should exit from the network feed,
which is called and out point, or return to the network/show we were watching, and this is
called an in point. This informaMon is important because it’s indicaMng either “we’re going to an
ad break now,” or “we are going back to showing the program.” The duraMon represents how
long the ad break is planned for, the unique program id is specifies the viewing event, and the
event’s Mmestamp, or splice Mme, can be specified in the splice Mme structure, here in green.

15. Next, let’s check out the segmentaMon descriptor, here, in red. As you see in the splice info
secMon structure, there is only room for one splice insert event per message. The informaMon it
contains is limited, but it’s sMll widely used. A splice info secMon can contain mulMple
segmentaMon descriptors.

16. For example if a program is ending and at the same point a new program is starMng, we can
receive this informaMon in one SCTE-35 message, uMlizing mulMple segmentaMon descriptors.
As opposed to only expressing one type of local ad, a segmentaMon descriptor can indicate one
of many different event types, carried in the segmentaMon type id field, like program start/end
or program early terminaMon, chapter start/end, provider and distributor ad start/end,
unscheduled event start/end (like breaking news), planned and unplanned program runover
events, and content idenMficaMon heartbeat messages. It’s these segmentaMon descriptors that
allow our “program guide” or menu to be updated automaMcally in the case of a long game, or
to indicate whether or not the airing should be shown on the menu due to restricMons like
blackouts.
Like the splice insert command, it contains an event id, a cancel indicator flag, and duraMon flag.
The segmentaMon descriptor also has fields to denote delivery restricMons, although the only
one I’ve seen commonly used is the web delivery allowed flag (for global blackouts) and the rest
is conveyed through SCTE-224 out-of-band policies.
The segmentaMon UPID specifies the content contained in the segment, which can be various
formats, including Ad IDs, TMS IDs (Gracenote IDs), Airing IDs (Turner IDs), and EIDR IDs, to
name a few. The segmentaMon descriptor is used with the Mme signal splice command, which
we will take a look at now.
---
Ad-ID: hQp://www.ad-id.org/
TMS/Gracenote IDs: hQp://www.gracenote.com/gracenote-id/
EIDR: hQps://eidr.org/

18. The Mme signal is preQy simple and provides a uniform method of associaMng a PTS Mme sample
with an arbitrary descriptor (or descriptors).

19. Now let’s take a look at how these individual messages work together. One thing that can get a
bit tricky or ugly when implemenMng the spec is that the same thing can be achieved mulMple
ways. For example, there are two ways to terminate an ad break that’s denoted by a splice
insert event (this is the first structure we looked at, the one used to denote local ads). The first
way to use this command only requires one message. The start event, or out point is sent, and
includes a duraMon along with an auto-return flag.

20. The auto return flag indicates that when the duraMon has passed to return to the network feed.

21. The second way is to use an out-point cue to denote the start of our ad break, which could
opMonally include a duraMon.

22. And then a second separate cue message to indicate the in point, or ad break end, that has an
event id corresponding to that of the out point.
SegmentaMon descriptor messages, the red ones we looked at that indicate events like program
and chapter segments, and naMonal and local ad breaks, are sent in pairs, and are conveyed
using the second approach here.

23. I also want to touch on segment hierarchy

24. I’ll use the first part of this episode of Shark Tank as an example, with the ad break lengths
exaggerated so you can see the concept more clearly. The highest level is the program, which
can include chapters and placement opportuniMes. These two ad breaks we see are denoted by
the provider and distributor placement opportuniMes, which are filled in with provider and
distributor adverMsements, which share the lowest logical level.
Events can be nested, as shown here, where in the first ad break, mulMple ad pods are shown
within the provider PO, and in at the second ad break here, where the distributor PO is nested
within the provider placement opportunity. If planned duraMons are sent with the placement
opportuniMes, this allows us to see how long the enMre placement opportunity is planned to be
as well as the duraMons of each individual adverMsement.

25. In order to give an advance warning of an upcoming splice, a command can be sent mulMple
Mmes before the splice point. For example, the same command could be sent 8, 5, 4, and 2
seconds prior to the event occurrence. However, it’s possible that an issued command may
need to be canceled.

26. The first way to cancel an issued event is to send a splice info secMon with the same event id
where the cancel indicator flag is set,

27. and then to send a new splice info secMon with the correct or updated parameters.

28. The second method

29. is to simply send a subsequent message with the new data without canceling the old message.

30. Now that we have decoded and understood the message, and how the pairings and hierarchy
work,

31. let’s take a look at how to convey the informaMon to the client.

32. In-band markers are typically included in M3U8 media playlist tags.

33. And here’s an example of the Apple-preferred method defined in the Pantos HLS spec, which
uses the EXT-X-DATERANGE tag, and includes the marker in the SCTE35-OUT aQribute or
SCTE35-IN aQribute for an in point.

34. This is the way that the SCTE 35 spec defines cue tags, using the EXT-X-SCTE35 tag with the cue
aQribute to contain the cue message.

35. Here’s an example playlist that illustrates a case with nested ad breaks; the out points mean
that the placement opportunity or ad break is starMng,

36. and each out point has a corresponding in point that indicates the ad break has concluded. You
can also expect to see in Point 1, at some point below aEer in Point 2, although it’s not shown
here.

37. Let’s also take a quick look at conveying cue messages using DASH.

38. SCTE 35 cues are carried in DASH manifests using Event elements in the Event Stream element.
The schemeIdUri can specify whether the message will be an XML representaMon, as shown
here, or as a base64 coded representaMon within the Signal Binary Element. It’s important to
note that In the case of an event cancelaMon, it’s necessary to add a new MPD event with a
cancelaMon flag, as opposed to deleMng the event for DASH consistency.

39. Now we have a completed picture of the process and the system will work great, in theory.
However, I’d also like to share some cases I’ve seen around inconsistent and irregular messages.

40. In working with mulMple vendors and providers, I’ve seen many different interpretaMons of the
SCTE 35 standard. I’ve seen local ads signaled in at least three different ways: by using a
distributor placement opportunity, by using distributor ads, and by using splice insert. A single
provider might send local ads using a combinaMon of these commands. The point here is to
make sure you implement all cases the spec states (and there are a lot) in order to not miss any
cue messages.

41. I’ve seen the splice insert command used for both local avails as well as for blackouts. It’s super
important to make sure these messages are correctly understood at a provider level. There may
be contractual or monetary consequences if a local ad break is starMng, but it’s instead
understood as a blackout and viewers can’t see any of the content.

42. I’ve also seen varying meanings of duraMon where some vendors interpret program duraMon as
the Mme between the beginning of the program and the first ad. Others interpret this same field
as the enMre duraMon of the program, and others don’t send duraMon.
I’ll also note that some providers send duraMon for ads, others don’t, which causes challenges
around having a consistent user experience if the ad duraMon details are used in the UI and
some of this informaMon is missing. This can also create challenges for implemenMng consistent
dynamic ad inserMon.

43. There are even plenty of cases where the specificaMon isn’t followed at all.
I’ve seen ad ids larger than spec’s max specified length; if the custom length isn’t known, it can be
incorrectly parsed or depending on the logic and resiliency, cause parsing errors that may result in
the message not reaching your client at all.
I’ll also menMon cases that require an ad break to be over when the planned duraMon is up, even if
the auto return flag isn’t set, as the spec mandates. If this assumpMon isn’t known, this can result an
indefinite ad state, and depending on the UI behavior, if rewind/fast forward is disabled for ads, can
compromise the user experience. If dynamic ad inserMon is implemented, this could potenMally
result in a stream of only ads for a long period of Mme.
Another case worth menMoning is when Event ids are reused to mean mulMple things at the same
Mme. If show with id 123 is ending the same Mme a new, different show that also happens to have
the same id starts, this can potenMally cause confusion like failure to end the first program with the
id 123. A similar case to this is when the ids used to idenMfy the program are wrong, occasionally
due to human manual data entry mistakes. It becomes difficult to match in-band with out-of-band
metadata used to display an up-to-date tv guide menu. This can result in the system not being aware
that a program or event has started, and users cannot access or watch the content. There are also
cases where providers use custom default values that are not the actual value; the parser or system
has to know which ones to use and which to ignore.
One more case that I want to menMon here pertains to usage in HLS. EXT-X-DATERANGE Mmestamps
on cue messages don’t always align across rendiMons in some implementaMons, and I recommend
taking this into account when designing the message ingesMon and flow through the service.
The boQom line here is that I recommend resilient parsing, and thoroughly tesMng and monitoring
each channel before the it is available to users.

44. Many of the inconsistencies I just menMoned are unable to be changed or fixed at the provider
or vendor level. Depending on equipment used by the provider, they may be unable to send
certain types of markers or commands, and in this case, this is usually limited to local avails, so
there is no in-band program visibility, and you must rely on out-of-band program scheduling.
Also, in-band delivery restricMons are only used by some providers, meaning the complete
system may need to contain a lot of channel- or provider-specific logic.

45. In order to prevent poor user experiences like freezing transport controls in the middle of a
program, showing the incorrect currently airing program for a channel in the channel menu,
blacking out programs that should be available to users, and so on, due to inaccurate or
unreliable messages, it’s important to be able to idenMfy marker inconsistencies. If you have a
live streaming service, you are the face to the customers, who probably won’t care whether it
was a vendor or provider error, but only care about the final user experience.
We can take steps toward achieving this accurate and consistent experience by having
conMnuous tesMng and alerMng in place. For example, if markers aren’t sent for a few hours, this
can be alerted for human invesMgaMon. I’ve seen cases where markers are consistent and
accurate when a channel is onboarded, but later stops sending markers all together. Another
approach is to compare the out-of-band data with what SCTE 35 messages are actually
received. A second strategy is to incorporate intelligent content type detecMon (which
determines whether it’s likely that this video segment is an ad or program) and verify that the
markers are consistent with this finding.
And lastly, it may be helpful to determine what reasonable ad break Mmes and duraMons are
expected based on data analysis. To miMgate irregulariMes, we can create automaMc Mmeouts to
end the ad if it seems that the ad break is unexpectedly long. Another valuable miMgaMon
strategy is to create tools that make it easy for humans to manually correct the state of a
channel, whether it be ending an ad break or extending a program that is going overMme.

46. I’ve included some spec references here.

47. And that’s it. Thanks for reading along!