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 proporcionan 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, un receptor tras NAT se conecta él mismo al emisor: no se requiere reenvío de puertos entrantes en su lado.

Protocolos Peer de transmisión fiable¶

Para la transmisión entre el emisor y el receptor hay disponibles 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 / RTP+FEC.

PS1 (Perfect Stream)¶

Un protocolo de desarrollo propio basado en UDP. Funciona según el principio ARQ con retransmisión selectiva. Se distingue por un bajo consumo de 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 usuario 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 retransmisión normal, sin una reconexión visible.

PS1 es un protocolo propietario y funciona solo entre nodos Perfect Streamer. Es especialmente eficiente en una configuración punto-multipunto: un emisor y muchos receptores.

SRT¶

Un protocolo abierto basado en UDP (UDT). Está ampliamente extendido y compensa bien la pérdida de paquetes. Admite los modos listener y caller, lo que proporciona compatibilidad 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 está disponible la autorización 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 densos 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, lo que garantiza una alta eficiencia. 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 / RTP+FEC (SMPTE 2022-1/2)¶

Entrega de MPEG-TS sobre RTP con corrección de errores hacia adelante (FEC), sin canal de retorno. El protocolo se conoce también como Pro-MPEG COP3. 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 / RTP+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, configuración flexible del margen de retransmisión — 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 / RTP+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 — 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 / RTP+FEC). 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: este transporte es 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¶

Todos los protocolos Peer admiten cifrado AES mediante una frase de contraseña común introducida en ambos lados. Para SRT se selecciona además la longitud de clave (128, 192 o 256 bits). El cifrado no altera la tasa de bits del flujo.

Para Pro-MPEG, el cifrado es una extensión no estándar, por lo que al activarlo no se garantiza la compatibilidad con software y equipos de terceros.

Otras entradas y salidas¶

Además de los protocolos Peer, están disponibles 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; auto-remux 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 a un dispositivo (incluido SDI); 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 canalizaciones 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. Esto permite 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 permiten distribuir un mismo canal a muchos destinatarios a la vez 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.
Los flujos aleatorizados (codificados) son compatibles, 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 multiplexado en Flujos MPTS.