FAQ

Respuestas a las preguntas que surgen con más frecuencia en la operación: la compatibilidad de SRT con software de terceros y la recepción de multicast con tasas de bits elevadas.

SRT: autorización mediante usuario y contraseña en software de terceros

Entre dos nodos de Perfect Streamer la autorización SRT se configura con los propios campos de la entrada y de la salida (SRT). El funcionamiento con otro software no está garantizado: el parámetro stream ID no está estandarizado y cada software lo implementa de una manera distinta.

El mecanismo de compatibilidad es común: la parte receptora toma el stream ID del cliente que se conecta y busca con él un login en la lista de logins locales (Usuario: añadir y editar). El campo «Usuario» debe coincidir íntegramente con el valor del stream ID. Por ejemplo, con la URL

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

en el campo «Usuario» se introduce

!#::u=1234567890,password=1234567890

La sintaxis del stream ID carece de importancia para Perfect Streamer: la cadena no se descompone en partes, sino que se compara íntegramente. Las excepciones son tres caracteres que el propio nodo interpreta:

  • | — separador: la parte de la cadena anterior al primer carácter de este tipo se considera el usuario, y el resto, la contraseña del login local;

  • * — el stream ID no está definido; el cliente se autoriza por dirección, es decir, mediante un login local con el atributo «Cuenta de dirección IP»;

  • @ al principio de la cadena está reservado para la autorización de servicio entre los nodos de un dominio Meshwork.

Perfect Streamer no limita la longitud del stream ID: la limitación procede de la biblioteca SRT y es de 512 bytes, incluido el cero final. No conviene transmitir valores de más de unos 500 caracteres: una cadena demasiado larga o bien corta la conexión, o bien se envía vacía sin ningún mensaje de error.

Cada software forma el stream ID a su manera, así que, si la recepción por la URL no funciona, active en la salida SRT el ajuste adicional Trace. En el registro del flujo que acepta la conexión aparecerán la dirección del cliente, el stream ID recibido y el motivo del rechazo; esa línea muestra qué envió realmente la otra parte. Después se puede corregir el stream ID: por ejemplo, eliminar del principio de la cadena los caracteres sobrantes que impiden la transmisión del valor.

Recomendaciones para trabajar con multicast UDP

Objetivo. Recibir de forma estable multicast UDP con una tasa de bits total de varios cientos de Mbps (1 Gbps o más) en un solo servidor.

Problema. En la recepción con tarjetas de red de interfaz RJ-45, a medida que el tráfico supera los varios cientos de megabits comienzan pérdidas crecientes de paquetes de multicast. El ajuste fino de la tarjeta no ayuda: las versiones actuales de los sistemas operativos ya emplean los valores óptimos. Las tarjetas basadas en mejores chips tampoco eliminan el problema, sobre todo por encima de 500 Mbps. Tampoco ayuda el bonding de dos tarjetas: un mismo grupo multicast llega siempre a un único canal físico y a una única cola de recepción, por lo que se agrega el ancho de banda total y no el margen de un flujo concreto.

Solución. La experiencia en producción indica que para la recepción y la transmisión de multicast UDP conviene utilizar tarjetas de red de 10 gigabits con interfaz SFP+. Basta con una tarjeta económica del nivel de la Intel X520-DA1/2 (Intel 82599ES): en nuestras pruebas elimina la pérdida de paquetes con tráfico de multicast superior a 1 Gbps. Además, la carga de la CPU se reduce notablemente: el procesamiento de las interrupciones y de las colas de recepción resulta más barato en esas tarjetas.

Téngalo en cuenta durante el diagnóstico: el contador de errores de recepción recv-err de las estadísticas de la entrada cuenta únicamente los errores de lectura del socket y la pérdida de sincronización con el límite del paquete TS. Las pérdidas provocadas por el desbordamiento del búfer de recepción del kernel no llegan a la aplicación y no aparecen en ese contador: se ven con el comando netstat -su (línea RcvbufErrors) y por los errores de continuidad en el analizador de flujo (Analizador).

Recomendaciones para la configuración de la red para multicast

La sección se refiere a las entradas de red UDP / RTP y Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2). Estos parámetros no afectan a la recepción SRT: la biblioteca SRT establece por sí misma el tamaño del búfer, mientras que el retardo y el margen para la retransmisión se configuran en la propia entrada (SRT).

El tamaño del búfer de recepción del socket se establece con el ajuste adicional de la entrada Socket buffer (bytes). De forma predeterminada es cero: el nodo no solicita nada y el socket recibe el tamaño de búfer definido en el sistema por el parámetro net.core.rmem_default. El valor introducido es una solicitud, no un resultado. En cuanto se define de forma explícita, entra en vigor el límite superior net.core.rmem_max y el kernel recorta la solicitud hasta ese límite, informando de éxito en cualquier caso. Por eso el límite superior se eleva antes de establecer el tamaño del búfer en la entrada.

En una entrada en funcionamiento, el nodo muestra en dos lugares cuánto búfer se ha concedido realmente: en las estadísticas del flujo, el bloque «Enlace de entrada» incluye la línea «Búfer del socket (asignado)» (Estadísticas del flujo), y en el editor de la entrada (Editor de entrada y salida) el tamaño asignado se muestra debajo del propio campo, con una advertencia al lado si la solicitud no cupo bajo el límite superior. En ambos lugares se muestra el volumen útil que obtuvo el socket y no lo que está escrito en el campo: debajo del campo, en bytes, para poder compararlo directamente; en las estadísticas, redondeado. La ausencia de la línea significa que no hay socket: la entrada está detenida. Nunca significa un búfer nulo.

El valor de las estadísticas se actualiza junto con los demás indicadores, mientras que debajo del campo se lee una sola vez, al abrir la ventana del flujo. Por eso, tras guardar un tamaño nuevo, la línea situada bajo el campo desaparece: al guardar se vuelve a abrir el socket y el número anterior ya no le corresponde. Para ver lo concedido al nuevo socket se cierra y se vuelve a abrir la ventana del flujo, o se consultan las estadísticas, donde el valor se actualiza en directo.

Los parámetros se definen en un archivo aparte en /etc/sysctl.d/:

cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF

Aplicar:

sudo sysctl --system

El valor rmem_max es solo un límite superior; no se reserva memoria por él. El valor rmem_default se aplica a todos los sockets UDP del sistema; si ese tamaño global no es deseable, déjelo sin cambios y defina Socket buffer (bytes) solo en las entradas que realmente lo necesiten. El cero y un número indicado explícitamente no son equivalentes ni siquiera con la misma magnitud: el kernel duplica el tamaño solicitado, mientras que el tamaño predeterminado lo toma tal cual, y en ambos casos la mitad de lo concedido se destina a la contabilidad interna de los paquetes. Por eso, en un sistema con el mismo rmem_default, una entrada con un número indicado explícitamente obtiene el doble de espacio útil que una entrada con cero.

La referencia para el cálculo es la tasa de bits del flujo multiplicada por la pausa admisible en el servicio del socket. Así, 8 MB cubren unos 64 ms a 1 Gbps. La referencia fija el volumen útil, es decir, el número del campo de la entrada; el límite superior net.core.rmem_max debe ser entonces el doble del mayor de esos números. El par de valores recomendado más arriba cumple esa condición.

SRT: recepción en software de terceros con su propio stream ID

Ejemplo de URL SRT para la recepción en un software de terceros que, al trabajar con SRT, transmite por sí mismo el stream ID:

srt://Stream_IP:port?streamid=client1

Aquí client1 es el nombre del login local en la pestaña «Accesos locales» (Usuario: añadir y editar). Al añadir el login local basta con indicar solo el nombre de usuario. Si ese software transmite su propio stream ID y la URL no indica el login, el flujo no se recibe: Perfect Streamer no encuentra el login local y no entrega el flujo.

Del mismo modo, el stream ID se define en formato de usuario y contraseña: el campo «Usuario» del login local es igual a !#::u=1234567890,password=1234567890 y en el software de terceros se indica la URL:

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

El stream ID también se puede definir en formato de dirección IP: para ello se activa en el login local el atributo «Cuenta de dirección IP» y en el campo de dirección se introduce:

  • 192.168.1.1 — una única IP;

  • 192.168.1.1-192.168.1.254 — un rango de IP.

En ambos casos, la URL para la recepción por IP en el software de terceros es: srt://Stream_IP:port?streamid=*

El flujo queda vinculado a la dirección IP del cliente: la recepción a través de esta URL solo es posible desde la dirección IP indicada (o desde el rango indicado).