Olivier Karra, SaaS Solutions Director at Broadpeak, made the presentation “How To Manage Blackout When Distributing Premium Live Sport Channels Over IP” during the CMIP presentation at NAB Show 2022 (day 3)
Here you have the abstract of the presentation:
Whether you are a distributor, a vMVPD or D2C app, you may want to add premium live sport channels in your IP line-up. And this comes with blackout requirements. Performing blackout in IP is not as simple as in broadcast owing to the centralisation of the OTT head-ends. During this presentation, attendees will see how broadpeak.io can help users easily comply with the requests of programmers whilst maximising user satisfaction. The use case of peakVU.TV, the solution selected by many mid-size American ISPs to power their video IP services, will also be reviewed.
Watch Olivier’s talk here:
Or read its transcription here:
Introduction
Hello everyone, and thank you for coming over. Just a bit of introduction. I’m with Broadpeak. My name is Olivier Karra. I’m Marketing Director for SaaS Solutions. What we’re going to talk about in this session is how to manage blackout for the distribution of live sports content over streaming.
Agenda
For the agenda today, we’ll start with a brief introduction of what blackout is, just as a reminder, and then I will go a bit into the conditions and the requirements associated with this use case. Then we’ll go into the implementation itself, and last but not least, I will share our experience on a real deployment, which is the one of the peakVU.TV streaming platform.
Blackout
Just a brief history for those of you are not so familiar with blackout. Blackout is actually quite old. It got introduced back in the sixties, and what it is, basically it is meant to make sure that the live sports games are not viewable on the TV services when there is no rights associated with this kind of event. That’s really the core requirement associated with that kind of use case.
There is actually a second thing associated with blackout. It’s also intended to make sure that sports fans can buy tickets to go to stadiums, rather than watch those games on their TV. Why? Simply because it regenerates more revenue for the content rights holders. At the end of the day, for the distributors, it’s the same. They need to make sure that they comply with the rights of the content providers. That’s the ultimate requirement they need to comply with.
So if we look at blackout from a 10,000 foot view, and we look at the linear channel, what we’re going to have here is, typically we’re going to have regular programming, and then from time to time, we’re going to have live sports events, which are going to have restricted programming, which means that only specific audiences are allowed to view that event. And this is typically done with a set of policies. So for a given live sports game, you’re going to have a set of viewing policies that are going to describe who can watch the event or the content it should be replaced with if it is blacked out.
Conditions and requirements
Let’s move forward into the implementation, let’s have a look at what it means exactly. First of all, most blackout events are known in advance. That’s a pretty good news. It means that the schedules is known, sometimes days ahead, sometimes weeks ahead. And in fact, the time of switchover is also known in advance, pretty accurately. So that’s a good starting point. The challenge is that some of those events need to be delayed, for instance for bad weather conditions, or they need to be extended just because of overtime. This is very typical in a number of sports games, and this is where it requires manual intervention.
The other specific use case that can come up here is that the replacement content needs to be different from one region to another. This is a bit more advanced than just having the same replacement content for all the regions, and this is, again, one requirement that typically comes with the blackout use case.
All right, if we look at the expectations or what’s going to happen on the end user, you and me, of course the default expectation is that there is nothing to do. This should be completely automated, nothing to do in the manual way. And the other thing is that it needs to be done on the program level. As you’ve seen, not on the player level, not on the player time. From a functionality standpoint, it needs to be automated. When the switching occurs, it needs to be as smooth as possible. And as we’ve seen, we still need to have manual override, because there are several situations where it needs to be delayed or extended.
The big challenge in this kind of use case is around metadata. The distributors, whether they are aggregators or MVPDs who are getting those metadata, do not always get them in the right format. And in fact, if you talk to some of the programmers, you will see that they have different formats for their metadata. So that’s one of the biggest challenge. And this is exactly why we have that kind of standard in API coming up. This is normalizing the interfaces that we have between content providers, or metadata providers, and the platform that we’re using here.
Implementation over IP
Let’s move a little bit further into the implementation. If we look into the streaming itself, we see that we need a mechanism to implement it for DASH and HLS packaging protocols, of course. It’s true that you can do in the old way, and there are deployments in the industry where this is being done at the source level. The only challenge is that this is not scalable. At some point in time, you will reach some limits, and you will have too many constraints. So this is why it means that the manifest manipulation is fully aligned with this use case. This is what makes most sense in terms of use case management at this stage.
Now, what you’d need also is all the logic to make this kind of switching as automatic as possible. These events can be changed. The metadata associated with them are very dynamic, and everything needs to be automated. You need to move away from the manual management. Doing the manifest manipulation on the back end is of course one of the need, but is not enough. On the other side, on the end user side, you also need end user location, for instance. So it could be a ZIP code, it could be a DMA.
This is the other component which is needed to make the decision. And at the end of the day, what we’re talking about here is an API, which can automate those decisions based upon the schedule, and this needs to be done on the fly. That’s really the key points that are related to the implementation of blackout for streaming in general.
Okay, so if we look at the big picture, this is a very simplified overview of how the ecosystem looks like. Let’s say you have a content provider providing a linear channel to a distributor. This could be an MVPD, could be an aggregator. The API SaaS platform that we’re talking about here, the Broadpeak.io, sits in between. As you can see, we can get metadata directly from the content providers if they are in the right format. If not, we can work with partners that are going to normalize and adapt those metadata so that they can be leveraged.
This is on the backend side. On the end user side, we’re also getting the request from the end users with the information about the location. Again, this is really the key information that we need to make sure that we can make the decision. And once we have those two sets of information, we can make the call, we can make the decision, and this is how we can personalize the content. Let’s say if there is a live sports game for an audience that does not have the rights to view the event, this is how we can switch to a different content. Maybe we can look at another way of this ecosystem.
This is the video delivery plane, if you will. You see here that we’re getting manifests from the original content and from the replacement content. So these are inputs to the platform. As I said before, there are two other sets of components or metadata that we need. The rules to decide what can be done, what needs to be done.
So for instance, the audience, who needs to be switched, the timing, and of course the action. What content is going to be replaced for this specific time slot and for this specific audience? And likewise, we’re getting the end user location, for instance a ZIP code, but it could be any other parameter. It could be a mobile type device. It could be a DMA, it could be any kind of category. And this is how we can switch between the original content and the replacement content on a per audience basis.
peakVU.TV example
Before we move forward, just wanted to give you another example, and this is really a real life implementation. Here we’re talking about a managed service platform, the peakVU.TV platform, which is providing a streaming service, which coming with content. There are more than 350 channels of content for linear, for Catch up, for PauseTV and nPVR. What you see here is all the content providers, which are sending the metadata associated with the content. And in this metadata, we’re going to see, for each channel, what live sports game is going to be blacked out, and if such is the case, what content it’s going to be replaced with.
In this example, we’re working with a partner, Vubiquity, which is doing this aggregation and this normalization to send us all the SCTE224 metadata. And on the client side, the app is sending us all the end user location. This is, again, how we can make the decisioning in a automated way for every end user and for every channel at all times. This platform in the middle is automating all these decisions and providing all the logs, all the analytics associated with those switches.
That’s another point I wanted to mention, is that those content providers are also expecting the distributors to make sure that they comply with their distribution rules. This is exactly how we can provide those analytics, is because we have the information on both ends, on the back end and on the client side. We can know what has happened for every single channel, every end user, at all times.
This is the peakVU.TV example. Maybe one more information about the peakVU.TV platform. It’s about the way we worked to do the integration with the peakVU.TV platform. In fact, we had a CI-CD approach, really, to speed up the integration. What you see here is a typical phasing of how the Broadpeak.io SaaS got plugged on top of the peakVU.TV platform from the onboarding till the final validation and the deployment.
The key benefits here of working with the SaaS platform is the fact that you can fast track your testing from the very early days till the deployment. So all these stages, instead of taking months, actually took days or in the worst case weeks, because it’s all managed as a service without having you to deploy any infrastructure, any software layer. It’s a blackout as a service effectively, that is being provided by the platform.
So main messaging here is that this SaaS platform is providing a blackout as a service application in this case, and it’s API based, which means that all the metadata, all the schedules, all the slots that needs to be created can be done in a automated way through the API, without any manual intervention. Even in the case where there need to be changes to the schedules, that can be done through the API, just like if it was a simple event.
Before I end up with this presentation, I just wanted to share a few numbers on what has been deployed on this platform. Here you can see that we, for instance, have deployed eight sources, 14 alternates, multiple variants per channels, and more than a couple of slots per week and per source. So it shows you that it’s pretty dynamic, and this is a starting point before you can scale up the platform.
Conclusion
All right. Maybe my conclusion at this stage to finish with this presentation is that if you want to see the platform in action, come over to our booth. We have nice demos running that we can show you. If you want to create an account, feel free to sign up. There is a free trial that you can test for 30 days, and once you log into the app, you can even create your own demo, and you can also do the test with your own content. I think this is really… Within minutes or hours, you can see how the blackout service is working for your environment, your ecosystem, and your services.
Thank you!
Photo by Stuart Bloodworth on Unsplash
