Mathias Guille, Head of Cloud Platform at Broadpeak, made the presentation “How we used SCTE224 to build our API video platform” on the Video Tech New York City Meet Up on the 2nd February 2022.
In his presentation, Mathias shared about Broadpeak’s journey to create broadpeak.io, the API video platform that we launched on the 18th January 2022, and explained how we use the SCTE-224 to build our API.
Here are the topics discussed:
- Broadpeak and broadpeak.io’s introduction.
- Broadpeak’s journey to create broadpeak.io: from its conception to its implementation.
- SCTE-224, concept, use, and deployment in broadpeak.io’s API.
- broadpeak.io: use cases.
- broadpeak.io: next steps.
Watch Mathias talk here:
Or read its transcription here:
Introduction
Broadpeak, concisely, is a French company founded in 2010. We develop software for what I call the video streaming data plane. We do not do any transcoding, but we do origination/packaging/encryption and distribution (CDN).
We are quite famous for the different projects we do with service providers such as cable operators, telcos, and mobile operators. Our business is really related to anyone owning their own network & with their own infrastructure where we deploy our technology.
For example, we do Origin Packager and if you are looking to deploy your Cloud PVR service, we can help you with that. If you have your own network and you want to deploy your own CDN we can help you with that as well.
We typically complement that with a technology called multicast ABR which is helping to use multicast for HLS and DASH.
Then beginning of last year, I got the mission to find a way to mainstream our technology. Since we started, we were developing a lot of advanced streaming technologies and most of them for Tier 1 Pay-TV operators and their extraordinarily complex workflows. And we realized last year in the middle of Covid [pandemic] that a lot of changes happened in the web, in particular: few years back, we were saying “the software was eating the world” and last year we realized that it was the “video which is eating the world”.
Most of the traffic you can see on the web right now is video. And the video is not anymore about ESPN and Spectrum or Comcast only. Everyone needs to be its own media; everyone needs to have a somehow a video strategy.
The problem we have is that most of these people on the web do not have the infrastructure, they do not have the network, but they still look to have sophisticated video solutions because the video is quite complex, and you want to distribute it very well.
So, in January 2021, we created a team called Cloud Platform and we started developing our first API video platform called broadpeak.io. It has been out for two weeks now, so it is new. I encourage every one of you to look!
broadpeak.io
It has been designed over four pillars.
- First thing we were looking to build was not only a basic online service but really a platform with an API. The idea behind it was to embrace the current movement in the video industry which empowers DevOps. From my perspective, DevOps love to build on top of API platforms because it is giving them a lot of agility, the capacity to test quickly without going through a sales process.
- Then the idea also was to provide a good service but not like a typical SaaS: something self-serve with auto-scaling with instant access but keeping the same care that we have right now with our big customers with 24/7 support including local people.
- The third pillar was to propose advanced streaming workflows. There are a lot of existing video platforms already and the idea is not really to compete with them. For example, we do not really want to provide transcoding there are a lot of smart companies doing it already – we do not really want to compete on that. What we really go with is an advanced technology for advanced streaming workflow.
- Finally, the idea is to do to provide applications little by little, one by one, so our customers can build with us, start a first project then evolve as soon as we add more features.
Building an API
Our focus
Let us finish with the boring part and let us dig into what we have done to build that API.
The first focus was to build something frictionless, we put a lot of effort into the UX/UI. We created a web app to onboard our customers, and quickly test the technology / do some demos.
We knew it was not sufficient, so the second step was also to provide an API to help scale the project. We got influenced there by companies like Stripe and Shopify and tried to replicate the same on our scale.
After it, was important to provide a Knowledge Center because it is a self-serve platform and the idea was to let the customers run themselves the technology, troubleshoot it also by themselves.
Between the API and the Knowledge Center, we have a strong correlation. Every time we change something on the API, you can automatically test the change on the Knowledge Center.
Again, let us have in mind that we start with a first application which is around content replacement. I will come back to that. Now if tomorrow, we have one more application, everything will follow: the web app, the API, and the Knowledge Center.
Our choice
We have some decisions to make when we were thinking about the APIs.
What did we want to achieve? Creating an API sounds obvious, but we wanted to make the API part of our product development process. The complexity was about proposing advanced technology but keeping the API simple and having the right level of abstraction.
Now you have diverse ways to do it:
- The first way, you can say – “I’m going to build my own API, I’m going to be fully proprietary, and people are going to develop on top of it.” Well, that is an approach, and it gives you a lot of flexibility, but the problem is that it makes your customers super sticky with you. We do not believe it is a good thing.
- The idea was to be less sticky and see if there are some standards that we can reuse to be part of our API.
The second point was also making sure that we were versatile enough to address all our existing needs and the future ones.
Finally, the API must be global and not only focused on one region. Broadpeak is a global company and address different regions.
So, we produced a shopping list to build that API and we realized that we were looking to have an API around video able to help us to create, read, update, and delete (CRUD) any kind of video service. When I talk about video services, it can be a linear channel or on-demand content.
It must be able to manage an audience as our strategy is to help our customers to do the differentiation between the viewers in a specific location or using a specific device/codec.
You should be able to enforce rules and policies based on the content/audience.
The last part is close native integration with inbound metadata like SCTE35.
Our implementation
What is important is with broadpeak.io, we are looking to target DevOps and make the experience enjoyable for them.
We made things interactive meaning you can go to the Knowledge Center and test within seconds with an API key. We have dynamic code snippets so based on what languages you like you can test easily.
We put a lot of effort into the API definition to give good API logs.
In our development process, we use Swagger (also named OpenAPI 3.0), and we develop the API as part of our process. We push a JSON file to a tool called Readme.io which is the framework we use for our Knowledge Center.
Everything is automated, so every time we do a new update of the API, we automatically create an updated version in developers.broadpeak.io and our customers can follow the different versions of the API.
SCTE224 ESNI Concepts
SCTE
I will not go too much into details, but it is good to remind everyone what is SCTE. It is a society for experts in cable operators. It has been there since cable exists, and it is relevant in streaming because the video we use in streaming is also coming from cable broadcast.
SCTE is doing certification and standardization of course and there is also a show that they organized every year which helps to discover innovation around video and cable.
The good thing about SCTE is that it is not only American-centric, but they also have good collaboration and cooperation with international organizations.
SCTE35 is a good example of a concept popularized worldwide.
SCTE224 Key Concepts
So, what is the concept of SCTE224? The standard is fully XML based and it has been named also ESNI (Event Scheduling and Notification Interface).
Originally the main concept was to help Pay-TV operators to move to OTT. They were using broadcast cable or multicast transport stream and of course, now they are looking also to target more screens.
So, they must move to IP and adaptive bitrate streaming (HLS or DASH).
SCTE224 is a description of a schedule for a service such as a linear channel – and it can give a lot of information: timing information, metadata for cases like blackout, with alternative content, the description of the audience (I will come back to it) and the viewing policies.
What is interesting with the standard itself is that you can use different layers. You have a rule by default that you apply to any kind of media and then after that, on the fly or scheduled in advance, you can apply specific policies or specific rules.
The fact is that real-time helps to build the API.
On top of the scheduling part, it helps also for new use cases such as targeted advertisement, I will come back to this too.
If you think about SCTE224 from a data model standpoint, you can illustrate it with different definitions which are the base of the API.
First: the “media” can be any kind of video content. The “mediapoint” is a subpart of that media. It can be a program in a linear channel for instance.
Then you have the “policy.” The policy is something you can apply to a specific media point. A subtract of that is a viewing policy that relates to an audience. The audience can be people in a specific region or people with a specific device.
After that, you have “action” that you want to apply to an “audience.” A combination of an “audience” and an “action” is a “viewing policy.”
Finally, you have the concept of “audit” which is analytics to the people who want to enforce the policies.
You can see that the “mediapoint” is interesting because it gives you a timeline right off the bat with a start time and an end time. And this can be fully out of the band! It can also be correlated with SCTE35. That is one of the strengths of SCTE224, you have a clever way to complement information coming from inside the video itself via SCTE35. It helps because also it can be frame-accurate and of course, SCTE224 does not give you that possibility.
SCTE224 data model
To represent the data model in a more graphical way, I created for you a media from New York very French-influenced. It is a linear channel with regular programming where you watch live “Emily in Paris,” and you fantasize about living in Paris now. After that you have a Knicks game coming up, but the problem is that by living in New York City, you may not know that, but blackout rules need to be applied in the US. It has been invented a long time ago for the Indy 500 and the idea is that if you are living in New York – they will blackout the Knicks on TV because they want you to pay for the tickets and go directly to the arena.
So that’s where SCTE224 can help you by having a mediapoint inside the media. So, when the next game starts, you know that you can apply a policy. In that case for everyone in New York, they are going to be blackout and we are going to replace the game with something else, which can be another linear channel, a slate, or a video-on-demand.
You apply that policy and after that mediapoint you come back to the original programming. Again, it is very French influenced. You can now watch “Arsene Lupin,” it looks great, and you pass an incredibly fun time so that is the kind of SCTE224 data model applied to a specific use case.
SCTE224 creates the design for the media itself and a start time, an end time, and the concepts of policy and audience.
Policy=Action+Audience
Again, the policy is action plus an audience, right? You will see that in SCTE224, there are several different criteria to use there, and it is interesting for us because it opened a lot of doors to what we want to propose to our customers.
So, the blackout is the use case I just explained, I will come back to it in a little bit. It is one, but the sky is the limit you can imagine many different policies you want to apply based on what your programmers want to put in place.
For us, it was great in terms of looking at the next steps. We started broadpeak.io with content replacement applications and in the future, we want to do even better and propose more advanced streaming workflows.
Why SCTE224 was a good fit
SCTE224 is a rich standard with an extensive list of capabilities where you can define action and audience. It does not need to be super comprehensive: it is going straight to the point but also can do a lot and solves several of our pain points.
It is a standard so, of course, it avoids the Broadpeak stickiness.
It is adopted in the US, SCTE224 is used by example by Fubo or Hulu. Most of the programmers are using it as well: ESPN, Sinclair… You will find people in the industry who understand SCTE224.
It is simple enough to provide a good base for our API: keep in mind that we were looking for simplicity – at the end of the day it is like an API like any of any other one. SCTE224 is now a subset of our API, and we are super happy with it because again, customers like to work with standards.
There are still some challenges with SCTE224.
One of the problems is when you work in IP and streaming in ABR. You know that you need to deal with a lot of variants: HLS, DASH, several ways to encrypt, different versions of HLS, and so on. SCTE224 has no awareness at all. For example, for ESPN, which is fine you know that it is a media, but you do not know if it is ESPN HLS v4 or if it is DASH with numbering manifest. There are no concepts around that, so you must build it by yourself.
Some other concepts are limited, for example, in terms of security, it is missing protection around impersonation or man in the middle.
There is a little bit of competition if you look at SCTE224 and the use case of blackout coming from other formats like IO2, but we have a team called customer success which can be instrumental to also build connectors and help the market and our customers to implement SCTE224.
Applications and Use Case
Our concept: the contextualization engine
Our concept is the contextualization engine where we can get a source from our customers, and they tell us what to do with that source.
They configure a policy to apply to a special audience at a special time. They give us replacement content which can be another linear channel, a slate, or a video on demand.
Our system is doing all the manifest manipulations and it is going to deliver the manifest for every end-user. When we receive a streaming request, we look at the source, at the context and we do the manipulation as expected. Then we send that manifest to the customer. We do not deal with the video itself; we just really focus on the manifest manipulation.
One use case: Blackout
The idea is to work with distributors which got contracts with programmers. For example, you can be a vMVPD, you need to distribute ESPN and must apply blackout. What we do is we get the manifest from the distributors after they do the packaging and encryption. Then we get you to know out of the band the different slots for the blackout using a SCTE224 API call. And we manipulate the manifest to apply the blackout, so when the viewers are streaming ESPN on that distributor platform – they get to us, we do the manipulation, we give back the manifest and after the end-user can get the video fragments coming from the distributor itself.
Other use cases
So now if you think about it, our contextualization engine helps with other use cases too. The fact we use SCTE224 models different criteria on the audience, different criteria for the actions.
So, we have some use cases for regionalization, meaning that you have one linear channel at first national and that you want to regionalize. We have customers, they have this use case for election day.
On election day you can watch CNN to get the national results, but you want to know also who has been elected locally. Some parts of the program can be regionalized on CNN to have the local results too.
We have customers using our API for doing distribution management, some of our customers propose pay-per-view events and want to authorize or de-authorize some of the viewers based on what they paid.
Another one is alerting system. In the US, we have what we call EAS. When you have a tornado around, and you watch something on cable, you are supposed to have a message stopping the feed and telling you like “there’s a tornado – go to your basement.” This is not enforced yet for OTT video services, but it will at some point, the FCC is working on it, and we can help on that too for HLS and DASH.
Finally, there is also another use case coming up right now because SCTE224 helps with scheduling. We can help people doing virtual linear channels. For example, everyone talks about FAST channels, we can address it and we add advertisements to them.
Next Steps
Beyond Content Replacement
To finish, I want also to open a little bit of the debate and talk about what is next and what is beyond content replacement for us.
The good thing with SCTE224 is that it helps with scheduling but what is interesting as well is the metadata that we can use from inside the schedule.
We are looking at it in the future: we want also to move some other parts of the Broadpeak product line into broadpeak.io. One other thing we do is recording for Catch-Up and CloudPVR – with the metadata we have in SCTE224, we can get some information of what can be recorded or what cannot. We can tell too if PauseTV is available or not and that brings a lot of value in the relationship we have with the players to tell them what to do on some specific programs.
For example, we can also help with ad-skipping – some ads can be skipped, some ads cannot and as we manage the audience there’s a lot of things that we can get in terms of statistics and give feedback to some programmers telling them: “oh, by the way, when you were doing your blackout, you used that content for the replacement, it didn’t go very well with your audience”.
You can also imagine doing some personalized EPG: one EPG per user.
Finally, because the next application that we will propose in the platform will be around targeted ads, we can replace the ads in collaboration with SCTE35 for targeted Ads or Regionalization (the insertion of regional ads on national content).
Thank you!
Photo by Scott Blake on Unsplash
