Unterkapitel 1:

Übertragung von Streams, Übersicht

Streaming besteht immer aus drei Elementen/ Komponenten:

1. Source-Client oder für den Live-Betrieb 'Live-Feed' genannt; die Quelle

2. Streaming-Server; er ist für die Verteilung und Weitergabe des Streams zuständig

3. Streaming-Client; der Stream-Abspieler

Der Source-Client (A) und der Streaming-Server (B) können auch im physisch gleichen Gerät untergebracht sein.
 

A) Source-Client/ Live-Feed: hier wird das Audio (beim Radio, mitunter aber auch Video) in den Stream umgewandelt und der Streaming-Server damit gespeist. Der Source-Client bietet die Grundlage bzw. die Quelle (engl.: source) für den Server, der dann diesen (Audio-)Stream weiter verteilen kann. Wenn ein Live-Ereignis übertragen werden soll, dann ist die Speisung (beim Radio) ein (Audio-)Eingang, der an den Master-Ausgang (des Sendestudios) angeschlossen wird. Der Begriff 'Live-Feed' bedeutet: 'gerade eben Zuspieler', Einspeisung von einem „live“-Ereignis.^1 2

B) Streaming-Server: Das ist der Verteil-Knotenpunkt, der Streams auf Anfrage (Pull-Modus) abgibt, sofern alle nötigen Bedingungen erfüllt sind. (Eine Bedingung könnte die maximale Anzahl der erlaubten Clients sein, die sich am Server anmelden dürfen.)

C) Streaming-Client: Nach dem typischen Server-Client-Prinzip fordert der Client beim Server Daten an, startet also eine Nachfrage ('request') und wird dann vom Server beliefert (Pull-Modus).

Der meist gebrauchte Modus im Streaming ist Pull. Der Client fordert den Stream an und „zieht“ Medien-Daten. Es besteht jedoch die Möglichkeit, dass der Server die Daten „stößt“ - der Push-Modus; nähere Erläuterungen dazu siehe '4.4.2 Push-Server und Pull-Clients'.

(Update für die Verständlichkeit - Abweichungen von der ehemaligen Bachelorarbeit)

Im Bild unten ist das Streaming zur Übertragung mit 5 Clients dargestellt, die den Stream (meist über das Internet) empfangen und abspielen können.

Bild:

Bildtext: Medienstream-Weitergabe bei Streaming

Erklärungen zur Abbildung oben: Der Source-Client (A) beliefert den Streaming-Server (B) mit dem Medien-Datenstrom - mitunter auch Live. Damit versorgt er den Server mit den interessanten und relevanten Mediendaten, die vom Server sternförmig weitergegeben und verteilt werden. Von dort, vom Streaming-Server (B), kann der Stream abgerufen und abgeholt werden; von denjenigen Endnutzern, die den Stream, z.B. zu Hause, mit einem Streaming-Client (C) abspielen und wiedergeben wollen.

So kann beispielsweise ein Radioprogramm mit nur einigen Sekunden Verzögerung weltweit über das Internet empfangen werden.

Datenaufkommen am Server: Für den Server ist einiges an Bandbreite nötig. Fast jede Übertragung zu einem Streaming-Client (C) ist eine Punkt-zu-Punkt-Verbindung und wird vom Streaming-Server (B) einzeln abgewickelt und ausgesandt (Ausnahme Multicast).  Wenn beispielsweise 5 Clients (C) den Medien-Stream abrufen, wird vom Server (B) 5 Mal die gleichen Informationen ausgesendet (Upload vom Server ins Netzwerk/ meist Internet). Ein Sonderfall ist die Übertragung per Multicast, die aber nur bei speziellen Netzwerk-Topologien zum Einsatz kommt. (Mehr dazu im Kapitel Multicast...)
 

Streaming via TCP und http

Wenn von Audio-Streaming die Rede ist, wird meist Streaming via TCP und http gemeint. (Veranschaulichung in der Grafik oben) Allerdings ist das nicht selbstverständlich und es gibt auch die Möglichkeit, via UDP zu streamen; Genaueres dazu im Kapitel '4.4.3 TCP versus UDP'. Folgend wird immer angegeben, wenn ein Unterschied zwischen TCP- und UDP-Streaming besteht. Sofern nicht anders erwähnt, gelten die Beschreibungen für beide Streaming-Arten.

Die nachfolgende Grafik soll veranschaulichen, wie Streaming funktioniert, das TCP als Übertragungsprotokoll benützt. Beispiele hierfür sind die (Http-)Streams von 'Proton – das freie Radio' und '99drei Radio Mittweida'.

Bild:

Bildtext: Abbildung 8: TCP-Streaming erklärt in der Server-Client-Struktur

Erklärungen zu Abbildung 8: Zuerst, 1., fragt der Client den TCP-Stream an (engl.: request); dann 2. schickt der Server die Daten; 3. der Client bestätigt, dass die Daten angekommen sind (engl.: acknowledge; nur in TCP).