Figure 2. With server-side multiveiw, the server does most of the work, and the multiview looks like any other stream.

The Future of Multiview: Client, Server, and Build Your Own (BYOMV)

Multiview, or the ability to view multiple live feeds simultaneously, is quickly becoming a must-have feature for sports and live-event streaming. The core technical question for providers is how to implement it. 

There are two main architectural options: client-side and server-side multiview. Both can display multiple games or camera angles on a screen, but they work in very different ways, with very different implications for reach, cost, and scalability.

What is client-side multiview?

Figure 1. With client-side multiview, the player does all the heavy lifting, restricting its usage to powerful platforms.

In a client-side approach, the work of multiview happens on the device itself (Figure 1). The publisher delivers multiple independent live streams for each input, such as Game A, Game B, Game C, and Game D. The client application retrieves, decodes, synchronizes, and displays these streams. 

That means the app must request and maintain two to four concurrent adaptive bitrate ladders, keep them synchronized to a common timeline, and then render them together. The heavy lifting happens locally, which is why client-side multiview only works on devices with the processing power to decode and display multiple HD (or UHD) streams simultaneously. 

From the provider’s perspective, client-side multiview has some advantages. You don’t need to generate new streams in your encoding farm, because you are just reusing existing single-feed ladders. You can enable Build Your Own Multiview (BYOMV) from the start because the device can pull any combination of streams the user selects. And you get more granular engagement data, since the app can report exactly which windows a viewer watched and for how long.

The disadvantages are more striking. Few smart TVs are powerful enough for client-side multiview, so you’re limited to devices like the Apple TV, which comprises less than 15% of the US market. So, the client side can’t deliver to anywhere close to a service’s entire installed base. 

Beyond that, publishers must create and maintain a custom app for each supported device, most with disparate CPU, OS, memory, and bandwidth limitations, which is both expensive and time-consuming. The player is receiving multiple feeds, and each additional feed increases bandwidth, both at the origin and across the CDN, thereby raising costs. Quality control is tougher, as synchronization and smooth playback vary by hardware and network.

What is server-side multiview?

Figure 2. With server-side multiview, the server does most of the work, and the multiview looks like any other stream, enabling universal compatibility.

Server-side multiview takes the opposite approach. Here, the work of assembling the multiview happens in the provider’s infrastructure — in essence, a multiview channel is just like any other, so it’s universally compatible. Operationally, a compositing engine ingests multiple live feeds, which can be composed of video, images, VOD files, web pages, and other compatible content types. Then it combines them into a single video frame with the chosen layout, and encodes that composite into an adaptive ladder like any other live channel. 

The advantages are obvious. Because the output is simply a normal channel stream, it plays everywhere: legacy set-top boxes, older smart TVs, and entry-level mobile phones, all without any additional platform-specific development cost. This means server-side multiview can be implemented in days or weeks, as opposed to months. 

Since you only deliver a single stream to each viewer, not multiple streams as with client-side, bandwidth and CDN costs are minimized. Quality, sync, and latency are centrally controlled. Integration is much easier because publishers don’t have to update their apps or players.

The most significant limitation is the transcoding cost. Each server-side layout is a separate channel that requires a separate transcoder. Note, however, that this channel can serve millions of viewers and that the publisher can control this cost by limiting the number of simultaneous multiview streams. 

Static versus dynamic Build Your Own Multiview (BYOMV)

Within server-side, there are two distinct flavors. Static multiview means the provider defines the layouts in advance: a “Sunday NFL” view with four games, a “March Madness” view with four courts, and so on. These layouts can be offered and delivered to all viewers at once. Static multiview is a simple, efficient, and significant improvement over single-feed viewing.

Dynamic, or build-your-own multiview (BYOMV), takes it further. Each user can choose which games or camera angles appear in their windows, and the compositor generates a unique stream for them (or for a cohort of viewers with the same selection). This unlocks real personalization and richer monetization, since viewers engage more deeply and are less likely to churn. 

The challenge is scale: without careful engineering, generating a unique adaptive ladder per viewer can overwhelm even the largest encoding farms. Modern server-side solutions address this with GPU-based compositors, efficient resource pooling, and session management that makes per-user experiences feasible at scale.

Again, even with BYOMV, the publisher can control all costs. For example, the publisher might enable 50 BYOMV channels and force the 51st viewer to choose from an existing channel. The selection mechanism would naturally nudge viewer 51 towards a channel with at least some of the desired content, limiting frustration. Given that most viewers have a limited number of sports broadcasts available at any given time, contention for true BYOMV is usually not an issue.

Table 1 summarizes the features, pros and cons of the three approaches discussed.

Table 1. Summary of pros and cons.

Real-World Choices and Implications

Let’s explore the first few true commercial multiview implementations to understand approaches used and the consequences of those technology decisions. 

FuboTV: Client-side growing pains

FuboTV introduced its multiview feature on Apple TV in mid-2020, allowing users to watch up to four channels simultaneously. This was a big step, but by limiting the experience to Apple TV users, FuboTV excluded the vast majority of Fubo subscribers who watched on Roku or other devices, causing significant frustration (see here and here). Obviously, this was a client-side approach. 

It took almost four years to reach the next major platform. On September 26, 2024, Fubo announced a multiview beta for select Roku models. 

Although Fubo’s subscribers roughly tripled from 2020 to 2024 before cratering in 2025, the raw count still paled in comparison to YouTube TV, which offered platform-wide multiview capabilities alongside a stronger sports lineup and more competitive pricing. Clearly, YouTube TV has deeper pockets and other significant inherent advantages, so a one-to-one comparison isn’t fair. It’s also obviously incorrect to posit platform-wide multiview as the key differentiator between the services. 

Still, it is fair to say that loudly debuting a feature that excludes up to 90% of your viewers is not a great way to capitalize on your first-mover status and achieve a competitive advantage.

YouTube TV: Starting with static multiview, progressing to BYOMV

In March 2023, YouTube TV rolled out multiview just in time for March Madness. The feature enabled selected users to watch up to four simultaneous streams, with audio switching and caption options. All multiviews were static, with no BYOMV.

Figure 3. YouTube TV’s BYOMV appeared for the NFL season in 2024.

YouTube TV quickly innovated from there. YouTube introduced the Sunday Ticket football package for the season starting in September 2023. Then, in 2024, YouTube introduced BYOMV, which allowed NFL fans to create up to four-panel multiview grids with customization. In May 2025, YouTube TV began testing build-your-own multiview options that expanded beyond sports. Early access allowed users to pick from channels like ESPN, Bravo, and USA, with the promise of more to be added over the following months.

Reddit users quickly validated BYOMV. “Customizable multiview is amazing. Only having their predetermined ones was fine but often I found that I couldn’t find a combo that was perfect.” Over the last five years, YouTube has surpassed Hulu as the largest vMVPD in the US, at least in part because of a market-leading sports package bolstered by market-leading multiview capabilities. 

Formula 1: high-tech multiview, but limited reach

In March 2025, Formula 1 introduced F1 TV Premium, offering a high-end viewing experience with 4K HDR streaming and customizable multiview. Subscribers could access feeds like onboard cameras, timing data, and the main broadcast, choosing up to four streams

At launch, F1 TV Premium was available on the Chrome web browser, Apple iOS, Apple TV and Roku, and the new Multiview feature was initially available on Apple iOS, Chrome web browser, and TVOS-compatible devices. F1 has been adding platforms; here’s an up-to-date list. 

Fans were ecstatic, with one Reddit user likening it to “a customizable PLC (Pit Lane Channel) equivalent, where you can drag and drop multiple streams to a single view.” Yet frustration bubbled from Android and smart TV users left out of the launch window, dampening its broader impact.

Without subscriber data, the business impact remains speculative. But F1 TV Premium showcased what client-side BYOMV can deliver.

ESPN: hybrid approach, then a system-wide rollout

ESPN has treated multiview as a device-capable premium for years. Before 2025, curated multicasts for big events were surfaced on Apple TV and Xbox so fans could select a ready-made four-up without building tiles themselves. At the same time, Apple TV devices supported BYOMV, called Multicast, with create and edit controls inside the ESPN app. 

Figure 4. ESPN enabled static multiview in its ESPN Unlimited launch.

In August 2025, ESPN launched ESPN Unlimited and an enhanced app that brings multiview to a much wider device footprint as a system-wide feature. The baseline across smart TVs is a curated multiview that behaves like any other stream, which is the practical path to broad compatibility at scale. At launch, Apple TV remains the exception, with BYOMV available to users on that platform.

ESPN’s architecture pattern is clear. Preset, server-delivered views reach the most fans with minimal friction, while Apple TV’s client-side build-your-own keeps power users happy. Xbox historically supported Multicast, though post-launch reports on multiview availability there have been inconsistent, which reinforces the core point about device variance and why the universal preset approach matters.

Real-world summary

FuboTV showed that a well-executed feature delivered to only 10 to 15 percent of its base has limited commercial impact. Apple TV users loved multiview, but most viewers never saw it when it mattered.

YouTube TV launched a multiview platform-wide, first with server-side static multiview, then with BYOMV. That combination delighted sports fans and fully complemented its investment in the Sunday Ticket. 

Formula 1 sits closer to Fubo than YouTube. The build your own feature is impressive, but availability gaps kept many customers from trying it. The jury is still out on business impact.

Interestingly, for years, ESPN quietly deployed the Fubo approach, but offered multiview as an enhancement for Apple TV users rather than a platform-defining feature. When it was time to go big, ESPN went server-side with curated presets across all major playback platforms, while retaining MultiCast on Apple TV. We’ll see if platform-wide server-side BYOMV follows.

The lesson seems clear. While advanced features are great, they likely have negative value when the substantial majority of your users can’t access them. This leaves server-side multiview as the only practical platform-wide approach. BYOMV is what customers want, delivering the most personalization and revenue opportunities. When comparing server-side multiview vendors, make sure that arrow is in their quiver.

[Author’s note: This article was sponsored by Skreens.  Skreens Tessara is a server-side BYOMV solution.]

About Jan Ozer

Avatar photo
I help companies train new technical hires in streaming media-related positions; I also help companies optimize their codec selections and encoding stacks and evaluate new encoders and codecs. I am a contributing editor to Streaming Media Magazine, writing about codecs and encoding tools. I have written multiple authoritative books on video encoding, including Video Encoding by the Numbers: Eliminate the Guesswork from your Streaming Video (https://amzn.to/3kV6R1j) and Learn to Produce Video with FFmpeg: In Thirty Minutes or Less (https://amzn.to/3ZJih7e). I have multiple courses relating to streaming media production, all available at https://bit.ly/slc_courses. I currently work as www.netint.com as a Senior Director in Marketing.

Check Also

New Interview: Dominic Sunnebo on how Sports Programming Drives Subscriber Growth

I recently interviewed Dominic Sunnebo, Commercial Director at Worldpanel by Numerator, for Streaming Media. We …

The Business Models Powering Modern Streaming

Every streaming service runs on a business model which shapes everything from content acquisition to …

Rethinking Multiview Economics: When Server-Side Beats Client-Side

As you may have seen, I’ve been spending a lot of time analyzing multiview solutions …

Leave a Reply

Your email address will not be published. Required fields are marked *