1
2
3
4
150
TELE-audiovision International — The World‘s Largest Digital TV Trade Magazine
— 09-10/2013
—
FEATURE
Selfmade IPTV
1. Schematics of a MULTICAST
transmission. The server sends
one stream to the switch. The
transmission is then forwarded
to all connected devices.
2. Schematics of a UNICAST
transmission. The server sends
one stream to the switch, but
this time the stream is only
forwarded to one specific client.
Notice how the remaining ports
are fully available for other
communications.
3. Analogy of UDP: one
transmitter sends information,
regardless of how many
listeners there are. Also,
there is no feedback to the
transmitter. If a listener misses
a part or if he cannot correctly
receive the transmission, there
is nothing to do about it – the
transmitter will never know!
4. Analogy of TCP: one
transmitter sends information
to one listener. The reception
of every sentence has to be
confirmed by the listener. If he
missed the sentence or if he
did not understand it clearly,
the transmitter will send the
sentence again.
Vitor Martins Augusto
You can find quite a bit of infor-
mation on IPTV in the Internet
but it’s often not all that easy to
understand since it can be very
long-winded and complicated and
assumes the reader has some ba-
sic knowledge. One reason for the
difficulty in getting started in this
field is that most of the material
doesn’t have TV installers in mind
but rather is more geared towards
network specialists and IT admin-
istrators; two worlds bump into
each other here. Our goal is to save
our TELE-audiovision readers some
time and describe the more impor-
tant points.
Taking the leap into the IPTV world is
made complicated by these keywords:
TCP, UDP, RTP, Multicasting and Uni-
casting. But none of these are really
earth-shattering.
Almost everyone today that uses a
computer or tablet to get to the Inter-
net knows what TCP is. This network
protocol regulates the communication
between the various computers. Data
is sent in small packets from the send-
er’s computer to the recipient’s com-
puter.
To prevent the loss of a packet, it
contains the address of the transmit-
ter and the receiver. The packet also
includes a checksum that is calculated
from the data it contains. This makes it
possible to determine if the packet ar-
rives correctly and undamaged.
The best thing about TCP is that the
individual packets are transmitted until
a confirmation is sent back by the re-
ceiver. If this is the case, the transmit-
ter can then forget about the correctly
received data. Otherwise, the packet
would be retransmitted as often as
needed until a reception confirmation is
sent back. The order in which the indi-
vidual data packets are received is not
important – they will be placed in the
proper order by the receiver.
You can look at TCP as an amateur ra-
dio communication between two Hams:
the first Ham transmits a lengthy mes-
sage and after each sentence waits for
the second Ham to signal that he re-
ceived the message by saying „Roger“.
If he didn‘t understand it the first time,
the first Ham repeats the transmission.
This protocol is ideal for data trans-
missions; it guarantees that the data
arrives correctly and in one piece. For
live video and/or audio transmissions
this protocol is not as ideally suited.
There are two problems:
1) The video (or audio) has to arrive
in the correct order. What good would
it do if the third frame, for example, is
lost and after the seventh frame the
whole thing is repeated?
2) The checksum process is redun-
dant. If the image data of a frame
doesn‘t arrive correctly, it would be too
late the retransmit that frame.
