The Most Common Misconceptions About MABR

Multicast ABR (MABR) is one of the hot topics of the moment, and it is logically generating quite a few comments online and in publications across the industry. Now, the technology is at an early stage in terms of large-scale deployments, so a few of these comments are still based on very theoretical grounds. While they can sometimes seem relevant at first sight, they are contradicted today by the actual feedback from real-life implementations, turning out to be inexact or even misleading. Below we’ll present a summary of some of the most frequent misconceptions about MABR.

• It’s complex to integrate an MABR agent on a gateway.

With a bit of experience, integrating an MABR agent is technically quite simple, actually. It’s not even properly an integration, as this agent is pretty much autonomous from the other processes of the CPE, and no API calls need to be implemented on either side. The experience shows that what takes the most time, in general, is convincing CPE vendors that are not used to having third-party components to incorporate this agent and treat it as any other process of their firmware, with the same level of status reporting, logging, or other lifecycle requirements usually expected in production environments. A good illustration of this is that, for the particular use case where the agent is to be installed on an Android set-top box, which is by design an open system meant to receive third-party applications, it only takes a matter of minutes to set up. The process actually looks like installing an everyday app on one’s smartphone.

One other important aspect is that MABR is mostly implemented to replace traditional IPTV and broadcast. So incorporating an MABR agent saves a huge amount of time and energy by not having to implement a full MPEG stack in the STB.

Finally, looking forward, having a component dedicated to video directly embedded in the home of each user is not necessarily a burden but rather a very interesting added value for a CPE. The proportion of video in internet traffic is poised to increase even further in the future, and QoE is particularly important for this application. Therefore, optimizations will have to develop even more, and taking these optimizations down to the home level is particularly relevant, maybe even necessary at some point.

• MABR would only make sense for live content on a TV screen, but it supposedly fails there as it cannot match the latency standards that traditional broadcast can offer.

This argument assumes three things :

1. MABR is mainly applicable to live content and, even if it is sometimes used for catch-up or VOD, it’s fair to say that it’s by far its main usage, at least today.
2. Optimizations, such as what multicast offers, are not really necessary on mobile devices, as these devices are already fed by standard ABR (adaptive bit rate over public internet, also known as OTT) without anyone seeing a real issue. This implies then that MABR would only be useful on a TV screen, where the constraints on scalability and QoE are typically much higher, providing it would help get rid of traditional broadcast (MPEG-TS based).
3. ABR in general, with or without multicast, would unnecessarily add a lot of latency in comparison to broadcast. Therefore, it would never be suited to replace this traditional technology for live events on a big screen.

So, if not needed for mobile devices and not suited for the big screen, what would MABR be useful for?

The third assumption regarding latency might have been accurate a few years back but, unless old or poorly implemented, it’s no longer the case for MABR. On the contrary, the use of multicast is actually a great tool to help with that matter. The main reason for ABR’s extra latency is that the content delivery is expected to be variable, since it’s normally available via public internet, and that the player consequently implements a large buffer to compensate for these variations. The more buffer, the more latency. Creating the network conditions to secure a steady delivery is the one mandatory condition for safely being able to reduce this buffer size, and that’s exactly what MABR does for all parts of the network and at all times (even for peak hours). With the combination of MABR

and CMAF chunking, it has been demonstrated that it’s possible to cancel all delivery latency and do just as good as broadcast. This innovation was recognized with a BAM Award in 2019. The latency issue being lifted, MABR becomes perfectly suited for big screens and a great alternative to move away from legacy broadcast technologies, which pretty much haven’t evolved for years.

The second assumption is also getting more and more arguable as set-top boxes have started losing their exclusivity on the big screen and more people progressively watch TV through Apple TV, Amazon Fire, Chromecast, or other popular streaming devices. Even operators themselves have started proposing packages that include these devices as an alternative to their basic set-top boxes. These devices cannot be considered mobile devices, in the sense that they can consume quite a lot of resources and require a big-screen level of quality. Now, these devices naturally only support ABR, not legacy broadcast standards. Optimizations in that case, unless with exceptional network conditions, are nearly mandatory.

• MABR wouldn’t save that much bit rate on the network.

In order to assess MABR, it is essential to be clear on what technology it is being compared to. More specifically, is it imagined as an alternative to traditional broadcast or is it seen as a way to optimize network resources on existing ABR delivery?

Experience shows that the main reason for operators to deploy MABR today is the former. There, the main goal is not to save bandwidth but to create the opportunity to run one technology rather than a complex and costly mix of ABR and legacy MPEG, allowing one single head-end, one distribution, and one converged type of devices.

And, even in the second case, bandwidth saving is not the first objective either. Rather, it turns out that implementing MABR is principally meant to increase QoE — that is to provide “broadcast quality” (in terms of resilience against rebuffering, latency, etc.) to the ABR delivery — making it suitable even to the main screen. That said, on top of improving QoE, MABR does actually save bandwidth on the network. In some cases, the savings might not be substantial on the last mile, for example in the case of DSL where DSALM/client connections are one to one anyway. This is, however, very different in a GPON or QAM context and, more than anything, the savings are to be seen on the core network. At the output of a PoP, no matter how the question is turned around, there will always be one connection per user in unicast ABR versus one connection per program in MABR. Unless the network has an extremely low number of concurrent users, the load on the network will always be dramatically less with MABR. And not only does it reduce the network bit rate, but another great benefit is that it also makes it predictable, while unicast, depending on the number of users, can provoke very high peaks of traffic. Amplitudes are nearly impossible to anticipate precisely, leading to a certain risk in terms of operations.

• Nonlinear usage (catch-up, pause, etc.) is not covered by MABR.

As already mentioned, MABR’s main use case is generally the opportunity to replace broadcast technology with a more unified and future-proof ABR solution, while preserving “broadcast quality” thanks to multicast distribution. Broadcast content is exclusively linear. Keeping nonlinear distribution in unicast ABR, considering the lower constraints in terms of scalability and latency, is not as much of a critical issue as with linear or live content. On this point, it is important to note that a network is dimensioned by peaks not by average traffic, and the highest peaks generally come from popular live events, not from nonlinear content. Even SVOD, as successful as it is, does not reach the same kind of concurrency levels. MABR’s role is not to eliminate all unicast but more simply to remove these peaks and, by doing so, it typically divides the required maximum network capacity by three to five times compared with ABR distribution, which is unicast only.

Now, in the rare case where nonlinear content provokes a peak of traffic at the level of most popular live events (e.g., a very popular series episode available at the same time for all users), a good way to optimize its distribution is to provision it in advance deeper in the network. You can do it either in the CDN POPs or even directly in the home CPEs, providing they have some storage available for that. The deeper these destination points are in the network and the more numerous they are, the more it is interesting to perform pre-caching via multicast. This is also quite a popular application in MABR deployments today, for example, for satellite contribution to remote network PoPs, for contribution to local TV stations, and for professional services to public places such as hotels and campuses.

• Are targeted ads compatible with MABR?

MABR is not meant to replace ABR unicast distribution in its totality but to seamlessly complement it whenever it is relevant. While, generally, the main use case for MABR relies on QoE considerations, as previously described, it is true that MABR is also expected to limit the load of high concurrency content on the network. In reality, multicast and unicast work together. A certain proportion of unicast is perfectly acceptable, and even desirable to allow personalization, as long as the multicast does its job of removing the steep peaks of traffic that a unicast-only distribution would generate by unnecessarily replicating high-concurrency content for each user.

The doubts on compatibility between MABR and targeted ads are based on the fact that, during ad breaks, having targeted ads would cause all the users to request personalization. In this case, they would switch to unicast at the same time, meaning that the system would require full unicast capacity (the same capacity as if the distribution were unicast only, with no MABR capacity). This is already a bit of a shortcut, as reaching full unicast capacity would imply that all channels of the lineup get into an ad break at the same exact moment and that this time happens to correspond to a peak of audience. But even imagining this situation, one common misconception with targeted ads is that the system will distribute as many physical ads as there are users. This is naturally not the case, as the number of ads available for a given break is limited and, similar to other types of content, there will be ads that are more widely distributed than others, with a higher concurrency. These in particular will benefit from MABR. The others can continue being distributed in unicast without impacting the system dimensioning. Note that seamless ad insertion in MABR is quite similar to

seamlessly switching from one video layer to another and doesn’t constitute a huge technical challenge. Actually, it is by some aspect easier, as ad insertion is a live-to-file transition and, unlike live-to-live transitions, a file can be preloaded slightly before it is actually used, which facilitates the synchronization. This implementation is a reality today, and it has been recognized with a best AdTech award by CSI magazine this year.

So, MABR does make sense for ad distribution as an optimization of pure ABR, but it is even more relevant when we consider MABR as an alternative to legacy MPEG for live. This comparison is actually more accurate in the sense that announcers are naturally more interested in implementing ad targeting on TV sets rather than on mobile devices — this is where it matters most economically — and most TVs are still connected to MPEG-based set-top boxes and largely consuming linear live channels. In the usual hybrid STB model, live is MPEG while ads are distributed in ABR. Not only is this mixture much more complicated to manage but no ad optimization is possible, and the argument in that case is totally valid, switching to an ad break does indeed create unicast traffic spikes.

• Third-party OTT (Netflix, Disney, etc.) is not supported by MABR.

MABR requires multicast capacity, and this can only be granted by the owner of the network. It is true that pure OTT players cannot access this technology without having a specific deal with the network service provider connecting its users. This is, however, also true for any delivery optimization. Netflix, for example, has improved its QoE by installing dedicated caches embedded in ISP networks but, of course, this could never have happened without the agreement of the ISP. Even peer-to-peer strategies typically rely on some CDN adaptations, as peers are generally assisted by servers to ensure an efficient distribution. In summary, it is possible to distribute video over the public internet but, whenever the distribution on ISP networks must be optimized for quality of scalability reasons, the ISP is always necessarily involved, which is nothing new with MABR.

The second observation is that, today, these OTT offers are almost exclusively SVOD, and optimizations for this type of content are much less relevant than they are for live. A VOD asset is already fully available at the start of the streaming session and doesn’t suffer any latency constraint, so the client can use a large buffer on the player and secure a good quality playback this way, even in poor network conditions. Live, on the other hand, is created on-the-fly and cannot use the same strategy without ruining its starting time and latency. Making sure that the network delivery is good enough is an absolute must to avoid a situation where players frequently stop. On scalability, it should also be noted that VOD assets are unlikely to generate traffic peaks at the same level as live events and, therefore, don’t dimension a network.

It is very much expected that third-party OTT service providers will more widely offer live events in the near future; it has actually already started with some services in some countries. This is also probably the point in time where we will see more and more agreements with ISPs to optimize distribution.

In Conclusion

Multicast ABR technology is quite disruptive, and there is logically a certain number of interesting topics where the impact of such implementation doesn’t necessarily appear obvious, and for which is it is natural to raise questions. But, for these questions, it is certainly worth taking the time to think about how exactly MABR would operate in a real-life scenario. Also, when comparing options, it’s important to be very clear on what alternative MABR is actually compared to, whether traditional broadcast delivery (possibly ABR-assisted for nonlinear content) or to the all-unicast ABR option. When doing so, the important role that MABR has to play in the future of video delivery usually appears quite clearly, especially for the few topics tackled in this article, as presented in the summary table below.