- Informática/audiovisual empresarial
La forma en que funciona la transmisión de video en línea ha cambiado.
En el ecosistema del vídeo, es raro que las tecnologías competidoras coexistan pacíficamente durante mucho tiempo.
La ya famosa guerra de formatos de vídeo de finales de los años 70 y 80 demostró la rapidez con la que la industria podía inclinarse a favor de una tecnología y el impacto devastador que esto podía tener en la competencia. Cuando la industria votó colectivamente por el VHS en 1975, esta tecnología tardó menos de tres años en superar al Betamax. En un cambio de mercado posterior, entre 1999 y 2004, las ventas de VHS fueron superadas, y luego eclipsadas rápidamente, por las de DVD.
De Beta a VHS y a DVD: estudios de caso sobre cómo el ecosistema del vídeo puede dar un vuelco repentinamente.Fuentes: Business History Review, Nexus Research.
Los medios digitales han experimentado cambios sísmicos similares. En enero de 2010, solo el 10 % de los vídeos en línea se codificaban con el formato de compresión H.264. Menos de dos años después, esa cifra se había disparado hasta el 80 % (MeFeedia).
En cada uno de estos escenarios, la inercia del mercado cedió ante una tecnología de medios cuyo momento había llegado. Y en 2015, la industria se acerca a su próximo punto de no retorno.
En los últimos diez o doce años, el vídeo en línea se ha convertido en un elemento esencial para el entretenimiento, el aprendizaje y la comunicación empresarial. Se estima que más de dos tercios del tráfico global de internet de los consumidores ya corresponden a vídeo ( Cisco ), y que las grandes empresas ya transmiten más de 14 horas de vídeo por empleado al mes (Gartner).
Durante este tiempo, la tecnología de distribución de medios ha evolucionado en cuatro fases.
La evolución de la tecnología de transmisión de medios en línea
1. Descarga HTTP
Cuando los archivos de vídeo se compartieron por primera vez en línea, se distribuían mediante el Protocolo de Transferencia de Hipertexto (HTTP), el mismo mecanismo de entrega que utilizan las páginas HTML, las imágenes, los documentos y otros tipos de contenido web.
Inicialmente, los videos debían descargarse por completo antes de poder reproducirse. Este proceso, denominado descarga y reproducción , presentaba varias deficiencias importantes. En primer lugar, las velocidades de conexión telefónica de 28 a 56 kbps provocaban que los usuarios casi siempre experimentaran largos retrasos en la reproducción. En segundo lugar, no existía un mecanismo para gestionar de forma eficiente a múltiples espectadores simultáneos. Por último, el ancho de banda limitado se desperdiciaba a menudo en segmentos de video no vistos. Por ejemplo, si un usuario hacía clic en un video de 10 minutos y solo veía los tres primeros, los siete minutos restantes se descargaban innecesariamente a través de la red.
Apple solucionó algunos de los problemas de la descarga de vídeo basada en HTTP al lanzar la compatibilidad con Fast Start , más conocida como descarga HTTP progresiva. Este método colocaba metadatos importantes al principio del archivo multimedia, lo que permitía que la reproducción del vídeo comenzara antes de que se descargara el archivo completo. Aunque la descarga progresiva todavía se utiliza hoy en día, a principios de la década de 2000 fue reemplazada en gran medida por protocolos y servidores personalizados diseñados para un nuevo tipo de distribución de vídeo en línea llamado streaming .
La descarga HTTP progresiva mejoró el tiempo de inicio, pero aún sufría de desperdicio de ancho de banda y escalabilidad limitada.
2. Protocolos de transmisión personalizados
En comparación con otros tipos de contenido compartido en línea, los archivos de video son enormes. Un solo minuto de video grabado con un iPhone puede ocupar entre 80 y 120 MB de espacio en disco. En ese mismo espacio, se podrían almacenar entre 250 y 350 documentos de Word de tamaño promedio (Microsoft).
Esta característica dificultaba la distribución de archivos de vídeo en redes con ancho de banda limitado. Por ello, a medida que el vídeo se popularizó en la web y en las redes corporativas, las empresas de medios y los proveedores de software comenzaron a desarrollar protocolos personalizados para la transmisión de vídeo. RealNetworks y Netscape colaboraron en el desarrollo y la estandarización del Protocolo de Transmisión en Tiempo Real (RTSP). Adobe, mediante la adquisición de Macromedia, implementó el Protocolo de Mensajería en Tiempo Real (RTMP) para la transmisión de vídeo basada en Flash. Microsoft desarrolló un tercer protocolo de transmisión, Microsoft Media Server (MMS), para su uso en diversas aplicaciones de Windows.
RTSP, RTMP y MMS trataban el vídeo como un caso especial. Creaban «redes superpuestas» en las que los servidores de transmisión específicos de cada protocolo coexistían con los servidores HTTP tradicionales. Cuando un usuario solicitaba la reproducción de un vídeo, la solicitud se enrutaba al servidor de transmisión, que a su vez establecía una conexión persistente (o «con estado») con el reproductor de vídeo del usuario.
Los protocolos de transmisión personalizados requerían servidores especializados, configuración de cortafuegos y una infraestructura de almacenamiento en caché independiente.
Los protocolos de transmisión personalizados superaron muchos de los desafíos de la descarga progresiva HTTP. El vídeo se almacenaba en búfer, se procesaba y se reproducía a medida que se transmitía por la red, lo que permitía a los usuarios interrumpir la reproducción a mitad de la transmisión con un mínimo desperdicio de ancho de banda. Se admitía el acceso aleatorio, lo que permitía a los espectadores buscar y comenzar la reproducción rápidamente desde cualquier punto del vídeo. La conexión persistente entre el servidor de transmisión y el cliente proporcionaba una latencia más predecible. En todos los casos, estas redes superpuestas ayudaron a las organizaciones a descargar el tráfico de vídeo del transporte WAN principal, reduciendo la posibilidad de que la congestión de vídeo pusiera en peligro la entrega de información y datos transaccionales de mayor prioridad.
Sin embargo, RTMP, RTSP y MMS presentaban limitaciones. Dado que estos protocolos trataban el vídeo como un tipo de datos especial, aumentaban el coste y la complejidad de la distribución de vídeo. En primer lugar, requerían la implementación de un conjunto independiente de servidores especializados en toda la red corporativa, lo que incrementaba los costes de infraestructura de hardware y software. En segundo lugar, los protocolos de transmisión creaban una vinculación entre los mecanismos de distribución y almacenamiento en caché. Esto obligaba a las organizaciones a admitir dos tecnologías de almacenamiento en caché distintas (una para el tráfico basado en HTTP y otra para el vídeo), duplicando así la complejidad de la gestión de la red. En tercer lugar, RTMP, RTSP y MMS requerían que los administradores abrieran puertos de red adicionales para la comunicación (1935, 554 y 1755, respectivamente). Esto ampliaba la superficie de ataque de la red y aumentaba la probabilidad de que los protocolos fueran bloqueados por los cortafuegos corporativos. Por último, los protocolos de transmisión personalizados solían ser incompatibles con los dispositivos móviles. Por ejemplo, RTMP requería Flash para la reproducción, un formato que, como es sabido, no es compatible con los dispositivos iOS. Más allá del ecosistema iOS, los clientes móviles experimentan frecuentes interrupciones de conectividad y cambios de dirección IP. Esto a menudo requeriría que la conexión RTMP activa se restableciera varias veces durante un solo evento.
3. Tecnología de transmisión de vídeo multicast
Afirmar que la multidifusión fue una fase distinta de la distribución de vídeo en línea es una afirmación generosa, considerando que la tecnología nunca alcanzó una masa crítica ni en el ámbito empresarial ni en el de consumo. Sin embargo, hubo un gran interés en la multidifusión para vídeo a mediados de la década de 2000, y la tecnología aún se utiliza en algunas redes corporativas, por lo que merece ser analizada.
La multidifusión era una tecnología de red que permitía a un emisor distribuir los mismos datos a múltiples destinatarios simultáneamente. Conceptualmente, era similar a escuchar la radio: se enviaba una única señal a todos los oyentes, en lugar de enviar señales individuales a cada persona que sintonizaba. Cuando se implementaba correctamente, la multidifusión generaba una eficiencia increíble en la entrega de datos. Esto impulsó un período de interés en su uso para la transmisión de vídeo.
Mediante la multidifusión, una organización podría, en teoría, transmitir vídeo en directo a través de su red corporativa utilizando una fracción del ancho de banda que requiere la transmisión unicast tradicional. Por ello, las organizaciones suelen recurrir a la multidifusión como una forma de obtener un mayor retorno de la inversión en sus redes con ancho de banda limitado, en lugar de actualizar su infraestructura de red.
La transmisión unicast (izquierda) envía un flujo único para cada cliente conectado, mientras que la transmisión multicast (derecha) envía un único flujo que comparten todos los clientes suscriptores.
Lamentablemente, los requisitos de infraestructura de la multidifusión la hacían inviable para la mayoría de las organizaciones. Para distribuir vídeo (o cualquier otro dato) mediante multidifusión, tanto la fuente como los receptores y la infraestructura de red de conexión debían ser compatibles con el protocolo. En concreto, cada enrutador, concentrador, conmutador y cortafuegos dentro de una red corporativa debía ser compatible con la multidifusión. Este requisito de una infraestructura homogénea no era ni práctico ni robusto.
Por ejemplo, si fallaba un intento de comunicación multicast, la alternativa solía ser una transmisión unicast tradicional. En la mayoría de los casos, esta transmisión unicast no se beneficiaba de ninguna optimización de red, como el almacenamiento en caché de datos u otras técnicas de aceleración WAN, ya que la multidifusión era la única forma de optimización implementada.
Además, dado que la multidifusión requería un entorno de red homogéneo, estaba fundamentalmente reñida con las topologías de red que aún predominan en las empresas y en la comunicación en línea de los consumidores. Internet está diseñado para una amplia gama de velocidades de red, tipos de conexión, calidad de servicio (QoS) y dispositivos de punto final. Su base es HTTP, un protocolo sin estado e independiente del medio, creado específicamente para funcionar en este entorno heterogéneo. De manera similar, las redes detrás de los firewalls corporativos son cada vez más heterogéneas. La tendencia hacia el uso de dispositivos personales en el trabajo (BYOD) implica que los empleados utilizan una variedad de tabletas y teléfonos inteligentes con capacidades y requisitos de red diversos. Y la continua consolidación del sector hace que sea cada vez menos probable que una sucursal recién adquirida en Londres utilice la misma arquitectura de red que la oficina central en Seattle.
En resumen, la multidifusión era una aspiración ambiciosa pero poco realista para la distribución de vídeo. En la última década, el interés por esta tecnología ha ido disminuyendo progresivamente.
Interés en la multidifusión, 2004-2015. Fuente: Google Trends.
4. Transmisión HTTP moderna
En 2008, Microsoft presentó Smooth Streaming, un enfoque híbrido para la distribución de vídeo que ofrecía muchas de las ventajas de los protocolos de transmisión personalizados, aprovechando al mismo tiempo HTTP y la infraestructura de red existente. Smooth Streaming también admitía la distribución de tasa de bits adaptativa (ABR), lo que proporcionaba a los espectadores tiempos de inicio y búsqueda más rápidos, un almacenamiento en búfer mínimo y una experiencia de reproducción más fluida.
La transmisión con tasa de bits adaptativa proporciona tiempos de inicio y búsqueda más rápidos, un almacenamiento en búfer mínimo y una experiencia de reproducción fluida al ajustar dinámicamente la calidad del vídeo en función de la velocidad de conexión del cliente.
La transmisión basada en HTTP rápidamente ganó popularidad, y otros líderes del mercado no tardaron en invertir en esta tecnología. En 2009, Apple entró en el mercado con la introducción de HTTP Live Streaming (HLS). En 2010, Adobe dejó de centrarse en los protocolos de transmisión personalizados con el lanzamiento de HTTP Dynamic Streaming (HDS). Desde entonces, importantes empresas de transmisión y medios, como Microsoft, Google, Adobe, Netflix, Ericsson y Samsung, han colaborado en MPEG-DASH, un estándar abierto para la transmisión de vídeo adaptativa a través de HTTP.
Innovaciones como Smooth Streaming, HLS, HDS y DASH han impulsado un resurgimiento de la distribución de vídeo basada en HTTP y una transformación radical en la forma en que las empresas distribuyen vídeo a través de sus redes.
Obtén más información sobre la transmisión de video en línea.
En nuestro último informe técnico, Transmisión de vídeo moderna en el entorno empresarial: protocolos, almacenamiento en caché y optimización de redes WAN.Analizaremos con mayor profundidad los cambios técnicos que impulsan la transición hacia el streaming moderno, incluidas las siete características que hacen que un protocolo de transmisión de vídeo sea moderno.
También analizaremos las nuevas oportunidades que ofrece Modern Streaming para que las organizaciones utilicen la infraestructura de red existente para una distribución de vídeo más escalable y rentable.