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
Zum Thema IPTV findet man im
Internet sehr viel Lektüre, doch
diese ist oftmals nicht einfach zu
verstehen, denn die Texte sind sehr
langatmig und kompliziert und set-
zen einiges an Grundwissen voraus.
Ein Grund für den schweren Einstieg
in die Materie ist darin zu finden,
dass die meisten Texte nicht für TV-
Installateure gedacht sind, sondern
für Netzwerk-Spezialisten und IT-
Administratoren: zwei Welten sto-
ßen hier zusammen! Unser Ziel ist
es deshalb, Ihnen als TELE-audiovi-
sion Leser etwas Zeit zu sparen und
direkt das wichtigste zu erklären.
Der Einstieg in IPTV wird prinzipiell
wegen diesen Schlagwörtern erschwert:
TCP, UDP, RTP, Multicasting und Uni-
casting. Dabei handelt es sich aber gar
nicht um weltbewegendes.
TCP kennt praktisch jeder, der heut-
zutage einen Computer oder ein Tablet
benutzt und damit in das Internet geht.
Dieses Netzwerk-Protokoll reguliert die
Kommunikation zwischen den verschie-
denen Computern. Daten werden als
kleine Pakete versendet, die vom Sen-
der zum Empfänger von Computer zu
Computer wandern.
Damit ein Paket nicht verloren geht,
enthält es die Adresse des Senders und
des Empfängers. Außerdem enthält das
Paket auch eine Checksumme, die sich
aus den enthaltenen Daten errechnet
und es so am Empfänger ermöglicht,
festzustellen, ob das Paket auch korrekt
und unversehrt angekommen ist.
Das besondere an TCP ist, dass der
Sender die einzelnen Pakete versendet,
diese jedoch im Speicher belässt, bis
vom Empfänger eine Bestätigung zum
Empfang zurückkommt. Ist dies der Fall,
kann der Sender die Daten des korrekt
empfangenen Paketes vergessen, an-
sonsten wird dieses Paket erneut ver-
sendet und zwar solange, bis die Emp-
fangsbestätigung zurückkommt. Die
Reihenfolge in welcher die einzelnen Da-
tenpakete empfangen werden ist nicht
wichtig – sie werden am Empfänger wie-
der richtig einsortiert.
Als Analogie kann man sich TCP wie
eine Amateurfunk-Verbindung zweier
Funker vorstellen: der erste sendet ei-
nen größeren Text und wartet nach je-
dem Satz, dass der zweite Funker den
empfangenen Satz mit einem „Roger“
bestätigt. Hat er diesen nicht verstan-
den, wird er eben noch einmal gesendet.
Für Datenübertragung ist dieses Pro-
tokoll ideal, denn es garantiert, dass die
Daten korrekt und unversehrt ankom-
men. Für eine Live-Übertragung von Au-
dio und/oder Video ist dieses Protokoll
allerdings weniger gut geeignet, denn es
gibt zwei Probleme:
- Die Bilder (oder der Ton) müssen in
der richtigen Reihenfolge ankommen.
Was nützt es daher, wenn das dritte
Frame verloren gegangen ist und nach
dem siebten erneut gesendet wird?
- Die Checksumme ist überflüssig,
denn wenn die Bilddaten eines Frames
nicht korrekt empfangen wurden, dann
ist es trotzdem zu spät, dieses Frame
erneut zu senden.
Wegen dieser Gründe eignet sich für
Live-Übertragungen von Audio und Vi-
