Salida UDP multicast
Direccionamiento
Section titled “Direccionamiento”Para la distribución dentro de un edificio, utilice el rango de ámbito administrativo, 239.0.0.0/8. Es el equivalente multicast de 10.0.0.0/8: reservado para uso local, nunca enrutado hacia internet pública y seguro de asignar sin consultar ningún registro. Asigne un grupo por canal y lleve un registro escrito de la asignación, porque una colisión entre dos canales es la misma avería que un emisor duplicado y se manifiesta igual.
No utilice 224.0.0.0/24. Ese bloque está reservado para protocolos de control de enlace local: adyacencias de enrutamiento, el propio IGMP y el descubrimiento de vecinos en algunos equipos. El vídeo enviado ahí se entrega a todos los dispositivos del segmento y lo procesa código del plano de control que no esperaba 38 Mbps. Castmux avisa cuando un destino cae en ese rango en lugar de rechazarlo sin más, suponiendo que quizá esté probando algo deliberadamente, pero en producción el aviso debe tratarse como un error.
Se admiten destinos unicast, y son la opción adecuada para un enlace punto a punto: alimentar otra cabecera a través de una ruta enrutada, entregar un canal a un grabador o a un registrador de cumplimiento, o hacer pruebas desde un portátil que no está en la VLAN de televisión. Un canal unicast no tiene detrás ninguna pertenencia IGMP, así que la emisión bajo demanda no puede detectar espectadores para él y el canal debe dejarse siempre activo.
| Rango | Uso |
|---|---|
| 239.0.0.0/8 | recomendado Ámbito administrativo. La opción correcta para la distribución dentro del edificio. |
| 224.0.0.0/24 | evitar Reservado para protocolos de control de enlace local. Castmux avisa si un canal apunta aquí. |
| Dirección unicast | punto a punto Se admite. Adecuado para otra cabecera o un grabador. Sin detección de espectadores, así que mantenga el canal siempre activo. |
Tamaño del datagrama
Section titled “Tamaño del datagrama”La carga útil de cada datagrama es de 1316 bytes, exactamente siete paquetes de transporte de 188 bytes. Esa cifra no es arbitraria y conviene entender por qué es la única elección sensata.
Un paquete de transporte tiene 188 bytes y no puede repartirse entre datagramas sin que el receptor tenga que reensamblarlo. Siete paquetes son 1316 bytes, que con 8 bytes de cabecera UDP y 20 bytes de cabecera IPv4 suman 1344: holgadamente dentro de una MTU Ethernet de 1500 bytes, con espacio para una etiqueta VLAN. Ocho paquetes serían 1504 bytes de carga útil y se fragmentarían.
Enviar menos de siete paquetes por datagrama es legal, pero ineficiente en dos sentidos distintos. Cada datagrama lleva los mismos 28 bytes de cabecera por lleno que vaya, así que un flujo de datagramas medio vacíos gasta aproximadamente el doble en cabeceras y el doble de procesamiento por paquete en el dispositivo receptor para el mismo vídeo. Y, lo que es más importante, algunos descodificadores gestionan mal los datagramas irregulares: un descodificador que presupone siete paquetes por datagrama, o que almacena en búfer por número de datagramas en lugar de por bytes, produce artefactos intermitentes que solo aparecen en algunos modelos y que son casi imposibles de reproducir en un reproductor de PC.
Aquí los dos motores difieren. El motor pass-through emite datagramas completos de 1316 bytes el 100% del tiempo. El motor de remultiplexado los llena alrededor del 85% del tiempo, y vacía un datagrama corto cada vez que su multiplexor interno alcanza un límite de fotograma. Por eso Castmux fuerza explícitamente el tamaño de paquete en los canales HLS en lugar de aceptar el valor por defecto del motor; consulte Motores de emisión para la comparativa completa.
El valor por defecto es 16. El TTL de un datagrama multicast se reduce en cada router que lo reenvía, así que limita hasta dónde puede llegar el tráfico.
TTL 1
El datagrama nunca sale del segmento local. En un único edificio con el equipo y los televisores en la misma VLAN, este suele ser el valor correcto, y es una red de seguridad útil: un error de configuración no puede filtrar vídeo al resto de la red.
TTL 16 (por defecto)
Permite el reenvío a través de unos pocos saltos de router. Se eligió como valor por defecto porque funciona tanto en el caso plano como en el enrutado, y porque un flujo que no llega es una avería más difícil de diagnosticar que uno que viaja algo más lejos de lo necesario.
Valores más altos
Solo son necesarios cuando un router reenvía deliberadamente multicast entre VLAN, lo que requiere que quien gestiona la red haya configurado PIM o un equivalente. Subir el TTL no hace por sí solo que el multicast atraviese un router.
Interfaz de salida
Section titled “Interfaz de salida”A un canal se le puede asignar una dirección de origen, y el motor vinculará su socket a ella. Es útil para que la dirección de origen del tráfico sea predecible, para reglas de cortafuegos y para identificar de qué equipo procede un flujo en un segmento con más de uno.
Dos consecuencias más del mismo hecho. Corrija el rango, 224.0.0.0/4, no grupos individuales: una ruta de host por grupo parchea los canales que tenga hoy y deja todos los canales que se añadan después silenciosamente sin ruta. Y los cambios de ruta hechos con ip route no sobreviven a un reinicio, así que deben instalarse como una unidad que se ejecute al arrancar.
Tasa de bits constante
Section titled “Tasa de bits constante”Algunos equipos aguas abajo, y algunos descodificadores antiguos, se comportan mejor con un transport stream de tasa de bits constante que con uno que sigue a la fuente. Rellenar a CBR significa insertar paquetes nulos para que la tasa en el cable sea plana, haga lo que haga el vídeo.
El motor de remultiplexado puede hacerlo, porque construye su propio transport stream y puede decidir qué parte es relleno. El motor pass-through no puede: reenvía los paquetes de la fuente sin alterarlos y no tiene ningún mecanismo para insertar paquetes nulos, que es la misma propiedad que le hace conservar los PID originales y notificar fielmente la pérdida en la fuente. No se pueden tener ambas cosas.
En la ruta DVB-C la cuestión no se plantea. Una portadora DVB-C es de tasa de bits constante por construcción y el multiplexor rellena para completarla, así que un canal destinado a un múltiplex no necesita aplicar CBR a su salida UDP.
La tasa de bits constante por canal en la salida UDP simple, configurable con independencia del motor, está prevista.
Nombre del servicio
Section titled “Nombre del servicio”Un televisor o descodificador que explora un grupo multicast muestra el nombre que el transport stream declara en su Service Description Table. Con el motor pass-through, Castmux escribe el nombre del canal en la SDT, de modo que el nombre que escribe en la interfaz web es el que aparece en pantalla.
El motor de remultiplexado no escribe una SDT. Los canales con ese motor aparecerán con el nombre que invente el dispositivo receptor, normalmente la dirección del grupo o un marcador genérico. Si el nombre en pantalla importa y la fuente lo permite, utilice el motor pass-through.
Emisores duplicados
Section titled “Emisores duplicados”Dos procesos que envían al mismo grupo y puerto producen un flujo que es el entrelazado de ambos. Los contadores de continuidad entran en conflicto, los PID colisionan y el resultado en pantalla es pixelación y cortes de audio que van y vienen.
Esta avería es inusualmente cara de diagnosticar porque ambos emisores parecen completamente sanos. Cada uno produce un flujo válido a la tasa de bits correcta; las métricas de cada uno están en verde. La tasa de bits medida en el cable es aproximadamente el doble de lo que debería, que es la única pista, y es fácil atribuirla a otra cosa.
Por eso Castmux busca otros emisores en la dirección y el puerto de destino antes de arrancar un canal, y notifica la situación en lugar de arrancar encima de ellos. La causa clásica no son dos canales de Castmux —la interfaz de usuario lo impide—, sino un servicio antiguo que sigue en marcha junto a un despliegue nuevo: un emisor anterior que se deshabilitó pero no se detuvo, o una unidad systemd que una entrada de cron reinicia cada noche.
Oyentes ficticios
Section titled “Oyentes ficticios”Cuando nada en la red se ha unido a un grupo multicast, no hay ningún receptor que aplique contrapresión y, en algunas combinaciones de kernel y controlador, el búfer de envío del socket puede desbordarse en lugar de limitarse a descartar. El síntoma son errores de envío intermitentes en un canal que ni siquiera está viendo nadie.
Castmux puede mantener un consumidor local para cada grupo, que se une a él, lee el tráfico y lo descarta. Así la pertenencia al grupo y el comportamiento del búfer son coherentes haya o no espectadores reales. Está activado por defecto y cuesta muy poco; no hay motivo para desactivarlo salvo que esté midiendo algo y quiera que el grupo no tenga realmente ningún miembro.
Tenga en cuenta la interacción con la emisión bajo demanda: el oyente ficticio deliberadamente no cuenta como espectador. Si contara, ningún canal bajo demanda se detendría nunca.
Verificar la salida
Section titled “Verificar la salida”Tres comprobaciones, de menos a más concluyentes.
Primero, reproduzca el grupo desde una máquina del mismo segmento:
# ffplay, on a host in the same VLAN as the applianceffplay udp://@239.10.0.1:1234
# The @ is required. Without it ffplay listens on a unicast socket# and never joins the group, so you will see nothing and blame the encoder.En VLC, use Media → Open Network Stream e introduzca la misma URL:
udp://@239.10.0.1:1234Segundo, use la vista previa del navegador en la interfaz web. Confirma que la fuente está llegando y se está preparando correctamente, pero no demuestra nada sobre la ruta multicast, porque la vista previa no viaja por ella.
Tercero, y lo más útil, lea la casilla de tasa de bits UDP en la tarjeta del canal. Esa cifra se mide mediante captura de paquetes en la interfaz, directamente del cable, y no la informa el motor. Por tanto, es la única señal que no depende de que el motor diga la verdad sobre sí mismo, y es la misma medida para ambos motores. Un canal cuyo motor dice estar en marcha pero cuya tasa de bits UDP es cero no está en antena.