Unicast vs. Multicast: Choosing the Best Technology for IPTV Delivery

Choosing between unicast and multicast for video delivery is not a preference. It follows from whether everyone is watching the same thing at the same moment, and getting it wrong is the difference between a service that scales and one that does not.

Unicast: one stream per viewer

Unicast sends data from one sender to one receiver. The server opens a separate connection for each viewer and sends them their own copy.

That is exactly what on-demand viewing requires. Everyone is at a different point in a different programme, pausing and resuming independently, so there is nothing to share. The same applies to interactive sessions and to anything where the content differs per user.

The cost is that bandwidth scales linearly with audience. Ten thousand viewers means ten thousand streams. The network has to carry the sum, and there is no arrangement of the delivery path that avoids it.

Multicast: one stream, replicated where paths diverge

Multicast sends to a group address rather than to individual recipients. Routers along the path replicate the stream only where the routes to different subscribers separate. A single copy travels the shared portion of the path.

For a live channel this changes the arithmetic entirely. A thousand subscribers watching the same broadcast consume roughly one channel's worth of capacity across the core, not a thousand. The number of viewers stops being the constraint.

The trade is loss of individual control. Every recipient gets the same stream at the same moment, so pause, rewind and start-over are not available within the multicast itself.

Which suits what

Live linear channels are the case multicast exists for. Everyone is watching the same content at the same time, and the saving grows with the audience.

Video on demand has to be unicast. There is no shared stream to join.

Catch-up, pause and restart are unicast for the same reason, even where the underlying channel is multicast, which is why these features are usually described as an exception to how the rest of the service works.

Large scheduled events are where multicast pays for itself most obviously, because the audience concentrates at a known moment.

In practice a real IPTV platform runs both: multicast for live channels, unicast for everything else. Capacity planning has to account for the fact that the multicast load is roughly fixed with audience size while the unicast load is not.

What multicast requires of the network

Multicast is not something to enable at the last minute. It needs support along the whole path.

• IGMP for subscriber join and leave, and IGMP snooping on switches so streams are not flooded to ports that did not ask for them
• PIM or an equivalent to build the distribution tree between routers
• Multicast support in the access equipment and in customer premises equipment, which is where deployments most often fall over
• Enough capacity for the channel line-up as a whole, since every carried channel occupies capacity whether anyone is watching or not

That last point is the one that surprises people. Multicast makes the cost independent of the number of viewers, not of the number of channels.

The commercial view

Because multicast decouples cost from audience, a live service can grow without the network cost growing in step, which is what makes broad linear TV viable for an operator. Unicast on-demand does not behave that way, and its capacity planning needs to be based on concurrency rather than on subscriber count.

More on how this fits a full deployment in IPTV in 2026.