Comment by fuzzfactor

When the media server is only intended to broadcast a single stream 24/7 whether it is live from a newsroom or real-time from a media library, and there is no need for end-user-interaction with the media server itself, multicast only requires the server to serve to a single IP address and any clients on that network can just tap into it at any time through the routing hardware. The server just pours its streaming data into a single widely-accessible IP address and doesn't need to have any idea how many clients are active at all.

So multicast is when you want hardware outboard of the server to do all the distribution, the maximum number of simultaneous client users is then not limited by the server resources since the server itself only serves that one stream to a single IP address no matter how many users or not tap into the stream beyond that point.

The more familiar default approach for more common servers and routers is not multicast, but regular unicast instead. Where the server allows individual asynchronous interactions directly with each user like you expect in a common office network (or the internet), hardly anything identical is intended to be accessed simultaneously by the clients. But of course the server then needs to handle the distribution to each user individually like in a basic office network, which can add up to a lot of IP connections for the server to contend with compared to only a single IP if it was multicast.

So the number of simultaneous users is then limited by the number of connections that the server itself can maintain under unicast, which is an un-necessary additional bottleneck that can be avoided by using multicast if everything on that "channel" is going to always be simultaneous anyway.

Not my downvote btw.