srt
v1.5.4
Acerca de la TER | Características | Empezando | Instrucciones de construcción | Aplicaciones y herramientas de muestra | Contribuir | Licencia | Lanzamientos
Secure Reliable Transport (SRT) es un protocolo de transporte para transmisión de video y audio en vivo con latencia ultrabaja (menos de un segundo), así como para transferencias genéricas de datos masivos 1 . SRT está disponible como tecnología de código abierto con el código en GitHub, un borrador de Internet publicado y una creciente comunidad de usuarios de SRT.
SRT se aplica a los puntos finales de contribución y distribución como parte de un flujo de trabajo de transmisión de video para ofrecer video de la mejor calidad y menor latencia en todo momento.
| Seguro | Cifra transmisiones de video |
| Confiable | Se recupera de una pérdida grave de paquetes |
| Transporte | Se adapta dinámicamente a las condiciones cambiantes de la red |
En configuraciones de transmisión en vivo, el protocolo SRT mantiene una latencia constante de un extremo a otro. Esto permite recrear las características de la señal de la transmisión en vivo en el lado del receptor, reduciendo la necesidad de almacenamiento en búfer. A medida que los paquetes se transmiten desde el origen al destino, SRT detecta y se adapta a las condiciones de la red en tiempo real entre los dos puntos finales. Ayuda a compensar la fluctuación y las fluctuaciones del ancho de banda debido a la congestión en redes ruidosas.
SRT implementa cifrado AES para proteger la carga útil de los flujos de medios y ofrece varios mecanismos de recuperación de errores para minimizar la pérdida de paquetes típica de las conexiones a Internet, de las cuales la solicitud de repetición automática (ARQ) es el método principal. Con ARQ, cuando un receptor detecta que falta un paquete, envía una alerta al remitente solicitando la retransmisión de este paquete faltante. El protocolo también admite la corrección de errores de reenvío (FEC) y la vinculación de conexiones, que agrega una protección de transmisión perfecta y una conmutación por error sin interrupciones.
Para obtener más información sobre el protocolo, suscríbase al blog de Innovation Labs en
Para hacer una pregunta, únete a la conversación en el canal #desarrollo en 
? Haga clic en el botón ► para expandir la descripción de una función.
No importa cuán poco confiable sea su red, SRT puede recuperarse de fluctuaciones y pérdidas graves de paquetes, lo que garantiza la integridad y la calidad de sus transmisiones de video.
La corrección de errores de transmisión de SRT se puede configurar para adaptarse a las condiciones de implementación del usuario. Aprovechando el desarrollo de las comunicaciones IP en tiempo real para ampliar las prácticas tradicionales de recuperación de errores de red, SRT ofrece medios con una latencia significativamente menor que TCP/IP, al tiempo que ofrece la velocidad de transmisión UDP con una confiabilidad enormemente mejorada.
A diferencia de otros protocolos de transmisión que solo admiten formatos de audio y video específicos, SRT es independiente de la carga útil. Debido a que SRT opera a nivel de transporte de red, actuando como un contenedor alrededor de su contenido, puede transportar cualquier tipo de formato de video, códec, resolución o velocidad de fotogramas.
El proceso de protocolo de enlace utilizado por SRT admite conexiones salientes sin los riesgos y peligros potenciales de que se abran puertos exteriores permanentes en un firewall, manteniendo así las políticas de seguridad de la LAN corporativa y minimizando la necesidad de intervención de TI.
Utilizando cifrado AES de 128/192/256 bits en el que confían gobiernos y organizaciones de todo el mundo, SRT garantiza que el contenido valioso esté protegido de extremo a extremo desde su contribución hasta la distribución, de modo que ninguna parte no autorizada pueda escucharlo.
SRT 1.4 ve la introducción de la API de filtro de paquetes . Este mecanismo permite realizar un procesamiento personalizado en paquetes de red en el lado del remitente antes de enviarlos y en el lado del receptor una vez recibidos de la red. La API permite a los usuarios escribir su propio complemento, ampliando así aún más las capacidades del protocolo SRT con todo tipo de filtrado de paquetes diferentes. Los usuarios pueden manipular los datos del filtro de paquetes resultantes de cualquier forma, como para cifrado personalizado, inspección de paquetes o acceso a datos antes de enviarlos.
El primer complemento creado como ejemplo de lo que se puede lograr con la API de filtro de paquetes es para la corrección de errores de reenvío (FEC) que, en ciertos casos de uso, puede ofrecer una latencia ligeramente menor que la solicitud de repetición automática (ARQ). Este complemento permite tres modos diferentes:
Sólo ARQ: retransmite paquetes perdidos,
Solo FEC: proporciona la sobrecarga necesaria para la recuperación de FEC en el lado del receptor,
FEC y ARQ: retransmite paquetes perdidos que FEC no logra recuperar.
De manera similar a SMPTE-2022-7 en redes administradas, Connection Bonding agrega una protección de transmisión perfecta y una conmutación por error sin interrupciones al protocolo SRT. Esta tecnología se basa en más de una ruta de red IP para evitar interrupciones en las transmisiones de video en vivo en caso de congestión o cortes de la red, manteniendo la continuidad del servicio.
Esto se logra utilizando los grupos de sockets introducidos en SRT v1.5. El concepto general de grupos de sockets significa tener un grupo que contiene múltiples sockets, donde se aplica al grupo una operación para enviar una señal de datos. Los enchufes individuales dentro del grupo se harán cargo de esta operación y harán lo necesario para entregar la señal al receptor.
Se admiten dos modos:
Difusión: en el modo Difusión , los datos se envían de forma redundante a través de todos los enlaces de miembros de un grupo. Si uno de los enlaces falla o experimenta fluctuaciones en la red y/o pérdida de paquetes, los datos faltantes se recibirán a través de otro enlace del grupo. Los paquetes redundantes simplemente se descartan en el lado del receptor.
Principal/Respaldo: en el modo Principal/Respaldo , solo se utiliza un enlace (principal) a la vez para la transmisión de datos mientras que otras conexiones (de respaldo) están en espera para garantizar que la transmisión continúe si falla el enlace principal. El objetivo del modo Principal/Respaldo es identificar una posible rotura de enlace antes de que ocurra, proporcionando así una ventana de tiempo dentro de la cual cambiar sin problemas a uno de los enlaces de respaldo.
El control de acceso permite que la aplicación ascendente asigne un ID de transmisión a transmisiones SRT individuales. Al utilizar una ID de transmisión única, ya sea generada automáticamente o personalizada, la aplicación ascendente puede enviar múltiples transmisiones SRT a una única dirección IP y puerto UDP. Luego, un receptor puede utilizar los ID de transmisión para identificar y diferenciar entre transmisiones de ingesta, aplicar métodos de acceso con contraseña de usuario y, en algunos casos, incluso aplicar automatización basada en el nombre del ID de transmisión. Por ejemplo, la contribución podría enviarse a un flujo de trabajo de producción de vídeo y el seguimiento a un servicio de seguimiento.
Para las emisoras, Stream ID es clave para reemplazar RTMP para la ingesta de transmisiones de video, especialmente contenido HEVC/H.265, en servicios en la nube o CDN que tienen un único conector IP (dirección + puerto) abierto para video entrante.
| La API SRT | Borrador de Internet del IETF | Aplicaciones de muestra |
| Documentación de referencia para la API de la biblioteca SRT | El borrador del protocolo SRT de Internet | Instrucciones para usar aplicaciones de prueba ( srt-live-transmit , srt-file-transmit , etc.) |
| Descripción técnica de SRT | Guía de implementación de SRT | Libro de cocina SRT |
| Descripción técnica del primer borrador (precursor del borrador de Internet) | Una descripción general completa del protocolo con pautas de implementación. | Notas de desarrollo sobre el protocolo SRT |
| Blog de laboratorios de innovación | Canal de YouTube de SRTLab | Flojo |
| El blog en Medium con artículos técnicos relacionados con SRT | Canal técnico de YouTube con vídeos útiles. | Canales de Slack para obtener las últimas actualizaciones y hacer preguntas Únase a SRT Alliance en Slack |
¿Por qué TRE? - Una breve historia y fundamento de la TER por Marc Cymontkowski.
RTMP frente a SRT: documento técnico sobre comparación de latencia y ancho de banda máximo.
Documentación en GitHub con documentos API SRT, descripciones de características, etc.
El borrador de Internet del protocolo SRT: Datatracker | Última versión | Última copia de trabajo | Repositorio de GitHub
Linux (Ubuntu/CentOS) | Ventanas | MacOS | iOS | Androide | Administradores de paquetes
Compilador compatible con C++03 o superior.
CMake 2.8.12 o superior como sistema de compilación.
OpenSSL 1.1 para habilitar el cifrado; de lo contrario, compílelo con -DENABLE_ENCRYPTION=OFF .
El subproceso múltiple lo proporciona cualquiera de los siguientes:
C++11: biblioteca estándar ( std por -DENABLE_STDCXX_SYNC=ON opción CMake),
C++03: Pthreads (para sistemas POSIX está integrado, para Windows hay una biblioteca portada).
Tcl 8.5 es opcional y lo utiliza el script ./configure . De lo contrario, utilice CMake directamente.
Para obtener descripciones detalladas del sistema de compilación y las opciones, lea el documento Opciones de compilación de SRT.
El repositorio actual proporciona aplicaciones de muestra y ejemplos de código que demuestran el uso de la API de la biblioteca SRT. Entre ellas se encuentran srt-live-transmit , srt-file-transmit y otras aplicaciones. La documentación respectiva se puede encontrar aquí. Tenga en cuenta que todos los ejemplos se proporcionan con fines instructivos y no deben utilizarse en un entorno de producción.
La utilidad srt-xtransmit se utiliza activamente para pruebas internas y evaluación del rendimiento. Entre otras características, admite la generación de carga útil ficticia, enrutamiento de tráfico y vinculación de conexiones. Hay detalles adicionales disponibles en el repositorio srt-xtransmit .
Las herramientas de Python que pueden resultar útiles durante el desarrollo son:
srt-stats-plotting : script diseñado para trazar gráficos basados en estadísticas SRT .csv .
lib-tcpdump-processing : una biblioteca diseñada para procesar archivos de seguimiento .pcap(ng) tcpdump o Wireshark y extraer paquetes SRT de interés para su posterior análisis.
lib-srt-utils : una biblioteca de Python que contiene código de soporte para ejecutar pruebas SRT basadas en una configuración de experimento.
Cualquiera es bienvenido a contribuir. Si decide participar, tómese un momento para revisar las pautas:
Guía del desarrollador de SRT
Contribuyendo
Problemas de informes
Para obtener información sobre cómo contribuir al borrador de Internet o enviar problemas, vaya al siguiente repositorio. El repositorio para contribuir en SRT CookBook se puede encontrar aquí.
Al contribuir con código al proyecto SRT, acepta otorgar la licencia de su contribución bajo la licencia MPLv2.0.
Notas de la versión
Versionado SRT
El término "transmisión en vivo" se refiere a la transmisión continua de datos (MPEG-TS o equivalente) con gestión de latencia. La transmisión en vivo basada en la segmentación y transmisión de archivos como en el protocolo HTTP Live Streaming (HLS) (como se describe en RFC8216) no forma parte de este caso de uso. En este caso se debe considerar la transmisión de archivos en modo de mensaje o de búfer. Consulte la Sección 7. Mejores prácticas y consejos de configuración para la transmisión de datos a través de SRT del borrador de Internet para obtener más detalles. Tenga en cuenta que SRT es independiente del contenido, lo que significa que cualquier tipo de datos se puede transmitir a través de su carga útil. ↩
