Beyond the technology: Building a commercially sustainable multiview platform

Delivering multiview is no longer primarily a technical challenge. Modern workflows can create compelling multiview experiences using several architectural approaches (e.g. headend encoding, proprietary player, server-side packaging). The real challenge is deploying the service in a way that remains economically sustainable as consumer behavior becomes increasingly dynamic.

The 2026 FIFA World Cup is proving this in real time, as operators manage concurrent multiview demand across simultaneous matches, time zones, and millions of subscribers. For operators using server-side packaging, the commercial implications of that demand are worth examining closely, because the workflow has a dual personality:

There is a “push” element of the workflow and a “pull” element of the workflow, each acting asynchronously from one another.

Server-side multiview creates two completely different cost models that should not be priced the same way.

As illustrated by the diagram above, one half of the multiview workflow is predictable, while one half is unpredictable. One half should be built on capacity-based pricing, whilst the other half should be built on usage-based pricing.

The push workflows: predictable costs

The “push” element of the workflow (left side of the diagram above) is where eligible linear channels are transcoded into HEVC or VVC compliant “tiles” and then pushed into an Origin as a “storage room” awaiting real-time requests to be fetched. This part of the architecture is linear and scales according to the total number of linear channels configured as eligible for multiview channel combinations. The more channels the operator declares as eligible (via their UI to subscribers), the more transcoding, linear packaging (for CMAF segment building) and origin resources required.

The commercial mechanism is rather straightforward. How many channels does the operator want to make available for multiview combining? That is the pricing lever for transcoding, packaging and origin storage.

The pull workflow: where costs become unpredictable

The “pull” element of the workflow is more complex commercially speaking, because it’s more dynamic than linear channel encoding. The creation of multiview channels is done by a multiview Combiner (or by embedding functionality in the JITP, “Just-in-Time Packager”). The consumer’s UI offers them lists of channels to choose from (those marked as “eligible” in the workflow above under “push”). Once the consumer selects the channel numbers and screen-locations for their multiview channel(s), a request is made to the multiview Combiner to pull together all individual manifests for the creation of a single video channel with multiple audio tracks and closed caption (or subtitle) streams. The newly combined multiview channel is pulled back by the client.

The commercial challenge for the “pull” part of the architecture is that the operator couldn’t possibly predict with accuracy how many total multiview channels declared in their back-office will be actively running at any given time and for how long. The net effect is that scaling needs to account for either on-premises hardware resources (i.e. how many servers required for combining at peak) or cloud resources (i.e. how many machine instances of which type for compute-resource calculations and how much egress to plan for).

Why traditional licensing breaks down

Traditional licensing assumes predictable workloads. For example:

• Number of channels
• Number of encoders
• Number of outputs
• Number of subscribers

Multiview isn't like that. The encoding side is predictable, but consumption is highly dynamic. Subscribers create combinations dynamically. Usage is bursty. Peak demand can occur during major sporting events.

As just one example:

• An operator may declare 200 channels eligible for multiview. That predictable decision defines the encoding and origin requirements.

• One million subscribers pull from 160 of the eligible channels and define a total of 160,000 unique multiview channels (stipulating which corner of the channel will hold which eligible video tile).

• Calculating a 24-hour usage for a 30-day month of any given channel may conclude a value of 3,100 GB/month in egress traffic (the consumption part of the commercial model).

• However, in actuality, it is statistically impossible to assume that 160,000 unqiue multiview channels will all be watched 100% of the time (24x30).

• So the operator decides to assume a peak concurrency rate of 15%, meaning that at any given time they may be expecting to egress 15% of 160,000 multiview channels to their subscribers. This would yield (160,000 * 0.15) * 3100 total GB per month of egress (74.4m GB/month).

• In actuality, subscribers likely watched their multiview screens on average for far less, and only on-and-off during the day as a practical behavior of navigation. Further complicating this scenario is that large-scale sporting events could drive wildly atypical demand (e.g. World Cup, Superbowl, NASCAR, NBA Championships, Final Four, etc).

Why metered pricing is the answer

The best commercial model is to create a metered solution which tracks total Gigabytes per month actually utilized for serving multiview channels. Then a simple GB/month rate can be established and the operator need not concern themselves with predictive management of functionality usage in order to be accurately charged. In order to facilitate such a commercial model, it’s important to build that into the technical infrastructure of the multiview combiner (or JITP) so that it’s capable of tracking and logging this traffic and isolating it from other linear or on-demand traffic.

Another key advantage of this approach is that trends can be analyzed by the operator regarding which multiview channels (or individual eligible channels within them) have proven to be the most popular, and whether there was an inefficiency regarding consumer dynamic selection of multiview channels which could have reduced the total number of multiview channels active in the network, and thereby have reduced the monthly GB total and produced a lower bill. As case in point, let’s assume that the following 4 linear channels are all marked as “eligible” by the operator:

• ESPN

• Fox Sports 1

• NFL Network

• NBA TV

Subscribers could select the same four channels above but may place them in different corners of a 2x2 tile screen (multiview channels can be larger, of course). Each unique screen combination of channel numbers and locations on-screen is a unique multiview channel. Each multiview channel adds potentially more monthly network traffic (towards GB/month total). So the operator may do well to actively evaluate multiview channels being requested by subscribers and limiting them to pre-existing multiview channels if the same exact channels are present but in a different screen layout, thus saving on total monthly traffic and lowering their bill.

From estimated to metered billing: a better path forward

As multiview evolves from a premium feature into a mainstream viewing experience, commercial models must evolve alongside the technology. The most successful deployments will not necessarily be those with the most sophisticated architecture (although this certainly helps), but those whose commercial model accurately reflects how subscribers actually use the service. Separating predictable infrastructure costs from dynamic consumption costs creates a pricing framework that is fair to operators, sustainable for vendors, and capable of scaling with future demand.

Learn more about Quortex Multiview