Anforderungen

Referenzgerät

Castmux wird auf einer bewusst bescheidenen Maschine entwickelt und vermessen, denn so etwas passt in einen Technikschrank und läuft jahrelang unbeaufsichtigt:

Komponente	Referenzspezifikation
CPU	4 Kerne, arm64 oder x86-64
Arbeitsspeicher	6 GB
Kühlung	Lüfterlos
Datenträger	Beliebig; im Normalbetrieb gibt es außer dem Logging keine Festplattenaktivität
Netzwerk	Mindestens eine Schnittstelle, zwei empfohlen

Es wird nichts transkodiert, daher gibt es keine GPU-Anforderung und auch keinen Nutzen durch eine GPU. Für alle, die Hardware spezifizieren, ist das Fehlen dauerhafter Schreibzugriffe erwähnenswert: Ein Gerät mit industriellem Flash-Speicher wird durch diese Last nicht verschlissen.

Kosten pro Sender

Die beiden Engines verursachen deutlich unterschiedliche Kosten, und die Wahl der Engine verändert die Kapazität der Box etwa um den Faktor 1,5. Gemessen pro Sender:

Messgröße	Remux-Engine	Pass-through-Engine
Kaltstart (Beitritt → erstes Paket)	~4.4 s	~1.9 s
Volle 1316-Byte-Datagramme	85%	100%
CPU pro Sender	~5 % eines Kerns	~15 % eines Kerns
RAM pro Sender	~72 MB	~23 MB
Sender auf einer 2-GB-Box	~16	25+

Die Kosten verlaufen gegenläufig, und genau deshalb gibt es beide Engines. Die Pass-through-Engine ist sparsam beim Speicher und teuer bei der CPU; bei der Remux-Engine ist es umgekehrt. Auf dem Referenzgerät geht der Remux-Engine daher zuerst der Speicher aus und der Pass-through-Engine zuerst die CPU — vier Kerne zu je 15 % ergeben etwas mehr als 26 Sender, daher stammt der Wert „25+“.

Die Remux-Engine lässt sich trotz höherer Kosten pro Sender nicht abschaffen. Die Pass-through-Engine kann nicht mit Nullpaketen auf konstante Bitrate auffüllen, und ihr HLS-Eingang liest nur MPEG-TS-Segmente, kein fMP4/CMAF — ein moderner CMAF-Ursprungsserver oder ein nachgelagertes Gerät, das auf CBR besteht, braucht also die Remux-Engine. Wie Sie wählen, steht unter Streaming-Engines.

Kapazitätsplanung

Speicher ist eine Klippe, kein Gefälle. Das ist die wichtigste Aussage auf dieser Seite. Geht die CPU zur Neige, verschlechtert sich das Verhalten allmählich — Streams ruckeln, Sie bemerken es, Sie verringern die Last. Geht der Speicher zur Neige, gibt es keine allmähliche Verschlechterung: Der Kernel wählt einen Prozess aus und beendet ihn, und meist trifft es einen gesunden Sender, der mit dem Problem nichts zu tun hatte. Zwischen „alles in Ordnung“ und „ein Sender ist gerade verschwunden“ gibt es keinen Warnbereich.

Testen Sie die Kapazität nicht, indem Sie die Last bis zum Ausfall steigern

Zwanzig Sender auf der Remux-Engine haben beim Testen eine 2-GB-Box per OOM-Killer lahmgelegt. Nichts hat vorher gewarnt; die Box trug neunzehn Sender scheinbar mühelos, und der zwanzigste nahm einen davon vom Netz. Die Last bis zum Ausfall zu steigern findet nicht die Grenze, sondern eine Zahl, die einen Sender darüber liegt — und zwar, indem ein funktionierendes System zu Fall gebracht wird.

Messen Sie die Resident Set Size pro Sender mit Ihren eigenen Quellen, führen Sie die folgende Rechnung durch, und hören Sie dort auf.

Die Rechnung

Drei Schritte:

1. Nutzbarer Speicher = Gesamtspeicher − ~300 MB. Diese Reserve deckt Betriebssystem, Container-Laufzeit und den Castmux-Prozess selbst ab, die alle keine Kosten pro Sender sind.
2. Rohe Senderanzahl = nutzbarer Speicher ÷ RSS pro Sender für die gewählte Engine.
3. Lassen Sie 15 % Reserve. Der RSS pro Sender schwankt mit der Quell-Bitrate und verändert sich bei Aussetzern und Neuverbindungen des Ursprungsservers; die letzten 15 % fangen das ab.

Durchgerechnet für ein 2-GB-Gerät mit der Remux-Engine:

# usable memory
2048 MB - 300 MB = 1748 MB

# raw count at ~72 MB per channel
1748 / 72 = 24 channels

# minus 15% headroom
24 x 0.85 = 20 channels

Die Rechnung landet bei zwanzig — und zwanzig ist genau die Zahl, bei der eine echte Box dem OOM-Killer zum Opfer fiel. Der gemessene sichere Wert liegt bei ~16. Widersprechen sich Rechnung und Messung, glauben Sie der Messung: Der RSS pro Sender in der Tabelle ist ein Durchschnitt im eingeschwungenen Zustand, und nicht alle Sender liegen gleichzeitig auf ihrem Durchschnitt.

Verstehen Sie die Rechnung als Mittel, offensichtlich undurchführbare Pläne auszuschließen, nicht als Erlaubnis, bis an das Ergebnis heranzugehen.

CPU-Reserve

Bei der Pass-through-Engine führen Sie dieselbe Division mit den Kernen statt mit dem Speicher durch: Vier Kerne sind 400 Prozentpunkte CPU, bei etwa 15 pro Sender. Lassen Sie dieselben 15 % Reserve, und mehr, wenn die Box zusätzlich einen DVB-C-Modulator ansteuert oder gleichzeitig Vorschauen an mehrere Browser ausliefert.

Netzwerk

Schnittstellen

Castmux läuft mit einer einzigen Netzwerkschnittstelle, und für eine kleine Installation ist das eine völlig vernünftige Wahl. Zwei Schnittstellen — eine für das Management, eine zu den Fernsehern — sind vorzuziehen, und zwar aus Diagnosegründen, nicht wegen des Durchsatzes.

Teilen sich Management und Multicast eine Verbindung, wird jeder Fehler mehrdeutig. Ein ausgelasteter Uplink macht die Weboberfläche unbedienbar, sodass genau das Werkzeug, mit dem Sie das Problem diagnostizieren würden, vom Problem lahmgelegt ist. Getrennt bleibt die Management-Schnittstelle erreichbar, während Sie herausfinden, was mit der anderen nicht stimmt, und die Verkehrswerte in der Fußzeile lassen sich zuordnen: Eine Schnittstelle sollte eine gleichmäßige Multicast-Rate zeigen, die andere fast nichts.

Layer 2 und Routing

Die Fernseher müssen im selben Layer-2-Segment liegen wie das Gerät. Multicast überquert standardmäßig keinen Router; dafür wären PIM auf den dazwischenliegenden Routern und durchgängig einheitlich konfiguriertes IGMP-Snooping auf dem Pfad nötig — eine Aufgabe der Netzwerktechnik, die über den Rahmen dieses Produkts hinausgeht.

Auf dem Gerät selbst muss 224.0.0.0/4 auf die Schnittstelle zeigen, die zu den Fernsehern führt. Das wird ausführlich unter Installation → Multicast-Routing behandelt, und es lohnt sich, das vor der Hardwarebestellung zu lesen, denn diese Anforderung wird meist als letzte entdeckt.

Uplink und gestaffelter Start

Der Uplink, über den die Quellstreams kommen, muss die Summe aller Sender-Bitraten mit Reserve tragen. Die Reserve ist wichtiger als der Durchschnitt, und zwar wegen dessen, was beim Start passiert.

Beim Start von Castmux wollen alle dauerhaft eingeschalteten Sender gleichzeitig loslegen. Jeder baut eine Verbindung zu seinem Ursprungsserver auf und lädt Segmente so schnell, wie der Ursprungsserver sie ausliefert, um seinen Puffer zu füllen. Tun das acht Sender gleichzeitig an einem 100-Mbit-Uplink, bekommt nicht jeder ein Achtel der Leitung und startet langsam — sie laufen alle in ein Timeout, scheitern alle und versuchen es alle erneut, was denselben Ansturm wieder erzeugt.

Castmux staffelt die Senderstarts deshalb, standardmäßig mit 3 Sekunden Abstand. Der Preis: Ein vollständiger Neustart von zwanzig Sendern dauert etwa eine Minute. Der Gewinn: Er kommt überhaupt zum Abschluss. Verkürzen Sie den Abstand nicht, damit Neustarts schneller wirken; an einem knappen Uplink ist genau das die Änderung, die den Fehler zurückbringt.

DVB-C-Hardware

Nur erforderlich, wenn Sie HF-Ausgabe ins Koaxialnetz wünschen. Zwei Dinge werden benötigt:

• Ein freier PCIe-Steckplatz. Das schließt die meisten kompakten lüfterlosen Boxen aus und ist der übliche Grund, warum eine DVB-C-Installation ein anderes Gehäuse braucht als eine reine IP-Installation.
• Eine unterstützte DVB-C-Modulatorkarte. Die DVB-C-Ausgabe wurde mit TBS-Karten entwickelt und vermessen; die Referenzhardware ist die TBS 5862.

Für eine reine IP-Installation ist nichts davon relevant. Unterstützte Karten und Konfiguration finden Sie unter DVB-C-Multiplexing.

Software

Ein Linux-Host mit Container-Laufzeit. Castmux wird als castmux/castmux:latest ausgeliefert und ist ein einzelner Go-Prozess im Image.

Das Image basiert auf Debian trixie. Das ist keine Willkür: Die Engines brauchen aktuelle Versionen von FFmpeg und TSDuck, und ältere Debian-Versionen deckeln beide auf Versionen mit bekannten Einschränkungen. Alpine kommt nicht in Frage — für musl gibt es kein TSDuck-Paket, die Pass-through-Engine lässt sich dort also schlicht nicht bauen. Wenn Sie Images in Alpine-Größe gewohnt sind: Dieses ist größer, und das ist der Grund.

Die Distribution des Hosts spielt keine Rolle; sie muss lediglich den Container mit Host-Networking und den beiden unter Installation beschriebenen Capabilities ausführen können.

Internetzugang

Das Gerät braucht ausgehenden Internetzugang, um zu streamen. Jedes Gerät prüft seine Lizenz beim Castmux-Lizenzserver. Bis die erste Anmeldung erfolgreich war und das Gerät freigegeben wurde, streamt es überhaupt nicht. Das gilt auch dann, wenn sämtliche Quellen im lokalen Netz liegen. Ein Gerät, das in einem Segment ohne Route ins Internet installiert ist, geht nie auf Sendung.

Ausgehender Zugang wird für vier Dinge genutzt:

Zweck	Ziel	Erforderlich für
Lizenzanmeldung	iptvauth.alteox.app, HTTPS (TCP 443)	Erforderlich. Registrierung, Freigabe und regelmäßige Anmeldungen. Auf diesem Weg erhält das Gerät auch die von der Lizenz bereitgestellten Sender — siehe Über die Lizenz bereitgestellte Sender.
Telemetrie	otel.alteox.app, OTLP über gRPC (TCP 4317)	Zum Streamen nicht erforderlich. Hierher werden Metriken und Ereignisse jedes Senders gesendet — siehe Überwachung. Ist das Ziel nicht erreichbar, schlägt der Export fehl, und sonst ist nichts betroffen.
Quellen im Internet	Ihre Ursprungsserver	Nur wenn Ihre Quellen dort liegen. Das ist eine Eigenschaft Ihrer Sender, nicht des Produkts.
Upgrades	Die Container-Registry	Nur wenn Sie sich für ein Upgrade entscheiden. Nichts löst ein Upgrade automatisch aus.

Wenn die Verbindung verloren geht

Ein Gerät, das sich bereits angemeldet hat, streamt während eines Ausfalls weiter. Es läuft mit der zuletzt erhaltenen Lizenz, solange diese gültig ist — derzeit etwa zwei Tage —, und meldet sich erneut an, sobald der Server erreichbar ist. Ein kürzerer Ausfall lässt sich überstehen, ohne dass jemand vor Ort sein muss. Ein längerer nimmt jeden Sender vom Netz, sobald die zwischengespeicherte Lizenz abläuft. Die Einstellungen der Sender bleiben erhalten, und die Sender kommen von selbst zurück, sobald eine Anmeldung gelingt.

Das Panel License auf der Seite Settings zeigt den aktuellen Zustand und, falls das Streaming blockiert ist, den Grund. Außerdem zeigt es den Zeitpunkt der letzten Anmeldung, wann die Lizenz erneuert wird, und den Gerätecode, nach dem der Support fragen wird. Recheck licence & channels meldet das Gerät sofort an, statt auf den nächsten Versuch zu warten.

Halten Sie die Uhr korrekt

Die Lizenzprüfung hängt von der Systemuhr ab. Springt die Uhr zurück, ist das Streaming blockiert, bis sie korrigiert ist. Geben Sie dem Gerät als Teil der Installation eine funktionierende Zeitquelle (NTP), nicht erst im Nachhinein. Eine falsche Uhr bringt außerdem das falsche Programm in den Programmführer jedes Fernsehers.

Ein Vorbehalt zu DNS

Werden Ihre Quellen über Hostnamen adressiert, muss die Namensauflösung funktionieren, und zwar schnell. Ein Ursprungsserver, der eine IPv6-Adresse veröffentlicht, in einem Netz ohne IPv6-Route führt dazu, dass jeder Abruf zuerst IPv6 versucht und dann zurückfällt — im besten Fall langsam, im schlimmsten Fall mehrere Sekunden. Hat das Gerät keine IPv6-Konnektivität, konfigurieren Sie den Host so, dass er IPv4 bevorzugt; die Fehlerbehebung beschreibt die Symptome, die überzeugend nach einem langsamen Ursprungsserver aussehen.