La lista actual de protocolos de transporte de video disponibles es larga y puede ser confusa, desde RTMP a SRT, HLS, MPEG-DASH y CMAF. La intención de este artículo es explicar qué es lo que hace un protocolo de transporte de video y dónde se usa en la cadena de entrega de video, así como sus ventajas y defectos.

¿Qué es un protocolo de transporte?

Básicamente, es un protocolo de comunicación responsable de establecer una conexión y entregar datos a través de conexiones de red. Más específicamente, los protocolos de transporte ocupan capa 4 de la O pluma S ystems I Interconexión (OSI) modelo de protocolo. El modelo OSI de la Organización Internacional de Normalización sirve como plantilla estándar para describir una pila de protocolos de red. Los protocolos de este nivel proporcionan sesiones orientadas a la conexión y entrega de datos confiable. Los protocolos de transporte brindan garantías de entrega de datos que son esenciales para transferencias de archivos y aplicaciones de misión crítica. Es importante destacar que los diferentes protocolos de transporte pueden admitir una variedad de capacidades opcionales que incluyen recuperación de errores, control de flujo y soporte para retransmisión.

¿Para qué se usan los protocolos de transporte?

En los flujos de trabajo de video, los protocolos de transporte se usan para contribución, producción, distribución y entrega. El diagrama abajo ilustra estas tres distintas fases en la cadena de entrega de video en vivo. A la contribución se le refiere como “la primera milla” y “la última milla”.  Esta fase de la última milla es cuando los streams de video se entregan directamente al espectador en su dispositivo de preferencia o en su pantalla de TV.  Los protocolos de entrega más sonados son HLS, MPEG-DASH y CMAF, los cuales son basados en HTTP Y no son aplicables para la primera milla de streaming de video ya que agregan demasiada latencia para producciones en vivo.

Además existen protocolos propietarios disponibles que poseen las compañías y usualmente requieren de una licencia para ser usados por el cliente o terceros.  Los retos de usar un protocolo propietario cerrado son que puede ser costoso (requieren pagos mensuales), podría evitar la interoperabilidad entre dispositivos y siempre hay un riesgo si un producto es descontinuado o queda fuera de línea.

PROTOCOLOS DE CAPA DE APLICACIÓN PARA STREAMING DE VIDEO.

RTMP- Real-Time Messaging Protocol

Inicialmente se desarrolló RTMP como un protocolo propietario por Macromedia (ahora Adobe) y se desarrolló para para streaming de video y audio en tiempo real y transmisión datos entre un servidor y un reproductor Flash. Aunque Adobe anunció que ya no soportaría Flash, el protocolo RTMP continúa siendo usado comúnmente para streaming en vivo, entre flujos de trabajo de producción. 

RTMP es una tecnología de streaming continuo y depende del reconocimiento reportado por el receptor. Sin embargo este reconocimiento no es reportado al que envía inmediatamente, lo reporta después de una secuencia de paquetes recibida. Si existe una pérdida de paquetes en la secuencia, se retransmite la secuencia completa de paquetes. Este proceso de paquetes puede incrementar la latencia dramáticamente. Además RTMP, no soporta codificación HEVC o resolución avanzada por lo que no puede ser usado en altos bitrates debido a limitación en el ancho de banda.

RTP – Protocolo de transporte en tiempo real

RTP es un protocolo de Internet para la transmisión en tiempo real de datos multimedia en modo unidifusión o multidifusión. RTP se ejecuta sobre UDP para una latencia baja y, aunque no incluye recuperación de pérdida de paquetes, tiene mecanismos para compensar cualquier pérdida menor de datos cuando se usa junto con el Protocolo de control de RTP (RTCP). Mientras que RTP transporta los flujos de medios (audio y video), RTCP se usa para monitorear las estadísticas de transmisión y proporcionar retroalimentación de calidad de servicio (QoS) (es decir, paquetes perdidos, tiempo de ida y vuelta y jitter) y ayuda a sincronizar múltiples flujos. 

RTP también es el protocolo de transporte utilizado por WebRTC , un protocolo peer-to-peer de marco abierto con una API de JavaScript para compartir videos entre navegadores. Aunque funciona bien para videoconferencias entre grupos pequeños o para transmisión de multidifusión en una red cerrada, WebRTC tiene una capacidad limitada para escalar y transmitir de manera confiable video con calidad de transmisión.

RTSP – Protocolo de transmisión en tiempo real

RTSP es un protocolo de control de la capa de aplicación que se comunica directamente con un servidor de transmisión de video. RTSP permite a los espectadores pausar, reproducir y detener de forma remota las transmisiones de video a través de Internet sin necesidad de descargas locales. RTSP fue utilizado principalmente por RealNetworks RealPlayer y todavía se está aplicando para varios usos, incluso para transmisiones de cámaras remotas, educación en línea y radio por Internet. RTSP requiere un servidor dedicado para la transmisión y no admite el cifrado de contenido o la retransmisión de paquetes perdidos, ya que se basa en el protocolo RTP junto con RTCP para la entrega de transmisión de medios.

SRT – Transporte de video seguro y confiable

Pionero en Haivision, SRT se desarrolló para ofrecer el rendimiento de baja latencia de UDP en redes con pérdidas con un módulo emisor / receptor de alto rendimiento que maximiza el ancho de banda disponible. SRT, independiente del códec, de código abierto y libre de regalías, garantiza que la cadencia del paquete (señal de video comprimida) que ingresa a la red es idéntica a la que se recibe en el decodificador, simplificando drásticamente el proceso de decodificación. 

SRT ofrece funciones adicionales, incluido el cifrado AES nativo, de modo que la seguridad de la transmisión se gestiona a nivel de enlace. También permite a los usuarios atravesar fácilmente los cortafuegos a lo largo del flujo de trabajo al admitir los modos de envío y recepción (a diferencia de los modos RTMPy HTTP que solo admiten un modo único). Además, SRT puede reunir varios flujos de datos, audio y video en un solo flujo SRT para admitir flujos de trabajo muy complejos sin sobrecargar a los administradores de red. Dentro del módulo emisor / receptor, incorporamos la capacidad de detectar el rendimiento de la red con respecto a la latencia, la pérdida de paquetes, la fluctuación y el ancho de banda disponible. Las integraciones avanzadas de SRT pueden usar esta información para guiar el inicio de la transmisión o incluso para adaptar los puntos finales a las condiciones cambiantes de la red.

WebRTC: comunicación web en tiempo real

WebRTC es una tecnología de código abierto creada por Google y estandarizada en enero de 2021 que se utiliza a menudo para videoconferencias. WebRTC se compone de tres API HTML5 (“getUserMedia”, “RTCPeerConnection” y “RTCDataChannel”) para ofrecer transmisión de voz y video de baja latencia entre navegadores lo suficientemente rápido como para imitar la comunicación en persona. También permite la captura y reproducción de video y audio sin la necesidad de descargar e instalar complementos adicionales. Sin embargo, uno de los inconvenientes de utilizar WebRTC es la falta de escalabilidad, ya que los proyectos a gran escala con una gran cantidad de usuarios conectados requerirán un servidor, una solución o un servicio en la nube adicionales para aliviar el estrés del navegador.  

WebRTC es compatible con todos los navegadores principales, incluidos Microsoft Edge, Google Chrome y Mozilla Firefox, y se utiliza para impulsar aplicaciones de chat de video populares como Microsoft Teams, Facebook Messenger y Google Hangouts.   

HLS – Transmisión en directo HTTP

HLS es un protocolo de transmisión de velocidad de bits adaptable de Apple lanzado en 2009 que se utiliza principalmente para la última milla de una entrega de video. El contenido de HLS se envía desde un servidor web (o servidor de origen) y, a menudo, a través de un CDN antes de que llegue a un reproductor de video. El contenido de video HLS se divide en fragmentos separados, generalmente de 10 segundos de duración, que se duplican y codifican en diferentes velocidades de bits y resoluciones (o perfiles) en paralelo. Como protocolo de tasa de bits adaptativa, el reproductor de video busca cambios en las condiciones del ancho de banda y, si hay fluctuaciones, puede cambiar sin problemas al perfil ABR más adecuado en ese momento. HLS admite video codificado con los códecs H.264 o H.265 (HEVC).   

Con la tecnología Flash de Adobe ahora al final de su vida útil, el video en línea entregado por HLS y reproducido a través de reproductores HTML5 se ha convertido en el método principal de entrega de video a través de Internet con soporte en los principales navegadores web, dispositivos móviles, reproductores multimedia, servidores e incluso algunos consumidores. decodificadores. Como tecnología de Apple, HLS es el principal protocolo de entrega para dispositivos iOS.  

MPEG-DASH: transmisión dinámica adaptativa a través de HTTP

MPEG-DASH es un protocolo de código abierto desarrollado por Moving Pictures Expert Group (MPEG) y se convirtió en un borrador de estándar internacional en noviembre de 2011. MPEG-DASH se usa principalmente para entregar contenido de video en vivo y bajo demanda a través de Internet a los espectadores. -cajas superiores, teléfonos inteligentes, tabletas y otros dispositivos. MPEG-DASH tiene el mismo enfoque para la entrega de reproductores que HLS, ya que también divide el contenido en partes o fragmentos con una cascada de diferentes codificaciones que lo hacen adaptable a la entrega de video de última milla sobre la parte superior (OTT).  

MPEG-DASH es independiente del códec. Esto significa que MPEG-DASH no se limita al uso de códecs H.264 o HEVC, sino que también puede admitir otros como VP8 o VP9, ​​que podrían ser ventajosos para transmisiones de mayor calidad con tasas de bits más bajas. Como protocolo ABR alternativo a HLS, MPEG-DASH se usa ampliamente en dispositivos Android.  

En Punto Ti  asesoramos a nuestros clientes para la correcta implementación de codificadores y decodificadores Haivision de acuerdo cada necesidad.  Solicita tu demostración aquí.

Autor

Lina Nikols

Especialista en contenido, con casi 20 años de experiencia combinada en redacción de textos publicitarios y marketing. Bien versada en escribir sobre una amplia gama de temas, desde tecnología de consumo hasta soluciones de software empresarial. (Reproducido del blog de www.haivision.com)