Streamen Sie Ihre Firmen-Town-Hall on-premise, ohne sie an einen SaaS zu senden

Wenn 4.000 Mitarbeiter gleichzeitig an derselben all-hands teilnehmen, zahlt irgendjemand an irgendjemanden für diese Bytes. Üblicherweise ist dieser Irgendjemand ein Microsoft Stream-, Zoom Webinar-, Vimeo Enterprise- oder Brightcove-Abonnement. Die Bytes verlassen kurz das Unternehmensnetzwerk, prallen an einem Drittanbieter-Rechenzentrum ab und kommen über eine andere Verbindung in dasselbe Netzwerk zurück. Der CEO sitzt in einem Besprechungsraum zwei Türen weiter, und das Video von ihm geht nach Frankfurt und wieder zurück.

Das funktioniert wunderbar, bis jemand die Frage stellt, auf die es keine gute Antwort gibt. “Warum läuft unser interner town hall-Verkehr über ein Drittanbieter-SaaS?” Compliance fragt das vor einem Audit in einer regulierten Branche. Security fragt nach jeder Vorfallmeldung, in der ein Streaming-Anbieter erwähnt wird. Der CFO fragt, wenn die SaaS-Rechnung pro Zuschauer zur Verlängerung ansteht. Die IT fragt beim ersten Mal, wenn die WAN-Anbindung des Gebäudes zusammenbricht, weil bei der all-hands ein Teilnahmerekord erreicht wurde.

Die ehrliche Antwort lautet: Corporate Live Streaming hat sich rund um RTMP-Encoder und SaaS-Plattformen entwickelt, weil die Alternativen entweder teuer waren (Cisco Enterprise Video, eCDN-Appliances von Kollective und Hive Streaming, interne CDN-Hardware) oder so selbstgebaut, dass niemand in einem typischen IT-Team die Kapazität hatte, sie zu pflegen. Unternehmen entschieden sich für SaaS, weil nichts anderes erreichbar war.

Das hat sich geändert. Encoder, Transcoder, Packager und Publisher sind zu einer einzigen Software auf einem Mac zusammengeschmolzen. Das Ziel muss kein Anbieter mehr sein. Auf einen Webserver hinter Ihrer Firewall gerichtet, erzeugt dieselbe Software broadcast-taugliches HLS, das Ihre Mitarbeiter über das Unternehmens-LAN streamen, und nichts verlässt das Netzwerk.

Genau darum geht es in diesem Artikel.

Wie “internes Corporate Live” tatsächlich aussieht

Die meisten internen Videos in einem typischen Unternehmen lassen sich auf eine kleine Liste wiederkehrender Anwendungsfälle reduzieren.

Quartalsweise all-hands und CEO town halls. Großes Publikum (oft das gesamte Unternehmen), geringe Frequenz (vier bis zwölf Mal im Jahr), moderate Produktionsqualität. Die Latenztoleranz ist großzügig: fünfzehn bis dreißig Sekunden sind in Ordnung, weil es während der Keynote keine wechselseitige Interaktion gibt und Q&A in einem separaten Kanal abgewickelt wird.

Trainingssitzungen und Zertifizierungskurse. Manchmal live, oft mehrfach angesehen. Maximal einige hundert gleichzeitige Zuschauer. Produktion: eine Kamera, ein Vortragender, vom Laptop geteilte Folien.

Produktstarts und Engineering-Ankündigungen. Rein intern, weil die Ankündigung für die Belegschaft bestimmt ist, bevor sie die Presse erreicht. Empfindlich gegenüber Leaks.

Compliance- und HR-Briefings. Jährliche Ethikschulungen, regulatorische Updates, Arbeits- und Gesundheitsschutz. Das Audit-Trail zählt mehr als der Produktionsschliff.

Updates zu Sicherheitsvorfällen. Standardmäßig rein intern, weil der Inhalt aus Vorfalldetails besteht. Muss drinnen bleiben.

In jedem dieser Anwendungsfälle ist das Publikum aus internen Mitarbeitern im Unternehmensnetzwerk oder im Unternehmens-VPN. Die Inhalte sind per Richtlinie intern. Die Bytes an ein SaaS zu schicken, sich vom SaaS bedienen zu lassen, pro Minute zu zahlen und das Legal-Team zu bitten, eine weitere Auftragsverarbeitungsvereinbarung hinzuzufügen, ist der Weg des geringsten Widerstands, nicht die richtige Architektur.

Wie eine On-Premise-Alternative im Jahr 2025 aussieht

Die Architektur ist klein genug, um sie auf einen Klebezettel zu kritzeln.

Ein Mac im Besprechungsraum. Das MacBook des Vortragenden, eine USB-Kamera, die Gebäude-AV-Anlage, die Audio in den Mac einspeist, oder eine beliebige Kombination davon. Apple silicon verfügt über einen Hardware-H.264-, HEVC- und AV1-Encoder, identisch mit dem, den Final Cut Pro für den Export verwendet. 1080p mit 5 Mbps, 720p mit 3 Mbps und 540p mit 1,8 Mbps gleichzeitig in Echtzeit zu encodieren ist genau das, wofür der Chip entwickelt wurde.

Ein Webserver hinter der Firewall. Alles, was HTTPS PUT akzeptiert und Dateien ausliefert. Ein umgewidmeter Fileserver, eine kleine Linux-VM, ein vorhandener interner IIS oder nginx, der bereits Intranet-Inhalte ausliefert. Der Endpunkt empfängt kleine fragmented MP4-Segmente (sechs Sekunden je Stück) und winzige .m3u8-Playlist-Dateien. Der Speicherbedarf ist unbedeutend: eine einstündige Übertragung in drei Qualitätsstufen belegt etwa 4 GB. Der Server transcodiert nicht, er repackagiert nicht, er speichert und liefert lediglich aus.

Ein in die Intranetseite eingebetteter HLS-Player. Jeder moderne HLS-Player funktioniert: hls.js für Browser ohne natives HLS, die eingebaute Unterstützung von Safari, der Apple TV in der Cafeteria, die Display-Systeme im Besprechungsraum, die in den meisten Unternehmen ohnehin laufen.

Das ist die gesamte Architektur. Die Bytes verlassen das Netzwerk nie. Es gibt keinen Streaming-Server, der lizenziert werden muss, keinen Cloud-Transcoder, der abgerechnet wird, keinen eCDN-Agent, der auf jedem Mitarbeiter-Laptop installiert werden muss, kein SaaS-Abonnement. Auf dem Mac läuft My Live TV Channel, das den Stream encodiert und hochlädt. Den Rest erledigt der Webserver, den Sie ohnehin schon haben.

Warum das im Maßstab eines Corporate-LAN funktioniert

Die erste Reaktion von Infrastruktur-Leuten ist meistens: ein einzelner Webserver kann ein town hall-Publikum nicht bedienen. Im öffentlichen Internet trifft diese Intuition zu. In einem Corporate-LAN nicht.

Eine 1080p-HLS-Variante mit 5 Mbps über einen 1 Gbps-Uplink sättigt die Verbindung bei etwa 200 gleichzeitigen Zuschauern (1000 ÷ 5). Derselbe Uplink mit 10 Gbps trägt grob 2.000 gleichzeitige 1080p-Zuschauer. Die 720p-Variante mit 3 Mbps bringt diese Zahlen auf etwa 333 bzw. 3.300. In einer adaptiven Bitrate-Leiter, in der sich Zuschauer auf mehrere Stufen verteilen, landen die meisten Firmen-Laptops auf 720p, sobald die HLS-Adaptionslogik die komfortable Stufe gefunden hat. Die realistische gleichzeitige Kapazität auf einem einzelnen 10 Gbps-Server liegt damit bei mehreren tausend Mitarbeitern.

Wenn Ihr Publikum größer ist, ist der nächste Schritt kein SaaS. Es ist ein zweiter interner Server, oder Ihr vorhandenes internes CDN (die meisten großen Unternehmen verfügen bereits über Caching-Infrastruktur für Software-Updates und Intranet-Inhalte), oder eine einzelne nginx-Caching-Schicht vor dem Upload-Server. Nichts davon erfordert einen Anbieter, und alles davon ist günstiger als eine SaaS-Abrechnung pro Zuschauer.

Wenn das Publikum zu groß für Unicast wird

Die obige Unicast-LAN-Rechnung deckelt bei einigen tausend gleichzeitigen Zuschauern pro Server. Wenn eine globale all-hands 50.000 Mitarbeiter im selben Moment ins Netzwerk desselben Gebäudes bringt, oder wenn Sie an einen stadiongroßen Veranstaltungsort voller Firmen-Laptops streamen, stößt Unicast an eine Wand und das Stapeln weiterer Server wird verschwenderisch.

Die traditionelle Antwort heißt Multicast: eine Kopie jedes Segments wandert zu einer Multicast-Gruppe, jeder Zuschauer abonniert sie, das Netzwerk dupliziert die Pakete an Switches und Routern nach Bedarf. Ein einzelner 5 Mbps-Stream versorgt aus einer Quelle das gesamte Campus, ohne dass die Bandbreite pro Zuschauer multipliziert wird.

In der Praxis ist Multicast in einem Unternehmensnetzwerk eine “Ja, aber”-Situation:

• Es funktioniert nur innerhalb eines multicast-fähigen Netzwerks. In den meisten Unternehmensnetzwerken sind IGMP und PIM aus Sicherheitsgründen standardmäßig deaktiviert. Sie zu aktivieren ist ein Netzwerk-Engineering-Projekt, kein Schalter.
• Es überquert die meisten VPN-Verbindungen nicht. Remote-Mitarbeiter fallen auf Unicast zurück.
• Es überquert WAN-Verbindungen zwischen Standorten nicht ohne explizites MPLS-Multicast oder Vergleichbares.
• Es ist hauptsächlich innerhalb eines Campus oder eines Gebäudes nützlich, in dem die IT die Multicast-Bäume bewusst aufgebaut hat.

Wenn Ihr Netzwerk es unterstützt, lautet der Weg zur Nutzung mit dieser Architektur: Lassen Sie den Encoder-Mac das tun, was er tut (HLS via HTTPS PUT auf den internen Webserver), und fügen Sie nachgelagert einen Multicast-Translator hinzu. Open-Source-Tools wie tsduck und kommerzielle Appliances von Netzwerkanbietern lesen die HLS-Ausgabe, bauen einen MPEG-TS-Multicast-Feed und kündigen ihn via SAP oder SDP an. Endgeräte, die Multicast unterstützen (VLC, Set-Top-Boxen in Besprechungsräumen, Smart-TVs in der Cafeteria), treten der Gruppe bei, statt Unicast-HLS zu ziehen. Endgeräte, die das nicht tun (die meisten Laptops in einem Browser), nutzen weiterhin den Unicast-HLS-Player, der vom selben Webserver ausgeliefert wird. Ein Mac, ein Upload-Ziel und ein einziger Multicast-Translator decken beide Zuschauertypen ab.

Für die meisten Unternehmen ist dieser Abschnitt theoretisch: Unicast bewältigt die all-hands ohne Probleme. Für die wenigen Großunternehmen, in denen er nicht theoretisch ist, lässt sich die Architektur erweitern, ohne den Encoder zu ändern.

Die erstmalige Einrichtung

Der erste Durchlauf dauert etwa einen Nachmittag für ein IT-Team, das noch kein internes Streaming gemacht hat. Die grobe Reihenfolge:

1. Wählen Sie den Ziel-Webserver. Jeder interne Webserver mit HTTPS funktioniert. Konfigurieren Sie ein Verzeichnis wie /intranet-broadcasts/town-hall-2025-q4/ mit aktiviertem HTTPS PUT, ohne Authentifizierung wenn er hinter der Firewall steht, oder mit Basic Auth, wenn Sie das vorziehen. nginx mit dem dav_module schafft das in etwa zehn Zeilen Konfiguration. Apaches mod_dav ist das Äquivalent.

2. Testen Sie den Endpunkt. Von einem beliebigen internen Rechner aus sollte curl -X PUT https://intranet.corp/intranet-broadcasts/test/index.m3u8 --data "test" einen 201 zurückgeben. Wenn ja, ist das Ziel bereit.

3. Konfigurieren Sie My Live TV Channel auf dem Mac des Vortragenden. Fügen Sie ein HTTP PUT-Ziel hinzu, das auf das Verzeichnis zeigt. Speichern. Verbindung testen. Erstellen Sie ein Stream Profile mit der gewünschten Bitrate-Leiter.

4. Betten Sie einen HLS-Player auf der Intranetseite ein. Ein <video controls>-Tag, das auf die Wiedergabe-URL zeigt, reicht in Safari aus. Für Chrome und Edge fügen Sie hls.js ein (ein Script-Tag, eine Zeile JavaScript). Der gesamte Player umfasst weniger als dreißig Zeilen HTML.

5. Probelauf mit dem Technik-Team. Streamen Sie zehn Minuten lang vom Mac. Lassen Sie ein paar interne Zuschauer einschalten. Beobachten Sie das Dashboard. Bestätigen Sie, dass die Segmente auf dem Zielserver erscheinen, dass der Player sie abholt und dass die Latenz akzeptabel ist.

Das ist die gesamte Einrichtung. Folgende Übertragungen verwenden dasselbe Ziel, dasselbe Profil und dasselbe Player-Embed wieder.

Was ist mit Q&A, Umfragen und dem Rest

Die obige Architektur kümmert sich um die Übertragung, nicht um die interaktive Schicht. Für Q&A, Umfragen und Reaktionen während des town hall haben interne Unternehmen typischerweise bereits einen Slack- oder Microsoft Teams-Kanal, der seinen Zweck einwandfrei erfüllt, mit Subsekunden-Latenz über dasselbe interne Netzwerk läuft und sich in das Verzeichnis integriert, das der Rest des Unternehmens nutzt. Der Versuch, ein Streaming-SaaS gleichzeitig zum Chat-Tool zu machen, ist genau das, was diese Produkte teuer macht. Übertragung und Interaktion in die Tools aufzuteilen, die Ihr Unternehmen bereits betreibt, ist genau das, was die Architektur günstig macht.

Wenn Sie einen 24/7-Informationskanal intern wünschen (“CorpTV”), füllt die Playout-App My TV Channel die Zeit zwischen Live-Übertragungen mit geplanten Inhalten (Archive aufgezeichneter all-hands, Trainingsvideos, interne Nachrichten, Manager-Updates). Derselbe Zielserver, dasselbe Player-Embed. Mitarbeiter, die an einem Dienstagnachmittag auf der Kanal-Seite landen, finden etwas Laufendes vor anstelle eines “Stream offline”-Bildschirms.

Was Ihr Problem bleibt

Internes Video selbst zu hosten hat Kompromisse, über die ehrlich zu sprechen sich lohnt.

Aufzeichnung und Aufbewahrung. Der Zielserver bewahrt jede Übertragung unbegrenzt auf, sofern Sie keinen Bereinigungsjob einrichten. Das ist gut für Archive und schlecht für den Speicher, wenn Sie es vergessen. Die meisten Unternehmen wünschen sich eine Aufbewahrungsrichtlinie für interne Übertragungen (typischerweise an regulatorischen oder rechtlichen Vorgaben ausgerichtet). Einmal in cron einrichten und vergessen.

Untertitel und Barrierefreiheit. Live-Untertitelung ist nicht in die Encoder-App eingebaut, und das stellt sich als geringeres Problem heraus, als es klingt. Moderne Browser und Betriebssysteme erzeugen Live-Untertitel auf der Client-Seite, auf dem Gerät, ohne Beteiligung des Servers: Chromes Live Caption-Funktion arbeitet bei jedem im Browser laufenden Video, macOS Live Captions tut systemweit dasselbe in Safari, Edge hat sein eigenes Pendant. Jeder Zuschauer schaltet die Untertitel im eigenen Browser ein oder aus. Wenn Sie aus Compliance-Gründen serverseitige Untertitelung benötigen (die Untertitel müssen Teil der Aufzeichnung sein, oder Sie können sich nicht auf den Browser des Zuschauers verlassen), leiten Sie das Audio durch einen Untertitelungsdienst (Microsofts integrierte Untertitel, AWS Transcribe, interne Werkzeuge) und blenden Sie die Untertitel im Player ein. Die HLS-Schicht ändert sich in keinem der beiden Fälle.

Authentifizierung. Hinter der Firewall ist “jeder im Corporate-Netzwerk darf zusehen” oft akzeptabel. Wenn Sie stärkere Garantien benötigen (Vorstandsbriefings, M&A-Ankündigungen), stellen Sie die Wiedergabe-URL hinter Ihre vorhandene SSO- oder VPN-Postureprüfung. Standard-Web-Authentifizierung, nicht videospezifisch.

Standorte über mehrere Regionen hinweg. Wenn Sie Standorte auf mehreren Kontinenten haben, die an einer einzelnen Übertragung teilnehmen, möchten Sie entweder einen regionalen Cache-Server in jeder Region, oder eine bewusste Entscheidung, das Corporate-WAN zu nutzen. WANs sind typischerweise rate-limitiert, sodass die obige LAN-Rechnung nicht gilt. Planen Sie entsprechend.

Das ehrliche Fazit

Die Kostenfrage lässt sich am leichtesten überzeichnen. SaaS-Rechnungen für internes Streaming existieren, sind aber selten allein ausschlaggebend. Der ausschlaggebende Faktor für die meisten Unternehmen, die zu einer On-Premise-Architektur wechseln, ist: internes Video sollte intern bleiben. Die Stimme des CEO, die Engineering-Ankündigung, das M&A-Briefing, die Nachbesprechung des Sicherheitsvorfalls, die Compliance-Schulung: keines davon muss das Unternehmensnetzwerk verlassen, um an das Corporate-Publikum ausgeliefert zu werden, das in eben diesem Netzwerk sitzt. Sobald das der Rahmen ist, wird “wir senden eine Kopie durch das Rechenzentrum eines Anbieters und zahlen für die Rundreise” zu dem Teil, der gerechtfertigt werden muss, nicht die On-Premise-Alternative.

Compliance-Teams stellen in regulierten Branchen dieselbe Frage: welche Drittparteien haben Zugriff auf Aufzeichnungen interner Mitarbeiterbesprechungen? Security-Teams stellen sie nach jeder Vorfallmeldung, in der ein Streaming-Anbieter erwähnt wird. Datenresidenz-Vorgaben in einigen Regionen stellen sie, bevor die Übertragung überhaupt stattfindet. Eine Architektur, in der die Bytes das Netzwerk nie verlassen, beseitigt die Frage.

Wenn Sie diese Bedenken haben und Ihr IT-Team es leid ist, auf jedem Laptop den eCDN-Agent eines weiteren Anbieters bereitzustellen, ist die praktische Antwort inzwischen klein genug, um sie an einem Nachmittag aufzubauen. Ein Mac im Besprechungsraum, ein Webserver, den Sie ohnehin schon haben, und eine App, die Sie eine Woche kostenlos testen können. Das Architekturdiagramm passt auf einen Klebezettel. Die Anzahl der Anbieter mit Zugriff auf die Stimme Ihres CEO sinkt von “mehrere” auf “null”.

My Live TV Channel 7 Tage kostenlos im Mac App Store testen →