--- title: Protocolos de transmisión url: https://doc2.pstreamer.tv/es/manual/planning/transport.html lang: es product: Perfect Streamer version: 2.0.2.423 --- # Protocolos de transmisión Cómo entregar un flujo de un nodo a otro o a equipos de terceros. Aquí: qué protocolo elegir, cuánto cuesta en ancho de banda y latencia, qué puertos ocupa y cómo se cifra. Si lo que falla no es el canal, sino la fuente, la red o el nodo: [Redundancia: qué protege de qué](redundancy.md#planning-redundancy). ## 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. - **Conexión.** El receptor inicia la conexión, por lo que el NAT en su lado no es un obstáculo y no se requiere reenvío de puertos en el receptor. El emisor admite al receptor como Peer, por login y contraseña o por IP. - **Latencia**: el búfer del receptor, es decir, la ventana de eliminación de jitter y de retransmisión. El búfer del emisor debe ser mayor que los búferes de los receptores (latencia). - **El cambio de fuente** en el emisor no corta la conexión: el hueco lo cubre 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 (derivado del protocolo 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 un nodo de recepción con un gran número de entradas SRT en modo caller se puede desactivar el búfer del receptor SRT (TSBPD, entrega según las marcas de tiempo del emisor): de la sincronización se encargará el búfer de jitter del nodo ([Sincronización](../streamer/spts.md#streamer-spts-sync)), y la carga de CPU se reducirá notablemente. ### RIST Un protocolo abierto basado en RTP/RTCP. Funciona según el principio ARQ mediante NACK: el receptor solo informa de las pérdidas. 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 Perfect Streamer 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». > **Importante** > > **Versión beta 2.1.** Lo que se describe aquí solo existe en la versión beta 2.1: se instala desde el repositorio beta y solo con una licencia; la versión estable 2.0.2 y la versión de demostración no lo incluyen. La versión beta se suministra sin garantías y el soporte se presta en la medida de lo posible ([Programa de pruebas beta](../extras/beta.md#extras-beta)). En la versión 2.1, el FEC de entrada y de salida cumple SMPTE ST 2022-1: - los receptores estándar recuperan las pérdidas con él; - la entrada acepta FEC solo por columnas (1D) y por columnas y filas (2D), con una matriz de cualquier tamaño; - la salida solo puede enviar FEC por columnas: con una matriz 5 × 10, la sobrecarga es del 10 % en lugar del 30 %, pero la recuperación es más débil; - Pro-MPEG se combina con la segunda ruta SMPTE ST 2022-7 y con la reserva en caliente de salidas ([Redundancia: qué protege de qué](redundancy.md#planning-redundancy)). Latencia de la espera del FEC: Planificación del ancho de banda, la latencia y los puertos. ## Elección del protocolo de transmisión **En resumen.** - 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**. En detalle: | 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 | ## 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. La recuperación por FEC añade latencia en la recepción: mientras un paquete perdido espera el FEC de su matriz, la entrada retiene la salida del flujo. Cuanto mayor es la matriz y menor la tasa de bits, más larga es la espera: con una matriz grande y una tasa de bits baja son segundos, y debe cubrirlos el búfer de jitter de la entrada ([límite de espera FEC](../webui/io/network.md#webui-io-prompeg-fec-wait)). **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](../meshwork/index.md#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í | entrada: solo SPTS; de la lista de reproducción adaptativa se toma la variante por número (la primera de forma predeterminada) | | 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](../streamer/rtmp.md#streamer-rtmp); RTSP, la entrada HLS/HTTP, los archivos y dispositivos, las tuberías con nombre y las aplicaciones externas, en [Otras entradas y salidas](../streamer/other_io.md#streamer-other-io). Los ajustes detallados de cada transporte se indican en la sección [Interfaz web](../webui/index.md#webui). La distribución OTT (HLS, LL-HLS, DASH) se describe por separado en [OTT y DVR](../streamer/ott_dvr.md#streamer-ott-dvr). ## 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](../streamer/spts.md#streamer-spts). - Se admiten los flujos codificados, véase [Flujos SPTS](../streamer/spts.md#streamer-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](../streamer/spts.md#streamer-spts), y las particularidades del multiplex, en [Flujos MPTS](../streamer/mpts.md#streamer-mpts).