Entrega a la red¶

La salida principal de una cabecera es un flujo de transporte enviado a la red: al grupo multicast de un operador de cable, a un modulador, a una dirección unicast de un receptor. Aquí la estación es la parte activa: envía por sí sola, nadie se conecta a ella.

Un destino de entrega se llama push, y cada push tiene un Nombre. El nombre es su identidad: por él se encuentra el destino en la configuración, en las estadísticas y en las métricas. El panel lo advierte justo debajo del campo: cambiar el nombre crea un push nuevo y los contadores empiezan de cero.

Envíe el stream a un grupo¶

La pestaña Egreso, el bloque Pushes, el botón + Añadir push. El protocolo es MPEG-TS/UDP.

El interruptor Activado junto al nombre apaga un destino sin borrarlo. Para unicast, indique la dirección del receptor. TTL de multicast e Interfaz de salida se aplican solo al multicast.

Selección de la interfaz de salida¶

En la pestaña Egreso, indique la Interfaz de salida de un push MPEG-TS/UDP o MPEG-TS/RTP: el nombre de una tarjeta, como eno4, o su dirección IPv4 local, como 192.168.40.10. Establezca Host en el grupo 239.255.2.77 y Puerto en 5500, y pulse Guardar. El multicast saldrá por la tarjeta elegida independientemente de la ruta por defecto.

Las interfaces de entrada y salida son independientes: puede recibir por eno2 y enviar por eno4. Cada push tiene su propia interfaz de salida. Si el campo está vacío, la tabla de rutas del sistema operativo decide; vacíelo y guarde para restablecer ese comportamiento. El ajuste se aplica al multicast IPv4. Para unicast, el enrutamiento elige la interfaz de salida; Dirección de enlace establece la dirección local del socket y tiene otra función.

La interfaz debe existir en el streamer emisor y tener dirección IPv4. Si el nombre o la dirección son incorrectos, el push no arrancará y mostrará un error. Cambiar la interfaz de salida reinicia el push. En un clúster, compruebe que la interfaz esté disponible en cada streamer que pueda enviar este stream.

La captura se configura por separado — vea selección de la interfaz de entrada.

Multicast en una red real¶

Tres cosas hacen tropezar a la entrega, y las tres se resuelven con los campos de arriba.

• La tarjeta de red equivocada. En una máquina con varias interfaces, el sistema elige la interfaz de salida por la tabla de rutas, y para el multicast esa elección muchas veces no es la pensada. Si la señal «se está enviando» pero el receptor no la ve, fije primero la Interfaz de salida de forma explícita.
• TTL. El valor por defecto de 10 permite al paquete sobrevivir al enrutamiento — el 1 que el kernel trae de fábrica no dejaría salir el stream ni fuera de la subred. A través de varios routers el TTL se sube; para un segmento estrictamente aislado, se baja.
• El receptor tiene que suscribirse. La estación envía al grupo sin importar si alguien escucha: los paquetes salen aunque no haya ningún suscriptor. Que «no llegue nada» del lado del receptor suele ser culpa de su propia suscripción o del IGMP snooping del conmutador, y no de la estación.

RTP en lugar de TS a secas¶

Algunos receptores esperan el MPEG-TS envuelto en RTP según RFC 2250 / SMPTE ST 2022-2, y no un stream pelado sobre UDP. Es la misma salida con otra encapsulación: elija el protocolo MPEG-TS/RTP en lugar de MPEG-TS/UDP.

El datagrama recibe una cabecera RTP; todo lo demás — direccionamiento, TTL, interfaz, contadores — es común con un push UDP corriente.

La opción vecina en la misma lista es RIST, para cuando el lado receptor espera exactamente eso.

Varios destinos a la vez¶

Un stream tiene tantos pushes como haga falta, y funcionan con independencia: un receptor caído en un destino no toca a los demás.

Los destinos con la misma configuración de salida efectiva comparten un solo stream idéntico byte a byte: cien pushes iguales cuestan lo mismo que uno. Lo que los hace distintos son solo sus propias tablas de servicio — el PNR y los PID propios del destino; entonces para él se reescriben las tablas y los PID, mientras que la disposición de los paquetes, el PCR y los contadores de continuidad siguen siendo los de la salida compartida.

Comportamiento ante el fallo¶

El pusher no tiene política de reintentos propia: lo revive el stream. Una vez cada cinco segundos el stream coteja los destinos en marcha con la configuración y sustituye un pusher muerto por uno nuevo; el contador de reconexiones cuenta exactamente esas sustituciones.

De ahí la consecuencia práctica: el envío a un destino inalcanzable nunca se rinde y nunca necesita un reinicio manual. Seguirá levantándose mientras el destino esté activado.

No cuentan como reconexiones:

• editar la configuración — el pusher también se reinicia, pero eso es una decisión del operador, no un fallo del enlace;
• apagar y encender — apagar no es borrar: la configuración y los contadores acumulados se quedan, solo se detiene el envío.

Borrar un destino borra también sus estadísticas: los contadores están atados al nombre.

Qué comprobar¶

Bajo cada push corre una línea de estadística en vivo: el estado — Enviando, Error o Desactivado —, la velocidad en kbit/s, los errores por segundo, las reconexiones y, en uno fallado, también la causa. Todos los campos y las recetas de alertas están en la página Monitorización de entrega.

El estado Enviando con velocidad cero significa que no hay nada que enviar: el problema está en la entrada, no en la salida.

Qué viene después¶

• Pistas seleccionadas en un push — una calidad de la escalera a su propio destino.
• Salida MPEG-TS — PNR, PID y SDT, incluidos los propios de cada destino.
• CBR para DVB — cuándo la señal va a un modulador.
• Entrega de reserva — varias estaciones en un grupo: una envía, las demás esperan.
• Monitorización de entrega — contadores y alertas.