Requisitos

Equipo de referencia

Castmux se desarrolla y se mide sobre una máquina deliberadamente modesta, porque es lo que cabe en un armario de comunicaciones y funciona sin supervisión durante años:

Componente	Especificación de referencia
CPU	4 núcleos, arm64 o x86-64
Memoria	6 GB
Refrigeración	Sin ventilador
Almacenamiento	Cualquiera; en funcionamiento normal no hay actividad de disco más allá de los registros
Red	Una interfaz como mínimo, preferiblemente dos

No se transcodifica nada, así que no se requiere GPU ni se obtiene ningún beneficio de ella. La ausencia de escrituras sostenidas en disco es un dato a tener en cuenta para quien especifique el hardware: un equipo que funcione con flash industrial no se desgasta con esta carga de trabajo.

Coste por canal

Los dos motores tienen costes sensiblemente distintos, y elegir uno u otro cambia la capacidad del equipo en un factor de aproximadamente 1.5. Medido por canal:

Medición	Motor de remultiplexado	Motor pass-through
Arranque en frío (unión → primer paquete)	~4.4 s	~1.9 s
Datagramas completos de 1316 bytes	85%	100%
CPU por canal	~5% de un núcleo	~15% de un núcleo
RAM por canal	~72 MB	~23 MB
Canales en un equipo de 2 GB	~16	25+

Los costes van en direcciones opuestas, y por eso existen ambos motores. El motor pass-through consume poca memoria y mucha CPU; el motor de remultiplexado, al revés. En el equipo de referencia esto significa que el motor de remultiplexado se queda antes sin memoria y el motor pass-through se queda antes sin CPU: cuatro núcleos al 15% por canal dan algo más de 26 canales, que es de donde sale la cifra «25+».

El motor de remultiplexado no puede retirarse, pese a costar más por canal. El motor pass-through no puede rellenar con paquetes nulos hasta un bitrate constante, y su entrada HLS solo lee segmentos MPEG-TS, no fMP4/CMAF; así que un servidor de origen CMAF moderno, o un dispositivo posterior que exija CBR, necesita el motor de remultiplexado. Consulte Motores de emisión para saber cómo elegir.

Planificación de capacidad

La memoria es un precipicio, no una pendiente. Esto es lo más importante de esta página. El agotamiento de la CPU se degrada de forma progresiva: los flujos dan tirones, usted lo nota y reduce la carga. El agotamiento de la memoria no se degrada en absoluto: el kernel elige un proceso y lo mata, y el proceso elegido suele ser un canal sano que no tenía nada que ver con el problema. No hay ninguna franja de aviso entre «todo bien» y «un canal acaba de desaparecer».

El cálculo

Tres pasos:

Memoria utilizable = memoria total − ~300 MB. Esa reserva cubre el sistema operativo, el runtime de contenedores y el propio proceso de Castmux, ninguno de los cuales es un coste por canal.
Número bruto de canales = memoria utilizable ÷ RSS por canal del motor que haya elegido.
Deje un 15% de margen. El RSS por canal varía con el bitrate de la fuente y cambia durante los fallos momentáneos del servidor de origen y las reconexiones; ese último 15% es lo que lo absorbe.

Ejemplo resuelto para un equipo de 2 GB con el motor de remultiplexado:

# 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

El cálculo da veinte, y veinte es la cifra que provocó que el OOM killer actuara en un equipo real. La cifra segura medida es ~16. Cuando el cálculo y la medición no coinciden, confíe en la medición: el RSS por canal de la tabla es una media en régimen estable, y los canales no están todos en su media al mismo tiempo.

Utilice el cálculo como forma de descartar planes claramente inviables, no como permiso para llegar justo hasta el resultado.

Margen de CPU

Con el motor pass-through, haga la misma división respecto a los núcleos en lugar de la memoria: cuatro núcleos son 400 puntos porcentuales de CPU, a unos 15 por canal. Deje el mismo 15% de margen, y más si el equipo también controla un modulador DVB-C o sirve vistas previas a varios navegadores a la vez.

Red

Interfaces

Castmux funciona con una única interfaz de red, y para una instalación pequeña es una opción perfectamente razonable. Se recomiendan dos interfaces —una para gestión y otra orientada a los televisores—, por un motivo de diagnóstico más que de rendimiento.

Si la gestión y el multicast comparten un enlace, cualquier fallo se vuelve ambiguo. Un enlace ascendente saturado deja sin respuesta la interfaz web, de modo que la herramienta que usaría para diagnosticar el problema es precisamente la que el problema ha estropeado. Separarlas hace que la interfaz de gestión siga respondiendo mientras averigua qué le pasa a la otra, y que las cifras de tráfico del pie de página sean atribuibles: una interfaz debería mostrar una tasa multicast estable y la otra casi nada.

Capa 2 y enrutamiento

Los televisores deben estar en el mismo segmento de capa 2 que el equipo. El multicast no atraviesa un router de forma predeterminada; conseguirlo requiere PIM en los routers intermedios e IGMP snooping configurado de forma coherente en todo el recorrido, un trabajo de ingeniería de redes que queda fuera del alcance de este producto.

En el propio equipo, 224.0.0.0/4 debe apuntar a la interfaz orientada a los televisores. Esto se explica en detalle en Instalación → enrutamiento multicast, y merece la pena leerlo antes de encargar el hardware, porque es el requisito que la gente descubre en último lugar.

Enlace ascendente y arranque escalonado

El enlace ascendente que transporta los flujos de origen debe soportar la suma de los bitrates de todos los canales, con margen. El margen importa más que la media, por lo que ocurre durante el arranque.

Cuando Castmux arranca, todos los canales siempre activos quieren empezar a la vez. Cada uno abre una conexión con su servidor de origen y descarga segmentos tan rápido como este los sirva, para llenar su búfer. Ocho canales haciéndolo simultáneamente en un enlace ascendente de 100 Mbit no obtienen cada uno un octavo del enlace y arrancan despacio: todos agotan el tiempo de espera, todos fallan y todos reintentan, lo que vuelve a producir la misma ráfaga.

Por eso Castmux escalona el arranque de los canales, con un intervalo predeterminado de 3 segundos entre ellos. El coste es que un reinicio completo de veinte canales tarda aproximadamente un minuto en completarse. La ventaja es que se completa. No reduzca el intervalo para que los reinicios parezcan más rápidos; en un enlace ascendente limitado, ese es exactamente el cambio que reintroduce el fallo.

Hardware DVB-C

Solo es necesario si quiere salida de RF hacia la red coaxial. Se necesitan dos cosas:

Una ranura PCIe libre, lo que descarta la mayoría de los equipos compactos sin ventilador y suele ser el motivo por el que una instalación DVB-C necesita un chasis distinto del de una instalación solo IP.
Una tarjeta moduladora DVB-C compatible. La salida DVB-C se ha desarrollado y medido con tarjetas TBS; el hardware de referencia es la TBS 5862.

Para una instalación solo IP, nada de esto es aplicable. Consulte Multiplexación DVB-C para ver las tarjetas compatibles y la configuración.

Software

Un host Linux con un runtime de contenedores. Castmux se distribuye como castmux/castmux:latest y es un único proceso de Go dentro de la imagen.

La imagen está basada en Debian trixie. No es arbitrario: los motores necesitan versiones recientes de FFmpeg y TSDuck, y las versiones anteriores de Debian limitan ambos a versiones con limitaciones conocidas. Alpine no es una opción: no existe ningún paquete de TSDuck para musl, así que el motor pass-through sencillamente no puede compilarse allí. Si está acostumbrado a imágenes del tamaño de Alpine, espere que esta sea más grande; ese es el motivo.

La distribución del host no importa; solo que pueda ejecutar el contenedor con red de host y las dos capacidades descritas en Instalación.

Acceso a Internet

El equipo necesita acceso saliente a Internet para emitir. Todos los equipos comprueban su licencia con el servidor de licencias de Castmux. Hasta que su primera comprobación tiene éxito y el dispositivo ha sido aprobado, no emite en absoluto. Esto es así aunque todas las fuentes estén en la red local. Un equipo instalado en un segmento sin ruta a Internet nunca sale al aire.

El acceso saliente se usa para cuatro cosas:

Finalidad	Destino	Necesario para
Comprobación de licencia	`iptvauth.alteox.app`, HTTPS (TCP 443)	Obligatorio. Registro, aprobación y comprobaciones periódicas. El equipo también recibe por esta vía los canales suministrados con la licencia; consulte Canales suministrados por la licencia.
Telemetría	`otel.alteox.app`, OTLP sobre gRPC (TCP 4317)	No es necesario para emitir. Aquí se envían las métricas y los eventos de cada canal; consulte Monitorización. Si no se puede acceder, la exportación falla y nada más se ve afectado.
Fuentes alojadas en Internet	Sus servidores de origen	Solo si es ahí donde están sus fuentes. Es una característica de sus canales, no del producto.
Actualizaciones	El registro de contenedores	Solo cuando usted decida actualizar. Nada inicia una actualización automáticamente.

Pérdida de la conexión

Un equipo que ya ha realizado una comprobación sigue emitiendo durante un corte. Funciona con la última licencia recibida mientras esta sea válida, actualmente unos dos días, y vuelve a comprobarla en cuanto puede acceder al servidor. Un corte más breve que eso se supera sin que nadie tenga que desplazarse. Uno más largo deja todos los canales fuera del aire cuando caduca la licencia almacenada. Los ajustes de los canales se conservan, y los canales vuelven por sí solos en cuanto una comprobación tiene éxito.

El panel License de la página Settings muestra el estado actual y el motivo si la emisión está bloqueada. También muestra la hora de la última comprobación, cuándo se renueva la licencia y el código de dispositivo que le pedirá el soporte técnico. Recheck licence & channels realiza la comprobación de inmediato en lugar de esperar al siguiente intento.