Multiview’s Vendor Landscape: How Streaming Architectures Determine Success
Multiview—the ability to watch two, three, or four simultaneous feeds on a single screen—is increasingly a core capability in live sports streaming. The technical distinction that matters most isn’t the feature itself, but the architecture used to deliver it.
Though some large companies like YouTube develop their own multiview technology (Figure 1), most publishers will choose from a small group of suppliers, which includes Skreens, Broadpeak, Synamedia, and Tiledmedia. Each represents a distinct architectural path, including server-side, packager-side, and player-side multiview.
Figure 1. YouTube’s homegrown multiview feature set the standard for sports viewing. Image from Tom's Guide.
Let’s start with a brief description of the architecture and the companies that provide the products and services that enable them. Then we’ll discuss the factors to consider when choosing the best solution for your broadcasts.
Architecture 1: Server-Side Multiview (Skreens)
In a server-side architecture (Figure 2), multiview channels are assembled from other channels encoded as normal. After the multiview is defined, the component channels are handed off to a compositing engine that ingests them into a single video according to the designated layout.
Figure 2. In server-side multiview, the service composites and encodes the multiview, and sends a single stream to the player, just like any other channel.
The compositor then encodes that composite into a new ABR ladder that looks like any other live channel to the origin and packager. The player decodes the single multiview video, which makes the approach compatible with virtually any STB, smart TV, or CTV device that can already play the service’s live channels.
This is why server-side multiview is appealing to operators with a large installed base of legacy devices: they can launch multiview without touching the player and without worrying about synchronized multi-stream playback on underpowered hardware. As you’ll see, the tradeoff is infrastructure cost and complexity, since every distinct static layout or build-your-own combination is effectively a separate channel that must be rendered and encoded in the cloud.
Skreens is a provider of server-side multiview under the Tessera brand. In addition to selling direct, Skreens is the technology beneath MediaKind’s MK.IO multiview, which Comcast has deployed as Xfinity Multiview on X1 and Xfinity Stream. In April 2026, Skreens announced an agreement to deploy its Tessera software platform “to support curated multi-view presentations for select major live events, including the upcoming FIFA World Cup presented by FOX Sports and streaming on FOX One.”
Architecture 2: Client-Side Multiview (Tiledmedia)
In a client-side multiview architecture (Figure 3), the service delivers multiple feeds to the client, which is responsible for decoding and rendering them into a single stream. Nothing is pre-composited in the cloud.
Figure 3. In client-side multiview, multiple feeds are delivered to the player.
On the network side, the CDN simply serves Feed A, Feed B, Feed C, Feed D as ordinary independent HLS or DASH streams. The multiview control plane runs alongside the app and sends layout metadata down to the player: which feeds to show, how many tiles, where to place them, and which tile has audio focus. On the device, the player opens multiple concurrent connections to the CDN, maintains ABR for each feed, keeps all active streams frame-accurate, and composites them into a single layout on the app’s canvas.
The benefit of this approach is flexibility. Because there is no server-side compositing, the operator isn’t limited to a fixed set of pre-rendered layouts. It can support any combination of inputs in any arrangement without spinning up new cloud encoders.
The downside is that all the heavy lifting moves to the device. In practice, there are two different client-side designs. Most early commercial deployments ran multiple independent player instances, each with its own ABR and decode pipeline. Tiledmedia represents a narrower but more efficient category: a single specialized player that composites multiple feeds onto a single decoding canvas rather than running several full players in parallel.
An implementation that spins up multiple independent decoders will quickly hit CPU, GPU, and memory limits on commodity smart TVs and low-end streamers. Client-side multiview becomes viable only when you efficiently solve decoding, ABR, and synchronization within a specialized player.
Tiledmedia offers a client-side solution: one player handles retrieval, composition, sync, and display. It uses codec-aware tiling, streaming multiple feeds, tiling them, and compositing them in the player rather than the server.
One subtle but important UX advantage of client-side multiview is audio focus. Because the player manages multiple decoders locally, switching the main audio from one tile to another is instantaneous, with no manifest changes or extra buffering. In server-side and packager-side models, changing audio often means switching tracks or renditions in the manifest, which can introduce a small but noticeable hiccup for the viewer.
In addition to Tiledmedia’s single-player solution, several commercial player SDKs now offer multiview as a feature. Dolby OptiView exposes a MultiViewPlayer in its SDK, so any service already using the OptiView player can add multiview. Bitmovin’s Player SDKs support multiview on iOS, tvOS, and visionOS through a framework that manages up to five player instances per screen. These options are best thought of as player features, whereas Tiledmedia, Skreens, Broadpeak, and Synamedia are purpose-built multiview systems.
Packager-Side Multiview
In packager-side multiview (Figure 4), multiview is built at the packager/origin layer rather than in a cloud compositor or a heavy client. All the live cameras or program feeds are first encoded into conventional ABR ladders.
Figure 4. With the packager-side approach, multiview is created in the packager using HEVC or VVC tiling.
The key component is a multiview layout service that sits beside the packager. This service receives layout choices from the app and translates them into metadata parameters that define which input streams should appear in each tile, how large each tile is, and where on the screen it belongs. Those instructions are sent to the packager, which uses its existing manifest-manipulation and tiling logic to assemble a virtual multiview channel from the set of input ladders. What travels through the CDN is a single tiled bitstream with a conventional HLS or DASH manifest.
Crucially, the individual channels must be encoded using HEVC (or VVC) with a consistent tiling scheme and motion constraints. With tile-aware encodes in place, the multiview packager can assemble virtual multiview channels by selecting and aggregating tiles in the compressed domain with lightweight header rewriting, so any HEVC-capable decoder can render the result as a single stream.
From an operator’s perspective, this architecture turns multiview into an incremental packaging problem rather than a transcoding project. You continue to encode each input once, as you already do for standard linear channels. The multiview layout service and origin know how to remix those encoded segments into many different multiview variants by updating manifests and tile maps.
Two companies offer solutions in this class: Broadpeak and Synamedia. Broadpeak calls its implementation Multiview with a “multi-package” architecture, which is an extension of Broadpeak’s origin packaging and cloud DVR technologies. Multiview lives in the same tier as their existing origin packager and personalization stack, and is available as licensed software, a SaaS offering on Broadpeak’s platform, or a fully managed service.
Synamedia markets its solution as Synamedia Multiview built on top of the Quortex cloud video platform. As of June 2026, Synamedia’s Video Network business, which includes Quortex, is being acquired by Lumine Group, with the deal “anticipated to close in the near future.” This means the underlying multiview stack will live under the Quortex brand inside Lumine rather than as a longterm Synamedia product line.
Decision Matrix: How to Choose an Architecture
Now that you know the architectures and the players, let’s walk through the factors you should consider when choosing among them. Table 1 contains the details, starting with processing location, or where the multiview is created, which has a direct impact on device compatibility.
Table 1. Factors to consider when selecting a multiview architecture
Compatibility: Server-side > Packager-side > Client side
As mentioned earlier, compatibility is a key strength of server-side; any device that can play a regular stream from the service can play a multiview feed. In contrast, with client-side multiview, many smart TVs and low-end dongles can decode only one or two simultaneous streams, which effectively limits reliable multiview to higher-end CTV devices and boxes like Apple TV.
Packager-side technologies are similar to server-side. As long as the device can decode an HEVC multiview stream, it should be able to play the tiled multiview output without any special player changes.
From Static Multiview to BYOMV
The first wave of multiview was one-size-fits-all, where every viewer saw the same layout with no control beyond changing channels. That model proved the value of multiview, but it did nothing for personalization or first-party data. Most first-generation multiview services enabled one or more fixed channels, but no customization.
Over the last few years, the center of gravity has shifted towards personalization, spawning the acronym BYOMV (Build Your Own Multiview). YouTube TV, Sunday Ticket, ESPN, Peacock, and others now let viewers choose which games or cameras appear in each window. The expectation is no longer “here is your quad;” it’s “here is a canvas—fill it yourself.”
All three architectures can deliver that per-user flexibility. The real question is what it costs to offer that level of personalization at scale.
Paying for Customization
With server-side, each unique multiview channel requires its own real-time composite encode, so offering true BYOMV to hundreds of thousands of viewers gets expensive fast. In practice, most services cap the number of multiview channels and share them across users with similar selections, so two local NFL games might be combined into a single multiview channel that serves many viewers.
With client-side multiview, there is no extra encoding cost; the service simply makes the individual live streams available, and the player fetches and composites them. With packager-side multiview, each channel is encoded once, and the packager assembles many different multiview combinations by remixing tiles in the manifest, so you avoid per-layout transcoding entirely. The main incremental cost is packager complexity, which is typically far lower than multi-encode server-side but higher than a pure client-side approach.
Bandwidth Cost
In terms of bandwidth, server-side multiview behaves just like any single channel. Whether the viewer is watching one game or four, the bitrate is comparable to your normal 4K/HD channel.
This is a real point of differentiation among client-side multiview technologies. In “many-players” implementations, each tile is a separate player instance that believes it’s full-screen, so it often pulls the 4K top rung and then shrinks it. In this case, a 4-up layout may approach 4×4K bandwidth in the worst case.
In contrast, Tiledmedia’s single-player multiview selects per-tile rungs that match the pixels they will display. For a 4-up layout on a 4K screen, the player pulls roughly 1080p for each quarter-screen tile. Four 1080p encodes are typically less efficient than a single 4K encode, but not by much. With packager-side multiview, the principle is similar but is implemented in the origin rather than the player. Not as efficient as server-side, but nowhere close to 4x.
Ad Integration
Next up is ad integration. Server-side implementations have the cleanest story. Because the compositor outputs a single channel that is indistinguishable from any other live stream, it plugs directly into existing dynamic ad insertion (DAI) workflows without modification. Skreens markets Tessera explicitly on this basis. The practical upside is zero new ad-tech integration. In a BYOMV scenario, personalized ads are theoretically possible, but they would require a dedicated encoder output per viewer. Without that, every viewer watching the same multiview composition sees the same stitched ad.
Client-side implementations open the door to genuine per-viewer ad personalization via a different mechanism. Rather than DAI full-screen breaks, Tiledmedia's model (Figure 5) embeds advertising as a tile within the multiview layout itself. Tiledmedia’s dedicated advertising page calls it “personalized multiview advertising” and describes it as follows: “Publishers and advertisers can choose to display their advertisement in a small window in the corner of the screen (Picture-in-Picture), side-by-side with the main content, or in any other configuration. The solution is fully customizable and personalized… Wilma might see a soft drink ad in her PiP, while Fred is served a sneakers ad.”
Figure 5. Personalized multiview advertising from Tiledmedia
This technique keeps the viewer in the multiview experience rather than cutting away to a full-screen break, and it enables household-level or profile-level targeting. The integration overhead is correspondingly greater: ad decisioning happens at the player level, which means ad-server calls, impression tracking, and frequency capping all need to be wired into the client rather than handled server-side.
Packager-side implementations sit closest to the DAI model in practice, but with an important extension. Because each multiview combination is assembled as its own rendition, it can be registered with the DAI system as its own inventory unit. Broadpeak’s Damien Sterkers explained the logic in a recent interview on Streaming Learning Center: “We just announce to the ad server that we have more inventory available, and it can decide to insert ads specifically on this multiview application.”
He also highlighted a format innovation that becomes available when the video compositor controls the layout: “A standard L-shaped banner, for example, typically zooms out the video and fills the surrounding space with a still image. With multiview, that space could carry a live video instead.”
Synamedia’s product page doesn't address advertising directly, but its API-based “business logic” layer for channel selection is the natural hook for ad decisioning at the packager level.
Synchronization and Latency
Synchronization and latency are where the architectures diverge in day-to-day operation. Server-side and packager-side align all input feeds before encoding and packaging, then deliver a single synchronized stream, so LL-HLS or LL-DASH behave just as they do for a single game: one manifest, one buffer, one live edge.
The client-side approach has to juggle several live manifests and buffers in parallel, which makes strict frame-accurate sync at low latency harder, but it compensates with a snappier feel when viewers swap audio focus or change layouts, because those actions are resolved entirely in the player.
Integration Effort by Architecture
From an implementation perspective, server-side multiview is primarily a backend project. Skreens-style multi-encode solutions require you to deploy a compositor and encoder farm in your cloud or on-premises, integrate it with existing encoder, origin, and control plane workflows, and expose the resulting multiview channels in your catalog. On the client, you keep your current player and focus on adding dynamic multiview channels to the UI.
Client-side multiview reuses your existing live ladders for each game or camera; the work shifts to the player SDK and app. You need signaling or metadata so the app knows which feeds to open, has logic to keep them synchronized, and has enough device horsepower to decode and composite multiple streams. But the encoder and origin stacks change very little.
Packager-side multiview from Broadpeak and Synamedia lives in the origin or packager tier, so you still encode each channel once and let the multiview service assemble combinations at packaging time. Integration means enabling tiling-aware packaging in your origin, deploying the multiview control service, and ensuring your existing player can decode HEVC and interpret layout metadata, keeping client changes modest compared to a fully client-side implementation.
Conclusion: Multiview as an Architecture Decision, not a Feature
Multiview isn’t a feature you bolt on. It’s an architecture decision that shapes which devices you can reach, how much you pay to operate at scale, and how much control your product team has over the viewer experience. Server-side, packager-side, and client-side each represent a genuinely different set of tradeoffs across those dimensions. The right choice depends on your device footprint, customization requirements, existing infrastructure, and cost model. This article is meant to give you a solid framework for making that call.
Related Articles
Perhaps the booths that cropped up on my NAB 2026 itinerary and the sessions I squeezed in between simply skewed this way, but it seems like everyone's favorite sport in streaming this year is, well, sports. Certainly, when it comes to live, the pinnacle of achievement appears to be seamless delivery of premium sports events at global scale, with an eye to "meeting fans exactly where they are"—crossing national, lingual, and cultural borders via localization, and transcending generations through autogenerated highlights and verticalized mobile delivery. And when it comes to traditional landscape sports video streamed to conventional CTV glass, multiview more than ever seems to be the name of the game in 2026.
21 Apr 2026
With all of the inherent difficulties of delivering low-latency live streams at scale, and the growing interest in providing sports viewers with state-of-the-art multiview experiences, what additional technical challenges does multiview delivery create in streaming's fraught middle mile, and how do top-tier global broadcasters like Globo meet those challenges? Globo Head of Streaming and CDN Platform Marcos Petry discusses how Globo maintains and tunes streaming latency for multiview sports streams in this conversation with streaming consultant Bhavesh Upadhyaya at Streaming Media Connect in December.
30 Jan 2026
The largely unsung hero in YouTube's growth may be a feature that cost the company 99% less to implement than Sunday Ticket: multiview streaming capability. As this article shows, if you're broadcasting sports, multiview--particularly Build Your Own Multiview (BYOMV)--is quickly becoming an expected feature among sophisticated viewers. It's also one of the most affordable and effective ways to amplify the value of your programming, particularly when your content isn't exclusive and faces direct competition in the same market.
19 Aug 2025