To understand how IPTV digital video distribution works, think of your LAN Network as a river of data moving down from IPTV Head-End, to the users who need to receive the video data streams.
The IPTV Head-End is a set of devices dedicated to acquire video from a wide range of sources, including satellite, terrestrial off-air, digital cable, HDMI, SDI, CVBS, IP, etc. and convert it to an appropriate format for IPTV distribution.
There are basically three methods to distribute IPTV content over a LAN Network:
Understand Digital Video Distribution over IP networks to save bandwidth and prevent network flooding.
BROADCAST – ONE to ALL
MULTICAST – ONE to MANY
UNICAST – ONE to ONE
1.- Broadcast
In a broadcast set-up, the video head-end transmits each single video stream to all devices in a network, regardless of the number of clients that will view it. The clients must extract the content which is interesting for them. It can be seen as a satellite TV broadcast equivalent: The satellite on the sky sends all programs data streams only once. It doesn’t care how many receivers are on the earth side and on which programs are them interested. On the earth side, each receiver gets all the programs on his input, and he must be able to select the one which it needs to play and discard all the others.
Broadcast is one to many transmission mechanism which reduces network server load, allowing delivery of IPTV to thousands of recipients. On the other hand, the network load suffers from this brute force transmission to all endpoints. Doesn’t matter if they need the data or not.
The video IPTV stream is replicated as required by the network’s routers and switches to allow an arbitrary number of client devices to subscribe to the multicast address and receive the broadcast.
Broadcast IP addresses range is from 224.0.0.0 to 239.255.255.255, however many address ranges are reserved for special purposes. Best practice for streaming is to use the range from 234.0.0.0 to 238.255.255.255 unless there is a specific reason to use other addressing.
Let’s see how it works in one example.
Consider an ingest head-end, with DVB streamers which receive programs from Satellite or Terrestrial, and encoders/streamers which are connected to receivers with HDMI or CVBS out.
The backbone switch has all the SPTS (Single Program per Transport Stream) streaming traffic coming into it from the DVB Streamers and Encoders, and we can stream from it N programs, identified by different colors in the diagram below.
Click image to open expanded view
In a broadcast set-up, each switch within the network will repeat all incoming traffic and transmit it to any connected device.
The streaming traffic floods the entire network regardless of whether a particular client device requests a particular program or not.
Broadcast can be used for a very limited number of programs and bandwidth. Otherwise assuming a mere 30 programs at 4Mbps each will flood the network and each receiver network interface, and will simply not work.
Broadcast transmission isn’t really a viable proposition for the public internet, as having every connected device receive all broadcast signals all the time would introduce unnecessary interference and tons of unwanted data.
Broadcast is in practice only viable on very small LANs with a very limited number of IPTV streams.
1.1 How to Set-Up koovik head-end streamers for a BROADCAST system
Head-end server for Broadcast set-up is equal to Multicast set-up. See point 2.1.
2.- Multicast
Multicast streaming is similar to broadcast in the sense that the streamer head-end transmits each SPTS video stream only once regardless of the number of clients that will view it.
The key difference is that the switches in the network only spreads/replicates the video stream to each output interface where it is requested.
This removes the redundant or useless traffic in the network which floods both the network and the client’s network interface and CPU. The client device receives only the stream it requests.
This yields a very important enhancement to efficiency for both the server and the network.
The system is capable of being up-scaled to accommodate “many-to-many” type data streaming.
Comparing with the broadcast case example, each client receiver will have an income of only 4Mbps instead of 120Mbps. This simply could be the difference between working and not working.
Traffic within switches is also clearly reduced.
Click image to open expanded view
So, the question which arises is clear: If the network switches must repeat only the programs/streams requested by devices which traffic passes through them, the client endpoints/receivers must inform the network about the program required, and the switches must react according to these requests.
A Multicast system requires that both, the network and client devices support IGMP snooping.
The Internet Group Management Protocol (IGMP) is a communications protocol used by clients and their adjacent routers or switches to allow clients to inform the network of the desire to receive, continue receiving or stop receiving a multicast stream.
It is recommended to use Layer 3 switches for IGMP multicast. If you need to use Layer 2 switches, at least one Layer 3 switch must exist in the LAN segment in order for IP multicast and IGMP snooping to work. Layer 2 switches by themselves cannot support IP multicast service. Enabling IGMP snooping on a layer 2 switch in a LAN segment in which no layer 3 switch exists can result in intermittent multicast connectivity and severe packet loss.
Multicasting with Layer 3 switches is much more efficient than with Layer 2 switches because it identifies the multicast packet and sends it only to the intended receivers. Without IGMPv2 or IGMPv3 snooping support, the switch doesn’t know the streams required and may repeat all the streams flooding machines in the network which even don’t want to play any stream, and which are used for other purposes.
The range of IP addresses reserved for multicast is 224.0.0.0 – 239.255.255.255, however many address ranges are reserved for special purposes. Best practice for streaming is to use the range from 234.0.0.0 to 238.255.255.255 unless there is a specific reason to use other addressing.
Multicast an excellent and most used solution for IPTV distribution on campus like LANs, and hospitality installations in general.
It is not a viable proposition when IPTV manager is not the network proprietary and thus he can not manage the switches/routers. It must also be ensured that all client/receivers support IGMP querying (are able to send IGMP membership Queries).
2.1 How to Set-Up koovik head-end streamers for a MULTICAST system
Enter into the embedded web server Menu.
Select IP Output in the Menu.
Simply enable the programs which you want to stream from the streamer data Ethernet port, and type the multicast address and port you want to use for each program.
You can use the same multicast IP address and a different port, or different IP address and same port, or different IP address and a different port, at your convenience.
Use TTL (Time To Live) according to the number of switches and routers that stream is needed to traverse.
3.- Unicast
Unicast is one to one connection between the streamer head-end and the client device. One sender to one receiver.
The head-end may serve multiple streams to multiple clients, but always in a one to one basis.
All LAN’s and IP Networks support Unicast stream flow. Unicast transmission requires no additional network configuration, so it becomes the preferred streaming structure for point to point program transmission.
Click image to open expanded view
When the network or the client devices cannot handle IGMP, the use of unicast prevents flooding receiver devices and computers in the network, or the network itself. Unicast directs the stream only to the specified client without special network switches arrangements.
Unicast is the predominant form of transmission within the public internet for the good reason that people who send traffic over the internet, cannot manage the network infrastructure.
Each unicast client that connects to the server uses its own bandwidth. Example: 5 clients watching a 4Mbps program stream are using a total of 20Mbps bandwidth. If only one client is watching it, the network traffic is of 4Mbps.
So, if the network must support a lot of clients and a lot of streams, this method becomes extremely bandwidth consuming, and the network infrastructure must be arranged and dimensioned according to that traffic.
3.1 How to Set-Up koovik head-end streamers for a UNICAST system
Enter into the embedded web server Menu.
Select IP Output in the Menu.
Ensure that the headend service IP, and the client receiver are in the same network segment. In the example above, all sending and receiving devices are in the range 192.168.1.xxx range. You are free to the headend streamer service IP and clients IP at any IP address within the unicast range: 0.0.0.0 to 223.255.255.255
Enable the programs you need to stream.
In this example, UDP unicast is selected in the RTP/UDP protocol drop-down. RTP can be used equally. Other koovik streamers support also http, hls, rtsp, and rtmp.
Type the client IP address and the port where the receiver will listening for incoming streams. In the example, client on 192.168.1.136 will be listening on ports 1001 and 1002 for two different programs, client 192.168.1.137 will be listening on port 1003, and 192.168.1.138 on port 1004
Use TTL (Time To Live) according to the number of switches and routers that stream is needed to traverse.
If you want to play the second program on the 192.168.1.136 client machine, simply type the URL: udp://@:1002 or udp://@192.168.1.136:1002