Videoserver im Internet - wie groß ist die maximale Zuschaueranzahl?

[bullgard]

Hallo debianforum.de,
Ein Videoserver sendet auf der letzten Meile einen Videostrom zum Internet mit einer bestimmten Bitrate B1. Sein Internetprovider sichert ihm eine Mindestbitrate Bi zu. (Zugegen ein nicht oft auftretnder Bezahlfall.)
1. Wieviele Clients können den Videostrom vollständig empfangen (x)?
2. Wenn die Anzahl a der Clients die Zahl x überschreitet, können x den Videostrom vollständig empfangen, und der Rest a-x nur unvollständig bzw gar nicht. Nach welchen Kriterien trennt das Internet den Rest ab?
MfG
bullgard

[unitra]

Das hängt alles davon ab wie die "Leitung" beschaffen ist. So Etwas steht in den Verträgen. Diese Frage kann nur der ber Dienstleister beantworten der diese Leitung zur Verfügung stellt und "betreibt". Frage mal bei der Firma, rufe mal beim Support an und frage nach und schaue in den Vetrag. Das für den Anschluß vor Ort.

Und im Internet dagegen gilt immer, "best effort". Also das was zuerst ankommt wird auch zuerst bearbeitet.

[wanne]

"Das Internet" ist keine regulierte Organisation. Und "Ein Videoserver" keine vernünftige Definition. Das Zusammenspiel von Client und Server ist relevant.

Erstmal ist das Internetprotokl unreliable. Wenn also 2 Leute dumm mit 3MBit/s von einer 5MBit/s Leitung runter Laden (passiert in der Realität nicht. Später mehr.) Dann wird im besten Fall halt jedes 6. Paket weggeworfen. Und zwar mehr oder minder zufällige. Sprich: Überall fehlen wild Teile und mit dem Datenmüll kann keiner was anfangen. Wenn man sich ganz dumm anstellt passiert das dauernd:
Dein Rechner hängt an einem 1GiB-LAN-Kabel aber eher selten an einem genau so fetten Ineternet Anschluss. Wenn dein Videoaerver dumm mit 1GiB sendet, weil das seine Leitung ist aber die Inernet-Leitung kommt nur jeder Zehnte Teil an.
Ganz am Anfang, in den 70ern als die ersten Versuche mit Internet-Protokollen losgingen kam man erst mal auf die geniale Idee. OK. Habe ich 1/10. Versuche ich es mit den anderen 9/10 nochmal. Dann hat man 19%... Nach 50 versuchen hat man 99.5% und irgend wann hat man Glück und alles kommt durch.
So lange das einer macht, funktioniert das noch ganz gut. Aber ziemlich schnell ging das mit Totalzusammenbrüchen los: Je mehr Leute unterwegs waren desto weniger kam an, desto mehr versuchten es erneut...
Dann kam tcp. In seiner primitivsten Form und stark vereinfacht weist die eine Seite die jeweils andere an, den ersten Teil erst mal ganz langsam zu senden. Kommt alles an kommt die Anweisung, dass der Nächste Teil etwas schneller gesendet werden soll. So erreicht langsam das Maximum. Wird es Überschriten kommt ein Teil nicht an und die Geschwindigkeit wird halbiert. Kommt nicht mal mehr die Antwort, dass nicht alles angekommen ist, wird wieder bei Geschwindigkeit 0 angefangen. Da die Router zufällig wegwerfen bekommt so mehr oder weniger zufällig immer ein anderer eins auf den Deckel und halbiert die Geschwindigket und auf die Dauer bekommt jeder Download gleiche Anteile der Leitung und das System regelt sich selbst. Je mehr laden desto öfter wird die Bandbeite überschritten, desto öfter bekommt einer auf den Deckel und jeder bekommt kleinere Bandbeite...
So funktionieren bis heute praktisch alle Downloads. Man kann das schön beobachten. Am Anfang geht die Geschwindigkeit hoch und dann gibt es immer wieder einbrüche. Auch der Flash-Player (mit RTMP) und klassisches HTML5-Video (mit http) im Chrome/Firefox arbeiten so. (Safari und Konquerer können intelligenter sein.)
Vorteil (speziell für Video): Da die ersten Teile schon angucken bevor man den letzten Teil runter geladen hat. Man nennt dass dann progressiver download.
Nachteil: Da es am Anfang langsam ist braucht es zum anlaufen. Daneben verursachen die Einbrüche Ruckler. Gelöst wird das durch puffern: Es werden absichtlich große Teile geladen bevor man erst mit abspielen anfängt (und so lange steht das Video) die dann abgespielt werden, wenn der Download gerade mal langsamer als die Abspielgeschwindigkeit ist.
Nachteil2: Läuft immer nahe am Limit. Hat man einen 125MiB großen Film verstopft der für ne Sekunde die Volle Gigabit-Leitung. – Insbesondere auch wenn man nur 5s rein guckt und dann wieder abdreht.

In den 90er und 00ern gab es noch eine alternative Idee: Nur wirklich essentielle Daten werden derartig herunter geladen. Das Video selbst, wird genau mit der Geschwindigkeit, wie man es abspielt gesendet und ist so encodiert, dass ein fehlender Teil ausgemerzt werden kann, indem man die Daten von vorherigen Bildern und benachbarten Teilen des Bilds ersetzt. – Es entstehen kurz Blöcke im Bild. Bevor Netflix (das anders funktioneirt) den Begriff besetzte, wurde das Streaming genannt. Der VLC-Player und dessen Plugin konnten das. Das Protokoll, dass das kann (aber nicht so genutzt werden muss) ist meist RTP Der Ansatz ist aber extrem kompliziert und wird defakto nicht mehr weiterverfolgt.

In beiden Fällen ist die Annahme, dass die Internetleitung zumindest im Schnitt mindestens so schnell, ist wie alle Videos, die darüber abgespielt werden wollen. Andernfalls kollabieren die Systeme. (Im ersten Fall indem das Video die ganze zeit stehen bleibt, im Zweiten indem es unkenntlich wird.) Gerade zu der Zeit war das defakto immer der Fall. (Dazu später mehr.*) – Und wenn nicht, wurde das abspielen halt irgend wann durch den Nutzer beendet...

Mit den billigeren Internettarifen und der damit einhergehenden größer Verfügbarkeit von HD-Inhalten insbesondere bei youtube änderte sich das plötzlich. Es kam adaptives Streaming. (Das ist dann das, was Netflix und Co verwenden.)
Das baut wieder auf den progressiven progressiver downloads über tcp auf.
Mit einem kleinen Unterschied: Merkt das Abspielprogramm, dass der Download zu lange zeit unter die Abspielgeschwindigkeit fällt und der Puffer kleiner wird, reduziert für zukünftige Teile automatisch die Bildqualität. So wird wieder dafür gesorgt, dass auf die verfügbare Bandbreite größer als das benötigte ist und es keine oder seltener Hänger gibt. Daneben werden die nächsten paar Teile erst herunter geladen, wenn der Puffer zu klein ist/wird. Safari kann das via HLS. Chrome per MSE.

tcp, Gerechtigkeit und Auslastung
Du merkst, dass all diese Sachen darauf, setzen dass die Nutzer vernünftig sind und auf die ein oder andere Weise automatisch ihre Banbreite Reduzieren, wenn Pakete abhanden kommen oder zumindest nicht Bösartig massiv ihre Bandbreite über die des Bottlenecks erhöhen.
Zuerst mal: Warum war das so, dass Internetleitungen n den 90er und 00ern schneller als die Gestreamten Videos waren: Internetzugang gab es vor allem durch 2 Technologieen: DSL/ISDN/Analogmodems, die eigene Leitungen für jeden Zugang hatten. die viel langsamer als die dahinter liegende Infrastruktur waren und Kabel, wo die Kabelanbieter absichtlich kleinere Tarife verkauften als technisch möglich gewesen wäre und hart anfingen Pakete von Anschlüssen wegzuwerfen, die mehr nutzten. (Man nennt das Traffic shaping.) Bei einem Kollaps brach nur der eigene Stream und eventuell, der Mitbwohner zuammen. – Im Notfall kann man das also per Boxkampf mit dem Bruder ausmachen, was jetzt abgeschaltet wird, damit der Rest läuft. Unbekannte wurden nie beeinflusst, weil aus dem DSL nur so wenig Daten raus vielen, dass das andere Leitungen nie überlastete.
Mit der größeren Verfügbarkeit von Glasfaser-Anschlüssen ändert sich das wieder. (So wie das in den 80ern der Fall war.)

Warum funktioniert(e) das trotzdem?
Keiner hat einen Benefit von einem Zusammenbrechenden Internet. Und ausreichend fette Anschlüsse um wirklich Überlastungen abseits des Hausnetzes zu erzeugen sind teuer. Dass es zum Massenphämomen wird tausende Euro auszugeben um den Internet zu schaden ist unwarscheilich. Daneben korrigieren Internetanbieter und Nutzer eventuell nach, und routen über andere Teile des Internets wenn gewisse Teile notorisch überlastet sind. Das also große Massen an Leuten extrem viel Geld investieren, nur um absichtlich etwas kaputt zu machen, dass man einfach wieder reparieren kann, indem man ihm halt das Kabel Kappt, ist sehr Unwahrscheinlich. Daneben kann man bösartig kaputt machen primitiver auch mit Störsendern. (Ja. Die wirken nicht nur gegen Wifi sondern auch gegen DSL und Mobilfunk.)
Deswegen ist praktisch zu jeder Zeit der größte Teil des Intenet-Verkehrs über das 1981 spezifizierte tcp gelaufen, indem die Nutzer freiwillig das Internet vor dem Kollaps schützen.

Es gibt trotzdem ein paar Flaws Verbesserungsmöglichkeiten:

• tcp verteilt die Bandbreite gerecht über alle Downloads. Torrent downloadet aber von vielen Stellen Gleichzeitig. Hast du 99 Seeder bekommt dein torrent 99% der Bandbreite und der andere Download 1%. Deswegen wurde µTP erfunden: Es reduziert die Bandbreite schneller als normales tcp. Sodass es sozusagen im Hintergrund läuft und nur sehr kleine Bandbreiten frisst, solange andere "dringendere" Sachen wie Videostreaming anstehen. Die Playstation nutzt für ihre Spieledownloads einen ähnlichen Mechanismus.
• Das langsame erhöhen der Banbreite bis zum Maximum um sie dann beim Maximum drastisch zu reduzieren lässt natürlich viel Bandbreite ungenutzt. (Je mehr gleichzeitige Nutzer desto bessere Effizienz, aber gut wird die insbesondere bei schellen Wifis nie ) Linux implementiert deswegen eine effizientere Methode qubic, die am Anfang bei einem sinnvollen Schätzwert aus der Vergangenheit anfängt zuerst schnell hoch fährt und dann immer langsamer wird, wenn man sich dem vermuteten Maximum nähert, bzw dieses überschreiten. Dies verhält sich "neutral" zu klassischem tcp es bekommt zwar etwas mehr Bandbreite aus der Leitung holt sich die aber wirklich nur aus den ungenutzten Reserven. Alte tcps laufen genau so schnell/lahm, wie wenn man ein klassisches TCP daneben setzt.
• Google ist jetzt eine Nummer weiter gegangen: QUIC das jetzt von Chromium für youtube genutzt wird reduziert auch langsamer. Dies ist noch effizienter und schützt das Internet auch vor Überlastung. Ist also prinzipiell nicht gänzlich böse. Hat aber das Problem, dass es mit dem Verhalten andere TCP-Verbindungen abwürgt. Währen QUIC immer nahe am Maximum der Leitung bleibt, reduziert TCP schnell um das Internet zu schützen und landet so bei einem Bruchteil der QUIC Bandbreite.
• Auch RTP hat defakto in die Kerbe geschlagen: Die konstante Übertragungsrate hat dazu geführt das die restlichen TCP Verbindungen halt den Rest der Leitung bekommen. Das kann ein Vorteil sein, weil es im Gegensatz zu progressiven Downloads nicht unnötig mehr Bandbeite verbraucht, als der Videostream groß ist. Auf der anderen Seite teilen sich dann halt 5 TCP die letzten 20% der Leitung, wenn das RTP meint, 80% einnehmen zu müssen. Gerecht ist anders...
• S3 (und damit oft auch die Video-Downloads) läuft immer häufiger mit mehreren tcp-Streams um die Bandbreite effizienter auszunutzen.
• Moderne DDOS-Attacken funktionieren manchmal so, dass man einfach absichtlich nicht runter schaltet und mit Vollgas sendet und so alle anderen Mitnutzer der Internetleitung platt drückt.

All diese Varianten sind noch mit guter Absicht gewesen. Aber man sieht hier sehr deutlich, dass man andere TCP-Nutzer zu seinen eigenen Gunsten benachteiligen kann. Und natürlich nutzen das Leute aus. Bis jetzt blieb die Anzahl ausreichend klein, dass das nie ein Problem wurde. Insbesondere nicht fürs gesamte Internet, das ein Problem bekommen würde, wenn es üblicher würde, bösartige alternativen zu nutzen.
Aber eigentlich wundert mich schon lange, dass das nicht ein massives Problem wird dass Leute aus Egoismus Protokolle die ihnen nutzen aber allen schaden nutzen.

[debilian]

Meine Erfahrung ist, dass eine 1 GBit/s Leitung sehr viel abdecken kann, als Beispiel:

https://www.rtr.at/TKP/service/rtr-nett ... th.de.html

würde z.B. heissen bei 720p a 5 MBit/s Download gleich 200 User gleichzeitig...

gruss

[uname]

Sein Internetprovider sichert ihm eine Mindestbitrate Bi zu

Was ist hier der Internetprovider? Meinst du damit sowas wie einen DSL- oder Glasfaseranschluss zuhause?

Normalerweise ist es bei vielen schauenden Teilnehmern so, dass der Absender den Videostream ins Internet streamt (z. B. Youtube oder Twitch) und dann alle direkt im Backbone zuschauen. Nennt sich teilweise auch CDN (Content Delivery Network). Alternative Anbieter sind z. B. https://vimeo.com .

Was ist denn überhaupt dein Ziel?

[wanne]

Meine Erfahrung ist, dass eine 1 GBit/s Leitung sehr viel abdecken kann, als Beispiel:

https://www.rtr.at/TKP/service/rtr-nett ... th.de.html

Ja. Wobei die 25MBit/s für 4k schon massiv übertrieben sind. Ich sehe da real insbesondere bei Amazon eher so 15MBit/s. Die wollen halt auch auf Nr Sicher gehen.
Ähnliches gilt für die 0.1MBit/s von Skype. Für Mumble oder Teamspeak reicht oft schon weniger als die Hälfte, wenn man auf "Sprache" stellt. Ich tippe das ist bei Skype nicht anders.

Normalerweise ist es bei vielen schauenden Teilnehmern so, dass der Absender den Videostream ins Internet streamt (z. B. Youtube oder Twitch) und dann alle direkt im Backbone zuschauen.

Die Erklärung stiftet mehr Verwirrung als Aufklärung. Vor allem weil sie wild viele Marketing-Begriffe ohne vernünftige Definition benutzen:
CDN heißt lediglich, dass das Video an vielen unterschiedlichen Stellen abrufbar ist. Üblicherweise mindestens für jede größere Region (Kontinent) von wo anders. Ab einer gewissen Größe macht es Sinn, nicht nur ein fettes Rechenzentrum zu bauen. – Ähnlich wie Aldi nicht nur riesige eine Filiale hat. Die Technik bleibt exakt die selbe.

und dann alle direkt im Backbone zuschauen.

Backbone werden Leitungen bezeichnet die strategisch besonders wichtig sind. Es gibt aber natürlich keine formale Definition für "wichtig". Sie zeichnen sich üblicherweise darüber aus dass sie viel Bandbreite und eben eher keine "Endkundenabschlüsse" haben. Wenn du ein Fetter Streaming-Anbieter bist, ist natürlich sinnvoll an möglichst fetten Leitungen zu hängen. Unwahrscheinlich ist, dass der youtube-Nutzer erst mal zu einer solche fährt.

dass der Absender den Videostream ins Internet streamt

Nicht erst mal. Sobald du einen Internet-Anschluss hast, bist du vollstänig gleichberechtigter Teil vom Internet. Entsprechend wird immer "ins Internet" gestreamt. Und zwar im Fall von Youtube oder twitch direkt für jeden Nutzer Einzeln. Nix ein mal senden X mal empfangen.
Es gibt ein paar Spezialfälle wie T-Home-Entertain im Telekom-Netz oder Kabelfernsehn im Kabelnetz. Aber im Normalfall blockieren alle Internetanbieter solche Protokolle für Fremdkunden weshalb das für die großen nicht in Frage kommt.

[debilian]

Ja. Wobei die 25MBit/s für 4k schon massiv übertrieben sind. Ich sehe da real insbesondere bei Amazon eher so 15MBit/s. Die wollen halt auch auf Nr Sicher gehen.

vollkommen richtig, es müssen ja auch erstmal 200 User gleichzeitig gucken...
der Fragende schreibt ja nicht, was er denn eigentlich erreichen möchte.

gruss

[unitra]

Es gibt da noch "Multicast" als eventuelle Lösung um sehr viel IP Traffic zu sparen.

[MSfree]

Es gibt da noch "Multicast" als eventuelle Lösung um sehr viel IP Traffic zu sparen.

Wie geeignet ist Multicast, um z.B. Videoportale wie Netflix und diverse Mediatheken zu bedienen?

Wenn sich Zuschauer ganz individuell einen Film ansehen wollen, dürfte Multicast ausscheiden, zumal ja auch die allgegewärtige Verschlüsselung via HTTPS Multicast unmöglich machen dürfte. Das klappt nur, wenn man einen unverschlüsselten "Sender" betreibt, der einen Livestream rausschickt, auf den sich dann viele Zuschauer aufschalten können.

[uname]

Vielleicht ist PeerTube noch ein Blick wert. Kann angeblich auch Live Streaming.

[wanne]

Wenn sich Zuschauer ganz individuell einen Film ansehen wollen, dürfte Multicast ausscheiden, zumal ja auch die allgegewärtige Verschlüsselung via HTTPS Multicast unmöglich machen dürfte. Das klappt nur, wenn man einen unverschlüsselten "Sender" betreibt, der einen Livestream rausschickt, auf den sich dann viele Zuschauer aufschalten können.

Schon tcp und damit http machen multicast unmöglich. Wie gesagt: Der Empfänger weist den Sender ja an, die Geschwindigkeit einzuhalten, die für seinen Internetanschluss passt. Du kannst aber Multicast nicht für jeden individuell in unterschiedlicher Geschwindigkeit machen.
Multicast funktioniert nur mit RTP. Wie gesagt: T-Home-Entertain macht das (oder hat das). Es wird gemunkelt, das Kabelanbieter das auch was am Start haben. (Aber nicht auf der letzten Meile.)
Wie gesagt: Multicast ist bei allen Anbietern für Fremdanbieter gesperrt.

[unitra]

Der TE hat eine ganz konkrete Frage gestellt, da is weder von einer Mediathek noch von einem VIdeoportal die Rede. Und "individuell Fim anschauen" habe ich auch nicht entdeckt im ersten Post.

Und zu deiner Frage: Das ist richtig. Multicast ist da völlig ungeeignet. Das aber, hat mit der initialen Fragestellung nicht mehr zu tun.

Es gibt da noch "Multicast" als eventuelle Lösung um sehr viel IP Traffic zu sparen.

Wie geeignet ist Multicast, um z.B. Videoportale wie Netflix und diverse Mediatheken zu bedienen?

Wenn sich Zuschauer ganz individuell einen Film ansehen wollen, dürfte Multicast ausscheiden, zumal ja auch die allgegewärtige Verschlüsselung via HTTPS Multicast unmöglich machen dürfte. Das klappt nur, wenn man einen unverschlüsselten "Sender" betreibt, der einen Livestream rausschickt, auf den sich dann viele Zuschauer aufschalten können.