Protocolos de transmisión en directo: Todo lo que necesita saber [2023 Update]

La retransmisión en directo es un fenómeno que sigue creciendo. De hecho, una enorme El 80% de las personas de este estudio dicen que prefieren ver una retransmisión en directo que leer una entrada de blog. Además, reproducción de vídeo en directo reciben un 27% más de minutos vistos en comparación con el vídeo estándar.

A medida que el vídeo en directo sigue convirtiéndose en el tipo de medio de comunicación preferido, las empresas y los organismos de radiodifusión han gravitado hacia su aplicación a través de plataformas profesionales de profesionales para sus espectadores. Pero cuando se trata de retransmitir en directo, hay mucha tecnología entre bastidores. En consecuencia, establecer en directo los protocolos de transmisión adecuados puede ser una tarea desalentadora.

Afortunadamente, vamos a aclarar los distintos aspectos importantes de la retransmisión en directo. Hablaremos de los protocolos de streaming específicos y en qué consisten. Vamos a detallar los seis protocolos de retransmisión en directo más utilizados por los profesionales de la radiodifusión en la actualidad. Y compararemos algunas tecnologías similares relacionadas con transmisión en directo incluidos códecs y formatos de transmisión de vídeo. Al final, aprenderá cuál es el mejor protocolo de streaming para su aplicación específica.

Índice

• Conceptos básicos de los protocolos de streaming
• Protocolo de retransmisión en directo frente a códec
• Protocolos de streaming frente a formatos de streaming de vídeo
• 6 Protocolos comunes de streaming de vídeo
• Reflexiones finales

Conceptos básicos de los protocolos de streaming

Los protocolos de transmisión constituyen uno de los pilares de la radiodifusión profesional.

Un protocolo de streaming, también conocido como protocolo de difusión, es un método estandarizado de entrega de diferentes tipos de medios (normalmente vídeo o audio) a través de Internet.

Básicamente, un protocolo de transmisión de vídeo envía “trozos” de contenido de un dispositivo a otro. También define el método para “reensamblar” estos trozos en contenido reproducible en el otro extremo.

Esto apunta a un aspecto importante de los protocolos de streaming: tanto el dispositivo de salida como el espectador tienen que ser compatibles con el protocolo para que funcione.

Por ejemplo, si envías un flujo en MPEG-DASH, pero el reproductor de vídeo del dispositivo al que transmites no es compatible con MPEG-DASH, tu flujo no funcionará.

Por eso es importante la normalización. En la actualidad se utilizan varios protocolos de transmisión multimedia, que veremos en detalle más adelante. Seis de los protocolos más comunes son:

1. Retransmisión en directo HTTP (HLS)
2. Protocolo de mensajería en tiempo real (RTMP)
3. Transporte seguro y fiable (SRT)
4. Streaming adaptativo dinámico a través de HTTP (MPEG-DASH)
5. Microsoft Smooth Streaming (MSS)
6. Comunicación web en tiempo real (WebRTC)

Antes de entrar en los protocolos específicos, aclaremos algunas posibles confusiones en el ámbito de los protocolos y códecs de transmisión en directo.

Protocolo de retransmisión en directo frente a códec

“Códec” es una palabra que aparece a menudo en el mundo de la retransmisión en directo y, a primera vista, la definición parece similar a la de un protocolo de vídeo. Sin embargo, un protocolo de transmisión en directo es diferente de un códec de vídeo

Codec significa “codificador/decodificador”. Es una herramienta para reducir el tamaño de los archivos de vídeo. Los archivos de vídeo RAW se componen de muchas imágenes fijas reproducidas rápidamente en secuencia (normalmente a 30 fotogramas por segundo). Ahora, imagina treinta fotos de dos megapíxeles cada una. Eso es mucho espacio de almacenamiento. Ahí es donde entra en juego un códec.

La solución para ahorrar espacio es la compresión, que utiliza algoritmos matemáticos para descartar datos que no son muy importantes. Por ejemplo, si una esquina del vídeo está en negro y permanece en negro durante unos segundos, puede desechar los datos de píxeles individuales y limitarse a incluir una referencia en su lugar.

Una vez que el archivo ha llegado a su destino, se descomprime para que el vídeo pueda reproducirse con normalidad. Este proceso tiene lugar en tiempo real cuando se trata de retransmisiones en directo. Este proceso es lo que ocurre cuando se utiliza un códec de vídeo. Un códec de vídeo es esencialmente una herramienta de método de streaming.

Protocolos de streaming frente a formatos de streaming de vídeo

Otra fuente potencial de confusión es el formato de transmisión de vídeo. Se refiere al “contenedor” o “paquete” que se utiliza para la transmisión de vídeo. Un formato contenedor suele contener vídeo comprimido, audio comprimido y metadatos como subtítulos, información de temporización, etc.

Estos datos se transmiten mediante un protocolo de flujo continuo. El formato de transporte define cómo se almacena el contenido dentro de los trozos individuales de datos a medida que se transmiten. Entre los formatos de transporte o contenedores habituales para la transmisión de vídeo se encuentran MP4 (fragmentos) y MPEG-TS.

6 Protocolos comunes de streaming

Se utilizan distintos protocolos de transmisión de vídeo para diferentes casos de uso. Algunos protocolos de streaming se adaptan mejor a unas configuraciones de streaming que a otras. El mejor protocolo para la retransmisión en directo depende de la situación.

Existen seis protocolos comunes de streaming con los que los profesionales de la radiodifusión deberían estar familiarizados: HLS, RTMP, SRT, MSS y MPEG-DASH, y WebRTC. Analicemos algunos de los antecedentes y requisitos técnicos de los protocolos más populares.

1. HTTP Live Streaming (HLS)

La popularización de los productos Apple exigía un protocolo compatible con iOS.

es un protocolo alternativo desarrollado por Apple. HLS son las siglas de HTTP Live Streaming, y hoy en día es el protocolo de streaming más utilizado en Internet. Sin embargo, no siempre ha sido así, ya que cuando aún existía Flash, el protocolo de streaming por excelencia era RTMP.

HLS es un protocolo de bitrate adaptativo y también utiliza servidores HTTP. Este protocolo es una especificación en evolución, ya que Apple añade continuamente funciones y mejora regularmente el HLS.

He aquí un par de ejemplos de cómo Apple ha mejorado HLS en los últimos años:

• Rendimiento: En comparación con un protocolo de streaming como DASH, HLS presentaba algunas deficiencias en el pasado. DASH ofrecía flujos de mejor calidad que HLS, pero ya no es así.
• Resolución: Anteriormente, DASH admitía vídeos con mayor resolución que HLS. Ahora, HLS es compatible con la resolución de vídeo 4K, por lo que HLS ya no está en desventaja frente a DASH en este frente tampoco.

A pesar de haber mejorado sus defectos anteriores, Apple aún no ha sido capaz de solucionar el problema de latencia asociado a HLS. El protocolo HLS tiene una latencia relativamente alta en comparación con RTMP, por ejemplo. Sin embargo, como ya se ha mencionado, Apple trabaja constantemente en HLS e incluso ha lanzado HLS de baja latencia.

HLS de baja latencia

HLS de baja latencia es una extensión del protocolo HLS que puede permitir una latencia de 2 segundos o menos. Esta latencia supone una gran mejora con respecto a los 15-30 segundos de latencia con los que suelen asociarse las transmisiones en directo HLS.

Por desgracia para Apple, la popularidad de este protocolo no ha crecido tan rápido como le gustaría, por lo que ha intentado algunas cosas para acelerar su adopción. Aún así, falta apoyo de los proveedores en todo el ecosistema de distribución de vídeo.

HLS es uno de los protocolos que utiliza Dacast. Dacast también ha añadido compatibilidad con la ingesta HLS, que todavía es relativamente nueva. Ten en cuenta que muy pocas plataformas de streaming admiten actualmente la ingesta HLS.

Códecs de vídeo compatibles:

• H.264
• H.265 / HEVC

Codecs de audio compatibles:

• AAC
• MP3

Formato de transporte/envase:

• MPEG-2 TS

Soporte de reproducción:

• Dispositivos iOS y macOS
• Navegadores Safari, Chrome, Firefox y Edge
• Muchos descodificadores, como Roku
• Muchos reproductores de vídeo en línea, como JW Player y el reproductor de vídeo para todos los dispositivos Dacast

Duración del segmento:

• 10 segundos (puede reducirse manualmente como parte de la reducción de la latencia)

Si quieres conectar con espectadores que utilizan dispositivos Apple, el streaming HLS es uno de los mejores protocolos para retransmitir en directo.

2. Protocolo de mensajería en tiempo real (RTMP)

El protocolo RTMP envía archivos de vídeo desde el codificador a la plataforma de vídeo en línea.

Real-Time Messaging Protocol (RTMP) es un protocolo que se utilizaba anteriormente para entregar vídeos al reproductor Adobe Flash. RTMP fue desarrollado por Macromedia con el objetivo principal de trabajar con Adobe Flash Player, pero como ya sabes, Flash Player ya no existe.

Para entender la popularidad de RTMP como protocolo de entrega, considere que en un momento dado, Adobe Flash Player estaba instalado en cerca del 99% de los ordenadores de sobremesa en Occidente. RTMP fue muy utilizado durante muchos años.

Y como RTMP y Flash trabajaron tan estrechamente juntos, mucha gente confunde ahora los dos términos como si fueran intercambiables, pero no lo son. En otras palabras, Flash ha muerto, pero RTMP no. En cambio, sigue vivo con un nuevo uso ahora que HTML5 ha sustituido a Flash.

RTMP tiene un soporte de reproducción limitado hoy en día. En su lugar, ahora se utiliza RTMP para la ingesta desde el codificador a la plataforma de vídeo en línea.

La ingesta RTMP permite a los usuarios aprovechar la compatibilidad de los codificadores RTMP de bajo coste. Gran parte de la industria del streaming de vídeo en línea, incluidos los principales software de streaming y OVP, sigue siendo compatible con la ingesta RTMP.

Cuando se combina con la entrega HLS, la ingesta RTMP produce un flujo de baja latencia. RTMP sigue siendo potente porque es capaz de soportar baja latencia, que es una de las principales razones por las que la ingesta RTMP ha seguido siendo popular. Otra de las razones principales por las que la ingesta RTMP es actualmente el protocolo más popular para la ingesta tiene que ver con la compatibilidad. La ingesta HLS, por ejemplo, aún no está muy extendida entre los servicios de streaming.

Códecs de vídeo compatibles:

• H.264
• MP4
• x264

Codecs de audio compatibles:

• AAC-LC
• AAC

Formato de transporte/envase:

El formato de transporte/paquete para RTMP no está disponible.

Soporte de reproducción:

• Reproductor Flash
• Adobe AIR
• Reproductores compatibles con RTMP

Duración del segmento:

• La duración del segmento para RTMP no está disponible.

Si necesita un flujo con baja latencia, en el que haya un retraso mínimo en el procesamiento de los datos, la ingesta RTMP es uno de los mejores estándares de flujo de vídeo que puede utilizar.

3. Transporte seguro y fiable (SRT)

SRT es un nuevo e innovador protocolo de streaming.

Secure Reliable Transport (SRT) es un protocolo de streaming relativamente nuevo de Haivision, empresa líder en el sector del streaming en línea. SRT es un protocolo de código abierto que probablemente sea el futuro de la retransmisión en directo. Este protocolo de transmisión de vídeo es conocido por su seguridad, fiabilidad y baja latencia.

SRT sigue siendo bastante futurista porque todavía existen algunas limitaciones de compatibilidad con este protocolo. El protocolo en sí es de código abierto y altamente compatible, pero aún no se ha desarrollado otro hardware y software de streaming compatible con este protocolo.

Haivision ha creado la SRT Alliance, un grupo de empresas del sector de la tecnología y las telecomunicaciones que se dedican a impulsar la SRT en el espacio de la retransmisión en directo. En la actualidad, la mejor forma de acceder a la TER es utilizar tecnología fundada o respaldada por cualquiera de los miembros de la Alianza TER.

Códecs de vídeo compatibles:

• SRT es agnóstico en cuanto a medios y contenidos, por lo que admite todos los códecs de vídeo.

Codecs de audio compatibles:

• SRT es agnóstico en cuanto a medios y contenidos, por lo que admite todos los códecs de audio.

Formato de transporte/envase:

• SRT es agnóstico en cuanto a medios y contenidos, por lo que admite todos los formatos de transporte y paquetes.

Soporte de reproducción:

• Haivision no especifica soporte de reproducción para SRT.

Duración del segmento:

• Haivision no especifica la duración del segmento para SRT.

Si desea estar a la vanguardia de los protocolos de transmisión de vídeo, puede considerar la posibilidad de adaptar SRT

4. Microsoft Smooth Streaming (MSS)

MSS o Microsoft Smooth Streaming es un protocolo de streaming más antiguo con amplio soporte de reproducción.

Antes de profundizar en Microsoft Smooth Streaming (MSS), debes saber que ya no es un protocolo que se utilice a partir de 2022. Pero creemos que es útil seguir hablando de ello para demostrar que sólo porque un gran nombre como Microsoft estuviera detrás del protocolo, ningún protocolo es a prueba de balas.

MSS es un protocolo de streaming que Microsoft desarrolló en 2008 para satisfacer las primeras necesidades de streaming con bitrate adaptativo. Este protocolo de transmisión de vídeo era conocido por ser rentable, reducir el almacenamiento en búfer y ofrecer un rendimiento optimizado.

Microsoft Smooth Streaming está detrás de lo que le permitió transmitir contenido en una XBox 360, Silverlight, Windows Phone 7, y algunas otras plataformas de TV conectadas en su día. También se utilizó en los Juegos Olímpicos de verano de 2008 como protocolo de transmisión a la plataforma en línea de la NBC.

La implantación de Smooth Streaming solía requerir Silverlight, el marco de plugins para desarrolladores propiedad de Microsoft. Sin embargo, Microsoft Silverlight dejó de utilizarse a finales de 2021. Uno de los puntos fuertes de Smooth Streaming era la compatibilidad con PlayReady DRM para impedir la piratería.

A pesar del fracaso de MSS, Microsoft sigue por detrás de otros protocolos como MPEG DASH. Aunque MSS era prometedor en sus inicios, los entusiastas de la tecnología pudieron ver que Silverlight no iba a durar mucho y, como resultado, MSS se vino abajo con él.

Códecs de vídeo compatibles:

• H.264
• VC-1

Codecs de audio compatibles:

• AAC
• WMA

Formato de transporte/envase:

• Fragmentos MP4

Soporte de reproducción:

• Navegadores con el plugin Silverlight
• Xbox
• Windows Phone
• Dispositivos iOS
• Ordenadores Windows
• Muchos Smart TV

Duración del segmento:

• 2-4 segundos

Si buscas el mejor protocolo de streaming para dispositivos Windows, no dejes de considerar MSS.

5. Streaming adaptativo dinámico sobre HTTP (MPEG-DASH)

MPEG-DASH es el protocolo de transmisión en directo del futuro.

El último protocolo de nuestro repaso es MPEG-DASH. Se trata de uno de los protocolos de streaming más recientes, y su adopción está empezando a generalizarse.

Dynamic Adaptive Streaming over HTTP (DASH), también conocido como MPEG-DASH, utiliza servidores web HTTP estándar. Esto reduce el coste y la dificultad técnica de la implementación en comparación con métodos heredados de streaming como RTP.

MPEG-DASH es también un protocolo de tasa de bits adaptativa (ABR). Esto significa que detectará automáticamente los cambios en la velocidad de conexión a Internet del espectador y servirá el vídeo de mejor calidad disponible en cada momento. El streaming ABR reduce el buffering y mejora la experiencia del espectador.

También es importante señalar que MPEG-DASH es una norma abierta que no controla ninguna empresa. Se desarrolló en un esfuerzo conjunto de más de 50 organizaciones, entre ellas algunas de renombre como Apple y Microsoft.

Aunque la mayoría de los navegadores web son compatibles con MPEG DASH, un gran inconveniente que hay que tener en cuenta al conocer el protocolo es que iOS y Safari aún no lo soportan y puede que nunca lo hagan. Teniendo en cuenta la popularidad de los dispositivos Apple, esto tiene enormes implicaciones.

Códecs de vídeo compatibles:

• H.264 (el códec más común)
• H.265 / HEVC (el sucesor de la próxima generación)
• WebM
• VP9/10
• Cualquier otro códec (MPEG-DASH es agnóstico en cuanto a códecs)

Codecs de audio compatibles:

• AAC
• MP3
• Cualquier otro códec (MPEG-DASH es agnóstico en cuanto a códecs)

Formato de transporte/envase:

• Fragmentos MP4
• MPEG-2 TS

Soporte de reproducción:

• Compatibilidad nativa con dispositivos Android
• Se reproduce en la mayoría de los televisores Samsung, LG, Philips, Panasonic y Sony fabricados después de 2012.
• Funciona con Chromecast
• Compatible con YouTube y Netflix
• No se admite de forma nativa a través de HTML5, pero los reproductores pueden implementarse a través de Javascript y Media Source Extensions

Duración del segmento:

• Variable

No todos los espectadores tienen la misma conexión a Internet, lo que significa que cuando se intenta conectar con una gran audiencia, es necesario transmitir el vídeo a diferentes resoluciones, lo que es posible con el protocolo de tasa de bits adaptable, que admite MPEG-DASH. MPEG-DASH es el mejor protocolo de streaming para ofrecer a sus espectadores un vídeo que satisfaga sus necesidades.

6. WebRTC

WebRTC es un proyecto gratuito y de código abierto que ofrece a navegadores web y aplicaciones móviles comunicación en tiempo real (RTC) a través de interfaces de programación de aplicaciones (API).

Web Real-Time Communication (WebRTC) es relativamente nuevo en comparación con los demás de nuestra lista y técnicamente no se considera un protocolo de streaming, pero a menudo se habla de él como si lo fuera. Es el principal responsable de que puedas participar en videoconferencias en directo directamente desde tu navegador.

WebRTC ganó mucha popularidad durante la pandemia porque se hizo con la intención de soportar conferencias web y VoIP. Microsoft Teams, cuya popularidad se disparó durante la pandemia, utiliza WebRTC para las comunicaciones de audio y vídeo.

WebRTC es compatible con la transmisión de velocidad de bits adaptativa del mismo modo que HLS y MPEG-DASH. Al igual que HLS, WebRTC también se basa en la transcodificación en directo para producir múltiples variantes de velocidad de bits, de modo que los usuarios con conexiones pobres y fuertes puedan disfrutar de la transmisión. WebRTC tiene un futuro muy optimista por delante.

Códecs de vídeo compatibles:

• H.264
• VP8 + VP9

Codecs de audio compatibles:

• PCMU
• PCMA
• G.711
• G.722
• Opus

Soporte de reproducción:

• Compatibilidad nativa con dispositivos Android
• A partir de 2020, iOS Safari 11 y las versiones más recientes son compatibles con WebRTC
• Funciona en Google Chrome, Mozilla Firefox y Microsoft Edge
• Con el apoyo de YouTube y Google

Duración del segmento:

• No aplicable

Reflexiones finales

A estas alturas ya comprenderás mejor lo que es la retransmisión en directo. Tanto si eres un veterano como un recién llegado, los conocimientos prácticos sobre códecs, formatos de contenedores, CDN y demás que se exponen en este artículo te ayudarán a elegir el mejor protocolo de transmisión en directo para tus necesidades.

Cada protocolo de transmisión tiene sus pros y sus contras. El protocolo que utilices dependerá en gran medida de a quién quieras llegar y de los dispositivos que utilicen. En otras palabras, las necesidades de su público.

Creemos que HLS es actualmente el mejor protocolo para la mayoría de los casos de transmisión de vídeo en directo. Por eso, con HDS, es nuestro protocolo por defecto aquí en Dacast. Los elegimos porque queremos lo mejor para nuestros clientes.

¿Aún no se ha unido a Dacast pero le interesa lo que ofrecemos? No digas más. Puede probar gratis nuestras soluciones profesionales con nuestra prueba gratuita de 14 días sin riesgos. Con nuestra prueba gratuita, tendrás acceso completo a la transmisión en directo, la carga segura de vídeos, el alojamiento de contenidos a la carta y mucho más.

Pruebe Dacast gratis

La tecnología evoluciona constantemente, y seguramente utilizaremos métodos diferentes en el futuro. Para recibir regularmente ofertas exclusivas y actualizaciones sobre streaming de vídeo, únase a nuestro grupo de LinkedIn.