Planificación y protocolos de transmisión de datos¶

El núcleo de Perfect Streamer es la entrega fiable de flujos MPEG-TS entre nodos a través de una red pública con pérdida de paquetes y retardos. Esta sección describe el modelo de transmisión, los protocolos de transporte y cómo planificar un canal: elegir un protocolo y calcular el ancho de banda, la latencia y los puertos. Los ajustes detallados de los campos individuales se tratan en la descripción contextual de la interfaz web (Interfaz web), y el procesamiento del flujo en un nodo, en la sección Streamer: detalles de implementación.

Modelo de transmisión: Stream, Sender, Receiver, Peer¶

La unidad de trabajo es un flujo (Stream), un único canal MPEG-TS. Para cada flujo se configura un servidor emisor (Sender) y uno o varios receptores (Receiver); la asociación emisor-receptor se denomina Peer.

La configuración se reduce a listas de entradas (input) y salidas (output) para cada flujo:

en el emisor, input son las fuentes MPEG-TS, output es la transmisión a los receptores;
en el receptor, input es la recepción del flujo desde el emisor.

Varias entradas en la lista proporcionan redundancia de fuentes; varias salidas, la distribución simultánea de un mismo canal a muchos destinatarios y por distintos protocolos.

Para los protocolos en los que el receptor inicia la conexión, el NAT en su lado no es un obstáculo: el receptor se conecta él mismo al emisor y no se requiere reenvío de puertos entrantes en el receptor.

Protocolos Peer de transmisión fiable¶

Para la transmisión entre el emisor y el receptor hay cuatro protocolos Peer. Se dividen en dos clases según el principio de compensación de pérdidas:

ARQ (Automatic Repeat reQuest): los paquetes perdidos se retransmiten a petición del receptor. Requiere un canal de retorno y un búfer en el receptor; la profundidad de recuperación es configurable. A esta clase pertenecen PS1, SRT y RIST.
FEC (Forward Error Correction): al flujo se le añaden continuamente datos redundantes que permiten recuperar las pérdidas sin canal de retorno. A esta clase pertenece Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2).

PS1 (Perfect Stream)¶

Un protocolo de desarrollo propio basado en UDP. Funciona según el principio ARQ con retransmisión selectiva. Consume pocos recursos y transporta flujos de alta tasa de bits, incluido un MPTS de tamaño completo.

El receptor inicia la conexión, por lo que el emisor requiere autenticación: los receptores se registran como Peer con login y contraseña o se autorizan por IP. La latencia está determinada por el búfer del receptor (ventana de eliminación de jitter y de retransmisión); el búfer del emisor debe ser mayor que el de los receptores. Al cambiar la fuente activa en el emisor, los receptores no se reconectan: la interrupción se recupera mediante la retransmisión normal.

PS1 es un protocolo propietario y funciona solo entre nodos Perfect Streamer. Es la opción más adecuada para una configuración punto-multipunto: un emisor y muchos receptores.

SRT¶

Un protocolo abierto basado en UDP (UDT). Está muy extendido y compensa bien la pérdida de paquetes. Admite los modos listener y caller, por lo que es compatible con equipos SRT de terceros y servicios en la nube.

En modo listener en el emisor, varios receptores se conectan a un mismo flujo; para la autorización, los receptores se registran como Peer, y también se pueden autorizar por IP. La parte iniciadora (caller) puede estar tanto en el receptor como en el emisor. El margen de ancho de banda para la retransmisión se define como un porcentaje por encima de la tasa de bits del flujo.

En nodos de recepción muy cargados, con un gran número de entradas SRT en modo caller, se puede desactivar el almacenamiento en búfer integrado del receptor SRT (TSBPD): de la sincronización se encarga el búfer de jitter del nodo (Sincronización), lo que reduce notablemente la carga de CPU.

RIST¶

Un protocolo abierto basado en RTP/RTCP. Funciona según el principio ARQ sin ACK, solo mediante NACK. Utiliza unicast y multicast.

Se implementan los perfiles Simple y Main: Simple ocupa dos puertos UDP consecutivos (el puerto base debe ser par), Main multiplexa los datos en un solo puerto. Se admiten varias rutas (peers) con balanceo ponderado, para redundancia y agregación. En multicast puede haber muchos receptores, con autorización por IP.

Pro-MPEG FEC¶

Entrega de MPEG-TS sobre RTP con corrección de errores hacia adelante (FEC), sin canal de retorno. En PSS se implementa una matriz FEC bidimensional (filas y columnas, SMPTE 2022-2).

El flujo de paquetes RTP se agrupa en una matriz de tamaño determinado, a lo largo de cuyas filas y columnas se forman los paquetes FEC. Cuanto menor es la matriz, mejor es la recuperación, pero mayor es la sobrecarga constante. Los canales FEC ocupan dos puertos adicionales (port+2 y port+4), lo que hay que tener en cuenta al ubicar varios flujos en un mismo host o en un mismo grupo multicast.

Las ventajas son una latencia fija baja y la compatibilidad con equipos de radiodifusión profesionales. Las desventajas son el tráfico adicional constante y la escasa recuperación con grandes pérdidas (por encima de ~0,2 %), por lo que el protocolo está pensado para canales gestionados con bajas pérdidas y no para el internet público «pesado».

Elección del protocolo de transmisión¶

Protocolo	Principio	Canal de retorno	Latencia	Compatibilidad
PS1	ARQ sobre UDP	requerido	configurable	solo entre nodos Perfect Streamer
SRT	ARQ sobre UDP (UDT)	requerido	configurable	abierto; equipos SRT de terceros y nube
RIST	ARQ (NACK) sobre RTP/RTCP	requerido	configurable	abierto; equipos RIST de terceros; unicast y multicast
Pro-MPEG FEC	FEC sobre RTP	no requerido	baja, fija	abierto (SMPTE 2022-1/2); equipos de radiodifusión profesionales

Criterios de elección:

un canal entre nodos Perfect Streamer, alta tasa de bits o MPTS de tamaño completo, distribución punto-multipunto — PS1;
compatibilidad con equipos de terceros o la nube, margen de retransmisión en porcentaje sobre la tasa de bits — SRT;
un transporte abierto basado en RTP, multicast, balanceo por varias rutas — RIST;
un canal gestionado con bajas pérdidas, latencia mínima sin canal de retorno, equipos de radiodifusión profesionales — Pro-MPEG FEC.

Planificación del ancho de banda, la latencia y los puertos¶

Protocolos ARQ (PS1, SRT, RIST). Las pérdidas se compensan mediante retransmisión, por lo que hay que prever:

un canal de retorno del receptor al emisor;
un margen de ancho de banda por encima de la tasa de bits nominal, ya que los picos de pérdidas provocan picos de tráfico de retransmisión;
un búfer en el receptor para la latencia del canal. Cuanto mayor sea el búfer, más profunda será la recuperación de pérdidas, pero mayor será la latencia de extremo a extremo; como referencia, varios valores de RTT. Los flujos de baja tasa de bits requieren un búfer mayor en tiempo, para que quepan suficientes paquetes en la ventana de recuperación.

Protocolo FEC (Pro-MPEG). Los paquetes redundantes se transmiten continuamente, con independencia de las pérdidas reales, por lo que la sobrecarga es fija y depende del tamaño de la matriz FEC. No se necesita canal de retorno, la latencia es baja y fija, pero la recuperación es limitada, por lo que este transporte es adecuado para canales con bajas pérdidas.

Puertos. Cada punto de escucha necesita un puerto UDP único dentro del host o del grupo. Además, tenga en cuenta que el perfil RIST Simple ocupa dos puertos consecutivos (el puerto base par y el siguiente), y Pro-MPEG ocupa el puerto base más dos puertos FEC (port+2 y port+4). En una red Meshwork, un catálogo común de direcciones y puertos ocupados ayuda a evitar colisiones (véase Meshwork).

Cifrado de flujos¶

El cifrado AES se activa con una frase de contraseña común que se establece en ambos lados de la conexión; las frases deben coincidir. Una frase vacía significa funcionamiento sin cifrado. El cifrado no modifica la tasa de bits del flujo.

El soporte y la longitud admisible de la frase varían según el protocolo:

Protocolo	Longitud de la frase de contraseña	Particularidades
PS1	10–64 bytes	—
SRT	10–79 bytes	Además se elige la longitud de la clave: 128, 192 o 256 bits. Una frase fuera de la longitud admisible detiene la entrada o la salida con un mensaje de error explícito.
RIST	no se comprueba; se usan los primeros 127 bytes	Solo en el perfil Main. En el perfil Simple la frase de contraseña no tiene efecto.
Pro-MPEG	10–64 bytes	Extensión no estándar: al activarla no se garantiza la compatibilidad con software y equipos de terceros.

La longitud de la frase se cuenta en bytes, no en caracteres: una letra cirílica ocupa dos bytes.

Otras entradas y salidas¶

Además de los protocolos Peer, hay transportes estándar para recepción y transmisión:

Protocolo	Entrada	Salida	Nota
UDP	sí	sí	unicast/multicast, SSM, selección de interfaz; hasta 7 paquetes TS por datagrama
RTP	sí	sí	restablecimiento del orden de los paquetes desordenados
TCP	sí	—	modo cliente; recepción donde UDP está bloqueado
HLS / HTTP	sí	sí	en la recepción, la variante de la lista de reproducción adaptativa se selecciona mediante un número configurable (el primero de forma predeterminada); la entrada es solo para SPTS
RTSP	sí	—	cámaras IP y servidores RTSP; remultiplexación automática a MPEG-TS; solo para SPTS
RTMP / RTMPS	sí	sí	publicación en receptores RTMP de terceros; H.264 y HEVC; solo para SPTS
file / device	sí	sí	grabación en un archivo TS y salida MPEG-TS a un dispositivo (por ejemplo, ASI); reproducción en bucle desde un archivo
pipe (FIFO)	sí	sí	puente a un proceso externo mediante una tubería con nombre
std (aplicación externa)	sí	sí	puente a protocolos no estándar mediante una aplicación de consola

La publicación y la recepción RTMP se describen en Publicación y recepción RTMP; RTSP, la entrada HLS/HTTP, los archivos y dispositivos, las tuberías con nombre y las aplicaciones externas, en Otras entradas y salidas. Los ajustes detallados de cada transporte se indican en la sección Interfaz web. La distribución OTT (HLS, LL-HLS, DASH) se describe por separado en OTT y DVR.

Redundancia de fuentes y distribución¶

Redundancia. Para un flujo se pueden definir varias entradas; solo una está activa en cada momento. Cuando la entrada activa falla, el flujo cambia automáticamente a la siguiente de la lista y, al restablecerse, puede volver a la fuente prioritaria. Así se pueden planificar de antemano las fuentes principal y de reserva de un canal; los ajustes detallados de la conmutación de entradas se describen en Flujos SPTS.

Distribución. Varias salidas en un mismo flujo distribuyen un mismo canal a muchos destinatarios y por distintos protocolos simultáneamente.

Requisitos del flujo de entrada¶

Conformidad con ISO/IEC 13818-1, Single Program (SPTS) o Multi Program Transport Stream (MPTS).
El conjunto de pistas viene determinado por el tipo de contenido seleccionado del flujo SPTS, véase Flujos SPTS.
Se admiten los flujos codificados, véase Flujos SPTS.
Para la sincronización, el flujo debe contener marcas PCR válidas.

El filtrado, la modificación y los modos de tasa de bits del flujo de entrada se describen en Flujos SPTS, y las particularidades del multiplex, en Flujos MPTS.