Inicio rápido

Antes de empezar

Deben cumplirse cuatro condiciones. Si alguna no se cumple, resuélvala ahora: cada una de ellas provoca más adelante un síntoma que parece una avería de Castmux y no lo es.

• Una URL de origen que ya haya reproducido. Ábrala primero en VLC en su portátil. Si VLC no puede reproducirla, Castmux tampoco, y pasará la próxima hora leyendo registros sobre un problema que está en el servidor de origen.
• Un grupo multicast que tenga permiso para usar. 239.10.0.1:1234 es una primera opción razonable: 239.0.0.0/8 es el rango de ámbito administrativo, por lo que no entrará en conflicto con nada enrutado. Confirme con el responsable de la red que el grupo y el puerto están libres.
• El equipo en el mismo segmento de capa 2 que los televisores. El multicast no atraviesa un router salvo que alguien haya configurado PIM, lo cual queda fuera del alcance de esta guía. La misma VLAN, la misma red de switches.
• Saber qué interfaz de red da a los televisores. Necesitará el nombre —eth0, eth1, enp1s0—, no solo «la de la derecha». Casi todos los fallos al final de esta página se deben a que la ruta multicast apunta a la otra.

Inicie el equipo

Cree un directorio en el host para la configuración y, a continuación, inicie el contenedor:

Estos comandos requieren root

Crear un directorio en /opt y ejecutar Docker requieren privilegios de root, por lo que los comandos siguientes se muestran con sudo. Si ha iniciado sesión como root, omita sudo. Si su usuario pertenece al grupo docker, los comandos docker funcionan sin él; pero pertenecer a ese grupo equivale a ser root, así que concédalo de forma deliberada.

# A plain host directory, so config.yaml stays readable and backup-able
sudo mkdir -p /opt/castmux/config

sudo docker run -d --name castmux --restart unless-stopped \
  --network host \
  --cap-add NET_RAW \
  --cap-add NET_ADMIN \
  -v /opt/castmux/config:/config \
  -e CASTMUX_WEB_USERNAME=admin \
  -e CASTMUX_WEB_PASSWORD=choose-something-better \
  castmux/castmux:latest

Cada opción es imprescindible:

—network host

El multicast tiene que emitirse en la LAN real. En una red bridge de Docker los paquetes se generan perfectamente y luego no van a ninguna parte, porque el bridge es un segmento distinto de aquel en el que están los televisores. No hay ningún contador que lo muestre; simplemente parece que todo funciona y nadie recibe nada.

—cap-add NET_RAW

Permite la captura de paquetes. Castmux usa libpcap para dos cosas: detectar qué clientes se han unido realmente a un grupo, que es lo que controla la emisión bajo demanda, y medir el bitrate real que sale por la interfaz. Sin ello, ambas funciones quedan ciegas.

—cap-add NET_ADMIN

Permite inspeccionar y gestionar la ruta multicast. Castmux comprueba la tabla de rutas desde fuera del proceso de emisión, porque un flujo enviado a un destino sin ruta informa de éxito desde dentro.

-v /opt/castmux/config:/config

El único archivo YAML se encuentra aquí como /config/config.yaml. Monte un directorio del host (bind mount) en lugar de usar un volumen con nombre, para que, cuando no se pueda acceder a la interfaz web, siga pudiendo leer y editar la configuración con un editor de texto normal.

Inicie sesión

Abra http://<appliance>:8080 en el navegador e inicie sesión con las credenciales que definió en el entorno. El puerto 8080 es el predeterminado y puede cambiarse con --port.

El pie de página debería mostrar una cadena de versión, valores de CPU y memoria, y tasas de red por interfaz. Si es así, el proceso está sano y puede empezar a añadir canales.

Añada su primer canal

En la página UDP channels, elija Add channel y rellene:

Campo	Qué introducir en esta primera prueba
Name	Cualquier nombre reconocible. Se usa en la vista de registro y, con el motor pass-through, como nombre de servicio en el transport stream.
Source type	HLS.
Source URL	La URL que reprodujo en VLC. Una lista de reproducción maestra sirve.
Destination address	239.10.0.1
Destination port	1234
Engine	Deje el valor predeterminado, el motor pass-through. Si resulta que la fuente es fMP4/CMAF en lugar de segmentos MPEG-TS, cambie al motor de remultiplexado; consulte Motores de emisión.
Force always-on	Márquelo. Consulte la nota siguiente.

Por qué forzar always-on en la primera prueba

De forma predeterminada, un canal funciona bajo demanda: se inicia cuando Castmux ve que un televisor se une a su grupo multicast y se detiene cuando se va el último. Es el comportamiento que quiere en producción, y justo el equivocado durante la puesta en marcha. Un canal sin espectadores, correctamente, no hace nada; todos los indicadores marcan cero y la conclusión natural es que está averiado. Demuestre que el canal funciona con él forzado y, después, vuelva a activar la emisión bajo demanda en el paso seis.

Confirme que está realmente en el aire

Guarde el canal y espere unos segundos. Un canal pass-through suele producir su primer paquete unos dos segundos después de iniciarse; el motor de remultiplexado tarda unos cuatro segundos y medio.

Compruebe el indicador de bitrate UDP

En la tarjeta del canal, mire el indicador UDP bitrate. Debe ser distinto de cero.

Este es el indicador que importa, y merece la pena entender por qué. Las demás métricas —frecuencia de fotogramas, velocidad, bitrate de la fuente— proceden del propio motor informando sobre sí mismo. Un motor puede estar totalmente convencido de que está emitiendo sin que nada llegue a la red. El bitrate UDP se mide con libpcap en la propia interfaz: cuenta los paquetes que han salido de verdad. Es la única señal que no puede generar un proceso que le está mintiendo, y también la única que funciona igual con ambos motores.

Verifique en un cliente

Desde una máquina en el mismo segmento que los televisores:

ffplay udp://@239.10.0.1:1234

# or, with VLC
vlc udp://@239.10.0.1:1234

La @ no es decorativa. Sin ella, el cliente intenta enviar al grupo en lugar de unirse a él, y no verá nada mientras el equipo parece perfectamente sano.

Indicador de bitrate distinto de cero, pero ningún cliente recibe nada

Este único síntoma explica la mayoría de las llamadas de soporte en primeras instalaciones, y casi siempre tiene la misma causa: 224.0.0.0/4 en el equipo apunta a la interfaz equivocada, de modo que los paquetes se emiten en un enlace en el que no están los televisores, a menudo uno que ni siquiera está conectado. La llamada de envío tiene éxito de todos modos, y por eso el equipo informa de que está sano. Corrija el rango completo, no el grupo individual, y lea Solución de problemas → enrutamiento multicast antes de cambiar nada más.

Vuelva a activar la emisión bajo demanda

Una vez confirmado que el canal funciona, edítelo y desmarque force always-on. El canal se detendrá poco después de que se vaya el último espectador y volverá a iniciarse cuando se una uno. Con el motor pass-through, cuente con la primera imagen unos dos segundos después de la unión.

Un televisor al que se le ha cambiado de canal no siempre anuncia su salida de inmediato, así que hay una breve espera antes de que Castmux detenga el flujo. Es intencionado: detener y reiniciar en cada cambio de canal sería peor para el espectador que mantenerlo unos segundos más de lo estrictamente necesario.

Una advertencia durante las pruebas: la vista previa del navegador cuenta como espectador. Un canal bajo demanda con una vista previa abierta seguirá activo, lo cual es práctico y, en ocasiones, confuso.

Siguientes pasos

📡 Multiplexación DVB-C Entregue los mismos canales por la red coaxial que ya existe en el edificio. 👥 Emisión bajo demanda Cómo funciona la detección de espectadores y qué ocurre cuando no puede ver nada. 📊 Monitorización y métricas Qué valores se miden, cuáles se notifican y en cuáles confiar.

Antes de añadir el resto de los canales, lea Requisitos. En un equipo pequeño, la capacidad está limitada por la memoria, y la memoria se agota de golpe, no de forma gradual.