Canales y fuentes

Qué es un canal

Una fuente más un destino. La fuente es una URL de la que Castmux obtiene la señal; el destino es una dirección IPv4 y un puerto a los que envía MPEG-TS. Todo lo demás en el canal —motor, perfil de resolución, comportamiento bajo demanda, tasa de bits esperada— modifica cómo funciona ese conducto, no lo que transporta.

Los canales son independientes. Cada uno se supervisa por separado, se reinicia por separado y se mide por separado, de modo que un origen caído en un canal no afecta a los demás.

Tipos de fuente

Sobre IP se admiten hoy cuatro tipos de fuente: HLS, SRT, RTMP y MPEG-TS simple, este último por UDP multicast o por HTTP. La tabla siguiente muestra qué más se admite y qué está previsto.

Fuente	Estado	Notas
HLS	Disponible	Lista de reproducción maestra o una única lista de medios. Consulte perfiles de resolución para saber cómo se elige un nivel.
SRT	Disponible	Modo caller, configurado íntegramente desde la URL. La latencia se calcula automáticamente.
RTMP	Disponible	Solo con el motor de remultiplexado. Normalmente, un codificador local que envía hacia la red del equipo.
UDP multicast (MPEG-TS)	Disponible	Volver a recibir una señal multicast existente, como la salida de otra cabecera. Tipo de fuente mpegts con una URL udp://. Consulte Fuentes MPEG-TS.
MPEG-TS por HTTP	Disponible	Un transport stream simple por HTTP, sin lista de reproducción. Tipo de fuente mpegts con una URL http:// o https://.
RTP multicast	Previsto	Transport stream encapsulado en RTP. Hoy solo se lee MPEG-TS simple sobre UDP. previsto
Cámaras RTSP	Previsto	Para señales de recepción, capilla y CCTV. previsto
Entrada de sintonizador DVB-S/S2	Previsto	Servicios por satélite recibidos por antena en lugar de por IP. No disponible hoy: no existe ninguna entrada de sintonizador de ningún tipo, así que no compre una tarjeta sintonizadora para ello. previsto
Entrada de sintonizador DVB-T	Previsto	Servicios terrestres recibidos por antena. previsto
Entrada de sintonizador DVB-C	Previsto	Recibir servicios de una red de cable en lugar de por IP. previsto

Fuentes HLS

Indique al canal la URL de una lista de reproducción maestra. Castmux lee la escalera que anuncia y selecciona una variante para entregarla al motor, según el perfil de resolución del canal. Sin perfil —el valor por defecto, y el que tienen todos los canales existentes—, la lista maestra se entrega sin cambios y decide el orden del origen.

La posición de inicio respecto al directo es configurable. Empezar más atrás en la lista de reproducción aporta resistencia frente a un origen que publica segmentos de forma irregular, a costa de un mayor retraso respecto al directo y una primera imagen más lenta tras un cambio de canal.

Los orígenes fMP4/CMAF necesitan el motor de remultiplexado

El lector HLS del motor pass-through solo admite segmentos MPEG-TS. Si el origen publica segmentos MP4 fragmentados (CMAF), ese canal debe usar el motor de remultiplexado. Es una propiedad del lector, no un ajuste: ninguna combinación de opciones hace que el motor pass-through interprete fMP4. Consulte Motores de emisión.

Fuentes SRT

Los canales SRT funcionan en modo caller: Castmux se conecta al origen. Toda la configuración va en la URL, y los siguientes parámetros de consulta se trasladan al motor:

streamid, passphrase, transtype, latency, rcvlatency, peerlatency, rcvbuf, sndbuf, maxbw, pbkeylen, payloadsize, tlpktdrop, linger.

srt://origin.example.net:9000?streamid=play/news&passphrase=••••••••&transtype=live

Latencia automática

Castmux mide el tiempo de ida y vuelta hasta el host de origen y fija el margen de latencia SRT en cuatro veces el RTT medido, con un mínimo de 200 ms y un máximo de 4000 ms. Cualquier valor de latencia presente en la URL se sustituye.

Existe porque el valor habitual por defecto de 120 ms es erróneo en cualquier enlace con jitter real, y porque el fallo resultante es uno que nadie atribuye a la latencia. Un margen insuficiente no rompe el canal; produce artefactos intermitentes —unos segundos de bloques cada cierto tiempo, sin intervalo predecible— en un canal cuyo panel está completamente en verde. Las instalaciones persiguen durante semanas al codificador, al switch y al televisor antes de que alguien sospeche de un ajuste de transporte copiado de otra instalación con un trayecto más corto.

El multiplicador es la recomendación convencional de SRT: el receptor debe poder esperar una retransmisión, que cuesta un viaje de ida y vuelta completo, con margen para un segundo intento. El mínimo evita que un enlace muy corto obtenga un margen demasiado pequeño para absorber pérdida alguna; el máximo evita que una sola medición errónea añada segundos de retardo a un canal.

Si prefiere fijar el valor usted mismo, desactive este comportamiento con overwrite_srt_latency: false en la configuración global, y la latencia de la URL se respetará.

Modos listener y rendezvous

Ambos son accesibles hoy pasando parámetros del motor en la URL, pero no están modelados en la interfaz: no hay ningún campo que diga “escuchar en este puerto” y nada valida lo que escribe. El soporte completo para canales listener y rendezvous está previsto.

Fuentes RTMP

RTMP se admite con el motor de remultiplexado, y normalmente se usa para un codificador local en la misma red que el equipo, no para una señal que llega por internet.

RTMP no funciona con el motor pass-through

No es un problema de ajuste ni una opción que falte. Si configura un canal RTMP con el motor pass-through, no funcionará. Deje esos canales con el motor de remultiplexado, o establezca la anulación de motor en el canal si su valor global por defecto es pass-through.

Fuentes MPEG-TS

El tipo de fuente mpegts recibe un transport stream que llega tal cual, sin lista de reproducción y sin contenedor. El esquema de la URL decide el transporte:

# a multicast group, e.g. another headend's output
source:
  type: mpegts
  url: udp://239.20.0.5:1234?localaddr=192.168.10.4

# a continuous transport stream over HTTP
source:
  type: mpegts
  url: https://origin.example.net/news/mpegts

Por UDP, el canal se une al grupo y lee los datagramas de transport stream exactamente como llegan. La URL admite tres parámetros opcionales, que se escriben igual para ambos motores:

• localaddr es la dirección local en la que recibir el grupo. Configúrela en un equipo con varias interfaces, para que la unión salga por la que está orientada al emisor.
• sources restringe la recepción a un único emisor, para multicast de fuente específica.
• buffer_size es el búfer de recepción del kernel en bytes. El valor por defecto es generoso, para que un bloqueo de planificación no descarte datagramas.

Por HTTP, el canal lee una única respuesta interminable, como la salida /mpegts de un servidor de streaming. Si el origen cierra la conexión, el canal se reinicia, igual que ante cualquier otro fallo de la fuente.

Hay algunas diferencias respecto a los demás tipos de fuente:

• Los perfiles de resolución no se aplican. Un transport stream transporta una única versión fija y no hay escalera entre la que elegir.
• Un canal no puede recibir su propia salida. Una fuente udp:// igual a la dirección y el puerto de destino del propio canal se rechaza al guardar el canal. De lo contrario, el motor ingeriría lo que acaba de enviar, indefinidamente, mientras el medidor de tasa de bits informaba de un canal sano. Leer el grupo de un canal distinto está permitido, y es una forma deliberada de encadenar un canal a otro.
• Solo se lee transport stream simple. Todavía no se admite una señal multicast encapsulada en RTP.

El destino

Una dirección IPv4 y un puerto. La dirección puede ser un grupo multicast, que es el caso normal en la distribución de televisión, o una dirección unicast para un único receptor o una prueba.

Para multicast, utilice el rango de ámbito administrativo 239.0.0.0/8. Está reservado exactamente para este fin —uso privado, local a la organización—, así que nada de lo que elija dentro de él puede colisionar con una asignación conocida.

Nunca utilice 224.0.0.0/24 para contenido

Ese rango está reservado para protocolos de control de enlace local: las adyacencias de enrutamiento, el propio IGMP y el descubrimiento de vecinos viven ahí. Los paquetes dirigidos a él se envían con un TTL de uno y los procesa cada dispositivo del segmento. Poner ahí un canal de televisión inunda de tráfico el plano de control de sus switches y perturbará la red mucho antes de que alguien se dé cuenta de que falta la imagen.

Hoy, un destino por canal. Enviar el mismo canal a varios grupos —por ejemplo, un grupo multicast y una sonda unicast— requiere un segundo canal con la misma URL de fuente. Varios destinos por canal está previsto.

Ajustes por canal

active

Si el canal está siquiera bajo supervisión. Un canal inactivo conserva su configuración, pero nunca se arranca y no produce métricas.

force_always_on

Mantiene el canal en marcha haya o no alguien viéndolo. El valor por defecto es desactivado, lo que significa bajo demanda: el canal solo funciona mientras se detecta un espectador en su grupo. Actívelo en los canales que nunca deben sufrir el retardo de arranque en frío al cambiar de canal. Consulte Emisión bajo demanda.

engine

Anula la elección global de motor para este canal. Vacío significa heredar. Consulte Motores de emisión.

resolution_profile

Qué nivel de una escalera HLS tomar. Vacío significa tomar la lista maestra sin cambios. Se ignora para SRT y RTMP, que no tienen escalera. Consulte Perfiles de resolución.

min_output_kbps

La tasa de bits de salida por debajo de la cual se considera que este canal no está produciendo nada y, por tanto, que necesita un reinicio.

Los canales de radio necesitan un umbral de tasa de bits más bajo

El valor global por defecto de la tasa de bits de salida mínima esperada presupone vídeo. Un servicio solo de audio está legítimamente muy por debajo —128 kbps es una tasa de bits de radio corriente—, así que con el umbral global se declara silencioso en cada comprobación y se reinicia indefinidamente mientras funciona perfectamente. Configure min_output_kbps en ese canal con un valor holgadamente inferior a su tasa real.

Nombrar un canal

El nombre del canal no es solo una etiqueta en la interfaz. Se convierte en el nombre de servicio DVB transportado en la SDT, que es lo que el televisor muestra en su lista de canales, y es la etiqueta asociada a cada métrica que produce el canal.

Esa segunda consecuencia es la que pilla desprevenida a la gente: renombrar un canal renombra sus series de métricas. Los datos históricos no siguen al cambio de nombre, así que un panel o una alerta basados en el nombre antiguo se quedan mudos, y la gráfica del canal parece empezar desde cero. Decida los nombres antes de construir paneles y trate un cambio de nombre como una operación con coste aguas abajo, no como un retoque estético.

Identidad del canal

Los canales se identifican con un id entero. Ese id aparece en el archivo de configuración, en la API HTTP y en cualquier lugar donde se haga referencia a un canal desde fuera.

Actualmente los id se reutilizan tras una eliminación. Si elimina el canal 7 y luego añade un canal nuevo, al nuevo se le puede asignar el id 7. Es un canal distinto en todo lo que le importa a un operador —otro nombre, otra fuente, otro destino—, pero todo lo que se basa en el id ve continuidad donde no la hay.

Conviene conocer las consecuencias prácticas antes de confiar en los id:

• Cualquier cosa que guarde estado por canal asociado al id —un planificador externo, una llamada a la API guardada, un marcador en la interfaz— puede acabar apuntando al canal equivocado tras un ciclo de eliminar y añadir.
• Los navegadores restauran el estado de los controles de formulario en una recarga suave con independencia de lo que haya generado el servidor, así que un canal recién creado puede mostrar brevemente un ajuste heredado del canal eliminado que tenía su id. Lo que dice la insignia junto al control es la verdad.
• En DVB-C, la identidad del servicio se deriva de la posición en un múltiplex y no del id del canal, de modo que reordenar o eliminar un canal desplaza los servicios que lo rodean.

Los identificadores estables y no reutilizados y la identidad de servicio fija están previstos. Hasta entonces, la regla segura es: un id identifica una posición, y un nombre identifica un canal.

Canales suministrados por la licencia

Una licencia puede incluir una lista de canales además del permiso para emitir. En cada comprobación de licencia, el equipo compara esa lista con sus propios canales. Cada canal registra quién es su propietario (managed_by en el archivo de configuración), y de ello se derivan dos reglas:

• Un canal suministrado por la licencia pertenece al servidor de licencias. En cada comprobación, su fuente, destino, perfil de resolución, modo siempre activo y estado de encendido o apagado se actualizan a lo que envíe el servidor, de modo que un canal que cambia de ubicación se corrige sin visita a la instalación. Si el servidor deja de listarlo, se elimina. La interfaz web marca estos canales y no permite editarlos ni eliminarlos, ya que la siguiente comprobación desharía el cambio.
• Un canal que haya añadido usted nunca se toca. El servidor nunca lo cambia ni lo elimina, aunque la lista contenga un canal con el mismo nombre. La única excepción es un canal que haya apagado: no está ejecutando nada, así que un canal con licencia con el mismo nombre o destino puede ocupar su lugar. Esto es lo que permite migrar un equipo antiguo sin eliminar antes sus canales antiguos.

La licencia también fija un número máximo de canales que pueden funcionar a la vez. Un canal con licencia por encima de ese límite se añade apagado en lugar de descartarse, de modo que ampliar el plan más adelante consiste en encenderlo, no en volver a introducirlo. El límite también se aplica a los canales que añada usted: un canal añadido cuando ya se ha alcanzado el límite llega apagado, con un mensaje que explica por qué.

Un canal con licencia que enviaría a un grupo que ya usa otro canal en marcha se rechaza en lugar de permitir la colisión, y lo mismo ocurre con uno que el servidor haya enviado sin URL de fuente o sin destino. Los rechazos se muestran en la interfaz web además de registrarse, para poder distinguir “el servidor no envió nada” de “el equipo rechazó lo que envió”.

Ejemplo práctico

Dos canales en config.yaml: uno HLS con perfil de resolución y otro SRT con un umbral de tasa de bits más bajo porque es un servicio de radio:

streams:
  - id: 1
    name: BBC One
    description: Reception and lounge
    active: true
    source:
      type: hls
      url: https://origin.example.net/bbcone/master.m3u8
    destination:
      address: 239.1.1.10
      port: 5000
    # Televisions here are 720p panels; the origin lists 1080p first.
    resolution_profile: hd
    force_always_on: true

  - id: 2
    name: Classic FM
    description: Audio only
    active: true
    source:
      type: srt
      url: srt://origin.example.net:9000?streamid=play/classicfm&transtype=live
    destination:
      address: 239.1.1.11
      port: 5000
    # Radio: well under the video-oriented global floor, so lower it or the
    # channel is treated as silent and restarted forever.
    min_output_kbps: 64
    force_always_on: true

No se indica latency en la URL SRT porque Castmux la calcula a partir del tiempo de ida y vuelta medido. No se indica engine en ninguno de los dos canales, así que ambos heredan el valor global por defecto.