The video world is changing. Today’s viewers demand highly personalized content, and to address content regionalization requirements, operators need more control over video distribution.
The SCTE 224 standard was created to help content providers and operators better deliver and monetize video content.
While content owners and distributors have been working together for decades, the need to better monetize live event rights for instance and therefore to better control how they are distributed over streaming became acute during recent years. Proprietary or ad hoc protocols were often used, resulting into very fragmented types of interfacing and implementations which were hard to maintain. Over time, relying upon a modern and standard API to carry rich metadata made its way through. In today’s world of very dynamic distribution policies, large scale lineups and extensive definitions, using manually configured rules is definitely not an option anymore.
This blog sheds light on how the SCTE 224 standard came to life and what benefits it brings to the combined ecosystem, based on discussions with key contributors of the standards, including:
- Paul Woidke, Chairman of SCTE’s DVS Working Group 5
- Stuart Kurkowski, PhD Distinguished Engineer, Comcast Technology Solutions
- Other engineering leads working for various large operators (e.g. Charter)
The Origins of SCTE 224
Fundamentally, SCTE 224 is an ESNI (Event Scheduling Network Interface) specification. It is an API that was developed by CableLabs several years ago.
While SCTE 224 started as an operator-driven initiative, it quickly became obvious that content providers could also benefit from this standard. Indeed, if there is one fundamental idea that deserves to be outlined upfront, it’s the need to control content distribution. This requirement emerged as a direct consequence of a more business-oriented need. To best license and monetize live sports events, professional sports leagues and sports networks understood that it was in their best interest to control how events would be distributed through MVPDs.
Specification Evolution
The SCTE 224 specification itself was originally developed back in the 2010s . Within the CableLabs organization, the first agreements followed soon after. The approach that initially emerged from the first discussions was pretty much a binary switch. The primary goal was simply to find a way to block the audiences identified as such.
Several refinements were then added through multiple iterations on the initial draft. This work then moved into a long-range research endeavor. Focused work and collaboration led to a solid draft.
Getting the Standard Rolling
CableLabs took the ESNI and ESAM combination of standards and made significant efforts to maintain this work. As the ESNI draft specification was brought into the standardization process during a five-to-six year period, subsequent versions generated, growing interest from content providers. They could foresee a way to enforce when, where and to whom their content would be distributed. Conversely, it meant that any distributor not enforcing the rules and policies specified in the distribution agreement would be in a breach of contract. This point effectively meant that providers streaming live sports events without enforcing the mandated event specific viewing policies could be sued by sports leagues and content rights holders. They had to adhere to their contractual obligations.
The other major improvement that came out of the SCTE 224 initiative is that signaling was no longer required to be in-band only. From this standpoint, enabling out-of-band delivery of metadata was a breakthrough. One of the challenges the working group identified early is that if all signaling had to be kept in-band, there was no way to come back to the original content linear feed.
Opening Up New Opportunities
Over time, additional links and schemas were added to SCTE 224 to enable programming control, chapterization, subsidiary schemas, and multiple other functionalities. Yet, SCTE 35 was kept intentionally, as it dovetailed very well with SCTE 224.
The strongest benefit of this combination is that it enables channel switching accuracy (for instance, with frame level cue points and stream conditioning), while allowing out-band delivery of complex and dynamic viewing policies ahead of time.
What is the Future?
While the SCTE 224 standard focused on blackouts at first, remarkably the ESNI SCTE 224 standard enables multiple other use cases such as EAS (Emergency Alert Services), personalized EPG and customization of ad breaks for targeted ad workflows. The challenge now is to make sure they are actionable and deployed massively in production.
With hindsight, Broadpeak expertise in SCTE 224 implementations is a now a true asset for any content provider or operator willing to ensure a safe and reliable path forward for any of those use cases.
Broadpeak actually used SCTE 224 to build its new broadpeak.io video API platform. To learn more about how you can customize the streaming experience, get in touch with us today!
Photo by Hadija Saidi on Unsplash
