Multicast vs Unicast vs Broadcast: Which One for Video Distribution

The three models in one table

Model	Delivered to	Replication happens at	Role in video distribution
Unicast	One receiver per connection	The sender (one copy per viewer)	VOD, interactive sessions, cross-segment delivery
Broadcast	Every host in the subnet, wanted or not	Every host receives a copy	Effectively unused for video
Multicast	Only receivers that joined the group	Forks in the distribution tree	One source to many screens on a LAN

The real difference: where packets are duplicated

• Unicast: the sender builds a separate point-to-point connection with each receiver. 100 viewers means 100 copies from the sender. Sender bandwidth and CPU become the bottleneck.
• Broadcast: packets go to every host in the IP subnet whether they want them or not. Because routers do not forward it, its scope is tiny — local subnet only — and it disturbs every device on that subnet, so video distribution avoids it.
• Multicast: the sender transmits one copy. Multicast routers build a tree using multicast routing protocols and replicate only at the furthest possible fork, raising efficiency and reducing backbone congestion.

Why multicast saves bandwidth, in real numbers

Take one 8 Mbps 1080p stream going to 60 screens:

Model	Sender uplink	Backbone load	Verdict
Unicast	8 Mbps × 60 = 480 Mbps	480 Mbps	Saturates gigabit; the encoder cannot sustain it
Broadcast	8 Mbps	8 Mbps, but every device must process it	Disrupts other traffic; unusable
Multicast	8 Mbps	About 8 Mbps, growing only after forks	Adding screens barely loads the sender

That is why multicast is the standard answer for one source to many screens on a LAN: transit PIS, campus signage, showroom video walls and surveillance walls all follow this model.

Multicast addresses and IGMP basics

• Address range: IPv4 Class D, 224.0.0.0 – 239.255.255.255. The 224.0.0.0–224.0.0.255 block is reserved for local network control (224.0.0.1 is all hosts) and must not carry business traffic; 239.x.x.x is the administratively scoped range, suitable for planning inside an organisation.
• IGMP: receivers use IGMP to tell the local router they want to join a group. The encoder and decoder must agree on multicast IP and port.
• Practice: allocate addresses from 239.x.x.x with a written plan, and never let two different streams share one multicast address.

The switch feature you must enable: IGMP Snooping

The fix is IGMP Snooping: the switch listens to IGMP traffic and forwards each multicast stream only to ports that actually joined the group.

• Always enable: IGMP Snooping on Layer-2 switches.
• As needed: an IGMP Querier. With no Layer-3 device querying, one switch must take the role, otherwise group memberships age out and the stream stops.
• Verify: check port counters — ports that never joined the group should carry no multicast traffic.

Typical multicast faults and how to isolate them

Symptom	Likely cause	Action
No picture on any receiver	Multicast address or port mismatch, or multicast output disabled on the encoder	Test with VLC at udp://@address:port on a receiver
Picture appears then dies after minutes	No IGMP Querier; group membership aged out	Enable a querier in the network
Whole network slows, including non-receivers	IGMP Snooping off; multicast is flooding	Enable IGMP Snooping
Nothing arrives across subnets	No multicast routing (PIM) on the router	Multicast does not cross Layer 3 by default — add multicast routing or a unicast relay
Some screens fine, others stutter	Insufficient bandwidth or loss on one link	Inspect per-port traffic and error counters

The short version above covers the common cases. When it does not clear the fault, work through the failure modes below — between them they account for nearly every multicast problem we see on video networks.

Identify it by the symptom first

Three symptoms cover nearly every multicast fault, and each points at a different cause. Do not start by reading the switch configuration; start by noting exactly what the screen does.

Symptom	Most likely cause
Screens are live for a few minutes, then go black and stay black	Snooping enabled with no querier — group membership timed out
Video works but unrelated devices on the network slow down	No snooping — multicast is being flooded to every port
Video reaches ports that were never meant to receive it	Unknown-multicast flooding left on, overriding snooping
Nothing arrives at all, on any port	VLAN separation, TTL, or the stream is not leaving the encoder

The mechanism behind all of them is the same: a switch that does not know who asked for the stream has to guess, and the guess is always "everybody". The background is in Multicast, Unicast and Broadcast Explained.

Failure 1: no snooping, so the switch floods

Without IGMP snooping, a Layer 2 switch has no way to tell multicast from broadcast and forwards it out of every port in the VLAN. Your video lands on the CCTV network, the ticketing terminals and the building management system, none of which asked for it.

This one is easy to recognise because it does not look like a video fault. Video keeps playing; everything else gets slow. If the complaint arrives from the IT side rather than the AV side, suspect flooding first.

Failure 2: snooping without a querier

This is the most reported multicast fault in the field, and it is a partial configuration rather than a missing one. Snooping lets the switch learn which ports want a group, but that learned state has a lifetime. Something has to periodically ask who still wants the stream. That something is the IGMP querier.

With no querier, membership ages out and the switch stops forwarding. Screens go black a few minutes after the stream starts and do not recover until something re-triggers a join. The give-away is the delay: a stream that works on commissioning and fails before the client arrives is almost always this.

The fix is not to disable snooping — that converts the problem into failure 1. Enable snooping and make sure a querier exists. On many installations the querier is the router or Layer 3 switch; on a flat Layer 2 network with no router, the switch itself has to be configured to act as querier. Check which device is sending the queries rather than assuming one is.

Failure 3: unknown-multicast flooding left enabled

Plenty of switches ship with a feature that floods multicast traffic whose group has no learned membership. It is on by default on some models, and it silently undoes the snooping you just enabled: groups that should be constrained still reach every port.

Look for it under names along the lines of "flood unknown multicast" or "unknown multicast flooding", and turn it off where the option exists. If it cannot be disabled on the hardware in front of you, the workaround is to constrain the traffic at layer 2 with a separate VLAN so the flood is at least confined.

Two more that look identical: VLAN and IGMP version

VLAN separation. Multicast does not cross a VLAN boundary unless it is explicitly routed. If the encoder sits in one VLAN and the decoders in another, no amount of snooping configuration will deliver the stream. Put the video devices in one VLAN, or configure multicast routing between them deliberately.

IGMP version mismatch. IGMPv2 and IGMPv3 behave differently, and a source-specific setup that assumes v3 will not behave as expected against a switch running v2. Confirm the version on both ends rather than leaving it on a default. Where the network also carries other IP video, agree the version across all of it.

Diagnosing it with a capture

The decisive test is not a configuration review, it is a packet capture on a port that should not be receiving the stream.

1. Start the stream and confirm it is playing on a port that should receive it.
2. Capture on a port in the same VLAN that should not receive it.
3. Watch for the multicast group address in the capture. Traffic here means flooding is still happening.
4. Leave it running. If the capture is clean but the receiving screen goes blank after several minutes, the fault is querier or membership timeout, not flooding.

This distinguishes failure 1 from failure 2 in one session, which a configuration read cannot do because both present as "snooping is enabled".

The configuration sequence that works

1. Give video its own VLAN and keep it away from anything safety-critical or latency-sensitive that is not part of the design.
2. Enable IGMP snooping on every switch in the path, not just the core.
3. Confirm a querier exists and that queries are actually being sent. Configure one explicitly if nothing else is doing it.
4. Disable unknown-multicast flooding where the option exists.
5. Set and document the IGMP version on both encoder and switch.
6. Prove it with the capture above, then re-prove it after any firmware upgrade on the switches.

Step 6 is not ceremony. Switch firmware updates reset or change multicast defaults more often than anyone expects, and a network that worked before an upgrade is not evidence that it works after.

Address planning before you start

Assign multicast group addresses deliberately rather than accepting defaults. Use the administratively scoped range set aside for private use, give each programme or channel its own address, and write the allocation down. Two channels sharing an address, or a video group colliding with an unrelated multicast application, produces faults that look exactly like switch misconfiguration and are not.

Encoders expose the multicast address and port as configuration; the ZY-EH1304 and ZY-EH1308 both appear on the network as standard UDP multicast sources and are managed through the web interface, where address, port and per-stream protocol are set per channel.

Verification: the 30-minute test

Item	Pass criterion
Sustained membership	Screens still live 30 minutes after stream start, with no re-join triggered
Containment	Capture on a non-video port in the same VLAN shows no video multicast
Querier present	Queries observed on the wire from an identified device
Cross-port delivery	Every intended receiver port plays, including ports on a different switch in the path
Address allocation	Group addresses recorded, one per channel, no collisions with other multicast use
After upgrade	Capture repeated following any switch firmware change

Where multicast genuinely cannot be made to work — a network you do not control, for example — the fallback is unicast per receiver, with the bandwidth cost that implies. That trade-off is the subject of How Much Bandwidth Does an IP Video Link Need?.

When not to use multicast

• Across the public internet: multicast is not forwarded publicly; use unicast plus CDN, or SRT.
• Only two or three receivers: unicast is simpler; the switch configuration is not worth it.
• Each viewer needs independent control: on-demand playback is inherently unicast.
• You do not control the network: if the switches are not yours and IGMP Snooping will not be enabled, multicast puts the whole LAN at risk.

In practice the common pattern is multicast inside the LAN plus unicast relays for the parts that must cross subnets. Draw the topology first, then decide which leg uses multicast.