Systeemvereisten

Referentieapparaat

Castmux wordt ontwikkeld en gemeten op een bewust bescheiden machine, omdat dat is wat in een patchkast past en jarenlang onbeheerd draait:

Onderdeel	Referentiespecificatie
CPU	4 cores, arm64 of x86-64
Geheugen	6 GB
Koeling	Ventilatorloos
Opslag	Willekeurig; bij normaal gebruik is er naast logging geen schijfactiviteit
Netwerk	Minimaal één interface, bij voorkeur twee

Er wordt niets getranscodeerd, dus er is geen GPU nodig en een GPU levert ook niets op. Het ontbreken van aanhoudende schrijfactiviteit is het vermelden waard voor wie hardware specificeert: een apparaat op industriële flashopslag slijt niet door deze belasting.

Kosten per zender

De twee engines verschillen wezenlijk in kosten, en uw keuze verandert de capaciteit van de box met ongeveer een factor 1,5. Gemeten per zender:

Meting	Remux-engine	Pass-through-engine
Koude start (aanmelding → eerste pakket)	~4.4 s	~1.9 s
Volledige datagrammen van 1316 bytes	85%	100%
CPU per zender	~5% van een core	~15% van een core
RAM per zender	~72 MB	~23 MB
Zenders op een box met 2 GB	~16	25+

De kosten lopen in tegengestelde richting, en daarom bestaan beide engines. De pass-through-engine is zuinig met geheugen en duur in CPU; bij de remux-engine is het omgekeerd. Op het referentieapparaat betekent dit dat de remux-engine eerst door zijn geheugen heen is en de pass-through-engine eerst door zijn CPU — vier cores à 15% per zender is iets meer dan 26 zenders, en daar komt het getal „25+” vandaan.

De remux-engine kan niet worden afgeschaft, ook al kost hij meer per zender. De pass-through-engine kan niet met null-pakketten opvullen tot een constante bitrate, en zijn HLS-invoer leest alleen MPEG-TS-segmenten, geen fMP4/CMAF — een moderne CMAF-originserver, of een apparaat verderop in de keten dat CBR eist, heeft dus de remux-engine nodig. Zie Streaming-engines voor hoe u kiest.

Capaciteitsplanning

Geheugen is een klif, geen helling. Dat is het allerbelangrijkste op deze pagina. Een tekort aan CPU verloopt geleidelijk — streams haperen, u merkt het, u verlaagt de belasting. Een tekort aan geheugen verloopt helemaal niet geleidelijk: de kernel kiest een proces en beëindigt het, en dat is meestal een gezonde zender die niets met het probleem te maken had. Er zit geen waarschuwingszone tussen „prima” en „er is net een zender verdwenen”.

De berekening

Drie stappen:

Bruikbaar geheugen = totaal geheugen − ~300 MB. Die reserve dekt het besturingssysteem, de container-runtime en het Castmux-proces zelf; geen van drieën zijn kosten per zender.
Ruw aantal zenders = bruikbaar geheugen ÷ RSS per zender voor de gekozen engine.
Houd 15% marge aan. De RSS per zender varieert met de bronbitrate en schommelt bij haperingen van de originserver en bij herverbindingen; de laatste 15% vangt dat op.

Uitgewerkt voor een apparaat met 2 GB en de 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

De berekening komt uit op twintig, en twintig is precies het aantal dat een echte box tot een OOM-kill bracht. Het gemeten veilige aantal is ~16. Spreken berekening en meting elkaar tegen, geloof dan de meting: de RSS per zender in de tabel is een gemiddelde in stabiele toestand, en zenders zitten niet allemaal tegelijk op hun gemiddelde.

Gebruik de berekening om duidelijk onhaalbare plannen uit te sluiten, niet als vrijbrief om tot aan de uitkomst te gaan.

CPU-marge

Maak bij de pass-through-engine dezelfde deling, maar dan tegen cores in plaats van geheugen: vier cores zijn 400 procentpunten CPU, bij ongeveer 15 per zender. Houd dezelfde 15% marge aan, en meer als de box ook een DVB-C-modulator aanstuurt of tegelijk voorvertoningen aan meerdere browsers levert.

Netwerk

Interfaces

Castmux draait op één netwerkinterface, en voor een kleine installatie is dat een volkomen redelijke keuze. Twee interfaces — één voor beheer, één richting de televisies — hebben de voorkeur, om een diagnostische reden en niet vanwege doorvoer.

Delen beheer en multicast één verbinding, dan wordt elke storing dubbelzinnig. Een verzadigde uplink maakt de webinterface traag of onbereikbaar, zodat precies het hulpmiddel waarmee u het probleem zou onderzoeken door het probleem is uitgeschakeld. Met gescheiden interfaces blijft de beheerinterface bereikbaar terwijl u uitzoekt wat er met de andere mis is, en zijn de verkeerscijfers in de voettekst toe te wijzen: de ene interface hoort een constante multicastsnelheid te tonen, de andere vrijwel niets.

Layer 2 en routering

De televisies moeten op hetzelfde layer-2-segment zitten als het apparaat. Multicast gaat standaard niet over een router heen; daarvoor is PIM op de tussenliggende routers nodig en een consistent geconfigureerde IGMP snooping over het hele pad, en dat is netwerkengineering die buiten de scope van dit product valt.

Op het apparaat zelf moet 224.0.0.0/4 naar de interface richting de televisies wijzen. Dit wordt uitgebreid behandeld in Installatie → multicastroutering, en het is de moeite waard dat te lezen voordat u hardware bestelt, omdat dit de vereiste is die men als laatste ontdekt.

Uplink en gespreid opstarten

De uplink die de bronstreams aanvoert, moet de som van alle zenderbitrates aankunnen, met marge. Die marge is belangrijker dan het gemiddelde, vanwege wat er bij het opstarten gebeurt.

Wanneer Castmux start, wil elke always-on zender tegelijk beginnen. Elke zender opent een verbinding met zijn originserver en haalt segmenten op zo snel als de originserver ze levert, om zijn buffer te vullen. Acht zenders die dat tegelijk doen op een uplink van 100 Mbit krijgen niet elk een achtste van de verbinding om langzaam te starten — ze lopen allemaal in een time-out, mislukken allemaal en proberen het allemaal opnieuw, wat dezelfde piek weer oplevert.

Castmux spreidt daarom het starten van zenders, met standaard een tussenpoos van 3 seconden. Het nadeel is dat een volledige herstart van twintig zenders ongeveer een minuut duurt. Het voordeel is dat hij überhaupt voltooid wordt. Verklein de tussenpoos niet om herstarts sneller te laten lijken; op een beperkte uplink is dat precies de wijziging die de storing terugbrengt.

DVB-C-hardware

Alleen nodig als u RF-uitvoer op het coaxnetwerk wilt. U hebt twee dingen nodig:

Een vrij PCIe-slot. Dat sluit de meeste compacte ventilatorloze boxen uit, en is de gebruikelijke reden dat een DVB-C-installatie een ander chassis nodig heeft dan een installatie met alleen IP.
Een ondersteunde DVB-C-modulatorkaart. De DVB-C-uitvoer is ontwikkeld en gemeten met TBS-kaarten; de referentiehardware is de TBS 5862.

Voor een installatie met alleen IP is dit allemaal niet van toepassing. Zie DVB-C-multiplexing voor ondersteunde kaarten en configuratie.

Software

Een Linux-host met een container-runtime. Castmux wordt geleverd als castmux/castmux:latest en is één Go-proces in de image.

De image is gebouwd op Debian trixie. Dat is niet willekeurig: de engines hebben recente versies van FFmpeg en TSDuck nodig, en oudere Debian-releases blijven voor beide steken op versies met bekende beperkingen. Alpine is geen optie — er bestaat geen TSDuck-pakket voor musl, dus de pass-through-engine kan daar eenvoudigweg niet worden gebouwd. Bent u images van Alpine-formaat gewend, reken er dan op dat deze groter is; dit is de reden.

De distributie van de host doet er niet toe, zolang die de container kan draaien met hostnetwerk en de twee capabilities uit Installatie.

Internettoegang

Het apparaat heeft uitgaande internettoegang nodig om te streamen. Elk apparaat controleert zijn licentie bij de Castmux-licentieserver. Zolang de eerste check-in niet is geslaagd en het apparaat niet is goedgekeurd, streamt het helemaal niet. Dat geldt ook als alle bronnen op het lokale netwerk staan. Een apparaat op een segment zonder route naar internet gaat nooit in de lucht.

Uitgaande toegang wordt voor vier dingen gebruikt:

Doel	Bestemming	Nodig voor
Licentie-check-in	`iptvauth.alteox.app`, HTTPS (TCP 443)	Vereist. Registratie, goedkeuring en regelmatige check-ins. Het apparaat ontvangt op deze manier ook zenders die bij de licentie horen — zie Zenders via de licentie.
Telemetrie	`otel.alteox.app`, OTLP via gRPC (TCP 4317)	Niet nodig om te streamen. Meetwaarden en gebeurtenissen van elke zender worden hierheen gestuurd — zie Monitoring. Is de bestemming onbereikbaar, dan mislukt de export en heeft dat verder nergens invloed op.
Bronnen op internet	Uw originservers	Alleen als uw bronnen daar staan. Dit is een eigenschap van uw zenders, niet van het product.
Upgrades	De container-registry	Alleen wanneer u zelf kiest voor een upgrade. Er wordt nooit automatisch een upgrade gestart.

Als de verbinding wegvalt

Een apparaat dat al een check-in heeft gedaan, blijft tijdens een storing streamen. Het draait op de laatst ontvangen licentie zolang die geldig is, momenteel ongeveer twee dagen, en doet opnieuw een check-in zodra de server bereikbaar is. Een storing die korter duurt, is zonder bezoek ter plaatse te overbruggen. Een langere storing haalt alle zenders van de lucht zodra de gecachte licentie verloopt. De instellingen van de zenders blijven bewaard, en ze komen vanzelf terug zodra een check-in slaagt.

Het paneel License op de pagina Settings toont de huidige status, en de reden als streamen geblokkeerd is. Het toont ook het tijdstip van de laatste check-in, wanneer de licentie wordt verlengd en de apparaatcode waar support om zal vragen. Recheck licence & channels doet direct een check-in in plaats van te wachten op de volgende poging.