- TI/AV para empresas
El funcionamiento del streaming de vídeo en línea ha cambiado
En el ecosistema del vídeo, es raro que las tecnologías que compiten entre sí coexistan pacíficamente durante mucho tiempo.
La ahora famosa guerra de formatos de cintas 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 su competencia. Cuando la industria votó colectivamente por el VHS en 1975, la tecnología tardó menos de tres años en superar al Betamax. En un cambio posterior del mercado, entre 1999 y 2004, las ventas de VHS fueron superadas, y luego rápidamente empequeñecidas, por los DVD.
From Beta to VHS to DVD: Case studies in how suddenly the video ecosystem can tip.Sources: Business History Review, Nexus Research.
Los medios de comunicación en línea han experimentado cambios sísmicos similares. En enero 2010, sólo el 10% de los vídeos en línea estaban codificados con el formato de compresión H.264. Menos de dos años después, esa cifra se ha disparado hasta el 80% (MeFeedia).
En cada uno de estos horizontes de eventos, la inercia del mercado cedió ante una tecnología de medios a la que le había llegado su hora. Y en 2015, el sector 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 algo esencial para el entretenimiento de las personas, el aprendizaje de los estudiantes y la comunicación de las empresas. Se calcula que más de dos tercios del tráfico mundial de Internet de los consumidores ya está compuesto por 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 streaming de medios en línea
1. Descarga HTTP
Cuando los archivos de vídeo se compartieron por primera vez en línea, se distribuyeron 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 contenidos basados en la web.
Al principio, los vídeos tenían que descargarse en su totalidad antes de poder empezar a reproducirlos. Este proceso, denominado download and play, tenía varias deficiencias notables. En primer lugar, las velocidades de conexión telefónica de 28 a 56 kbps hacían que los usuarios encontraran casi siempre largos retrasos en la reproducción. En segundo lugar, no existía ningún mecanismo que permitiera escalar eficazmente a múltiples espectadores simultáneos. Por último, el limitado ancho de banda se desperdiciaba a menudo en segmentos de vídeo no vistos. Por ejemplo, si un usuario hacía clic en un vídeo de 10 minutos y sólo veía los tres primeros, los siete minutos restantes se descargaban superfluamente en la red.
Apple abordó algunos de los problemas de la descarga de vídeo basada en HTTP cuando lanzó la compatibilidad con Fast Start, más conocida como descarga HTTP progresiva. Este método colocaba los metadatos importantes en la parte superior del archivo multimedia, lo que permitía comenzar la reproducción del vídeo antes de que se descargara todo el archivo. Aunque la descarga progresiva sigue utilizándose hoy en día, fue sustituida en gran medida a principios de la década de 2000 por protocolos y servidores personalizados creados para un nuevo tipo de entrega de vídeo en línea denominado streaming.
La descarga progresiva HTTP mejoró el tiempo de inicio, pero siguió sufriendo el desperdicio de ancho de banda y la escala limitada.
2. Protocolos de transmisión personalizados
Compared to other types of content shared online, video files are massive. A single minute of iPhone video can take up as much as 80 to 120 MB of disk space. In that same amount of space, you could store between 250 and 350 average-sized Word documents (Microsoft).
Esta característica dificultaba la distribución de archivos de vídeo a través de redes con limitaciones de ancho de banda. Por eso, a medida que el vídeo se hacía más frecuente en la web y en las redes corporativas, las empresas de medios de comunicación y los proveedores de software empezaron a desarrollar protocolos personalizados para la transmisión de vídeo. RealNetworks y Netscape colaboraron en el desarrollo y estandarización del Protocolo de Transmisión en Tiempo Real (RTSP). Adobe, a través de su 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 streaming, Microsoft Media Server (MMS), para su uso en diversas aplicaciones de Windows.
RTSP, RTMP y MMS trataron el video como un caso especial. Construyeron "redes superpuestas" en las que los servidores de transmisión de protocolos específicos se sentaban junto a los servidores HTTP tradicionales. Cuando un usuario iniciaba una solicitud para reproducir video, la solicitud se enrutaba al servidor de transmisión, que luego abrió una conexión persistente (o "con estado") al reproductor de video 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 streaming personalizados superaron muchos de los retos de la descarga progresiva HTTP. El vídeo se almacenaba en el búfer, se procesaba y se reproducía a medida que se transmitía por la red, lo que permitía a los usuarios abandonar un vídeo a mitad de la transmisión con un gasto mínimo de ancho de banda. El acceso aleatorio permitía a los espectadores buscar e iniciar rápidamente la reproducción desde cualquier punto del vídeo. La conexión persistente del servidor de streaming al cliente proporcionaba una latencia más predecible. Y en todos los casos, estas redes superpuestas ayudaron a las organizaciones a descargar el tráfico de vídeo del transporte WAN primario, 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 no estaban exentos de limitaciones. Como estos protocolos trataban el vídeo como un tipo de datos especial, aumentaban el coste y la complejidad de la entrega de vídeo. En primer lugar, los protocolos requerían el despliegue de un conjunto separado de servidores especializados en toda la red corporativa, lo que añadía costes de infraestructura de hardware y software. En segundo lugar, los protocolos de streaming creaban un vínculo entre los mecanismos de entrega y de 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), lo que duplicaba 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 su 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 sufren frecuentes interrupciones de conectividad y cambios de dirección IP. A menudo, esto obligaba a restablecer la conexión RTMP activa varias veces durante un mismo evento.
3. Tecnología de transmisión de vídeo multidifusión
La afirmación de que la multidifusión fue una fase distinta del suministro de vídeo en línea es generosa, ya que la tecnología nunca alcanzó una masa crítica ni en la empresa ni en la Internet de los consumidores. Sin embargo, a mediados de la década de 2000 hubo un gran interés por la multidifusión de vídeo, y la tecnología persiste en algunas redes corporativas, por lo que merece ser discutida.
La multidifusión era una tecnología de red que permitía a un emisor distribuir los mismos datos a varios destinatarios al mismo tiempo. Desde el punto de vista conceptual, no es muy diferente a escuchar la radio. Se envía una única señal de radio a todos los oyentes en lugar de enviar señales únicas a cada persona que sintoniza. Cuando se implementa correctamente, la multidifusión crea una eficiencia increíble en la entrega de datos. Esto impulsó un período de interés en el uso de la multidifusión para la entrega de vídeo.
Utilizando la multidifusión, una organización podría, en teoría, distribuir vídeo en directo a través de la red corporativa utilizando una fracción del ancho de banda requerido por la transmisión tradicional unicast . Por ello, las organizaciones solían considerar la multidifusión como una forma de obtener un mayor rendimiento de sus redes con limitaciones de ancho de banda, en lugar de actualizar la infraestructura de red.
La transmisión unicast (izquierda) envía un único flujo para cada cliente conectado, mientras que la multidifusión (derecha) envía un único flujo que comparten todos los clientes suscritos.
Por desgracia, 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 dato) mediante multidifusión, la fuente, los receptores y la infraestructura de red de conexión debían ser compatibles con el protocolo. En concreto, todos los routers, concentradores, conmutadores y cortafuegos de una red corporativa debían ser compatibles con la multidifusión. Este requisito de infraestructura homogénea no era ni práctico ni resistente.
Por ejemplo, si un intento de comunicación multidifusión fallaba, la alternativa era 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 de la WAN, ya que la multidifusión era la única forma de optimización implementada.
Además, como la multidifusión requería un entorno de red homogéneo, estaba fundamentalmente en desacuerdo con las topologías de red que todavía dominan las empresas y la comunicación online de los consumidores. Internet se ha construido para una amplia gama de velocidades de red, tipos de conexión, calidad de servicio (QoS) y dispositivos finales. Su base es HTTP, un protocolo sin estado e independiente de los medios construido específicamente para trabajar en este entorno heterogéneo. Del mismo modo, las redes detrás de los cortafuegos corporativos son cada vez más heterogéneas. La tendencia a traer su propio dispositivo (BYOD) significa que los empleados llevan una gama de tabletas y teléfonos inteligentes con diversas capacidades y requisitos de red. Y la consolidación continua 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 elevada pero poco realista para el suministro de vídeo. En la última década, el interés por esta tecnología no ha dejado de disminuir.
Interés en la multidifusión, 2004-2015. Fuente: Google Trends.
4. Streaming HTTP moderno
En 2008, Microsoft introdujo Smooth Streaming, un enfoque híbrido para la entrega de vídeo que ofrecía muchas ventajas de los protocolos de streaming personalizados, al tiempo que aprovechaba HTTP y la infraestructura de red existente. Smooth Streaming también soportaba la entrega de bitrate adaptativo (ABR), proporcionando a los espectadores tiempos de inicio y búsqueda más rápidos, un buffering mínimo y una experiencia de reproducción más suave.
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 de vídeo en función de la velocidad de conexión del cliente.
El streaming basado en HTTP ganó rápidamente impulso, y otros líderes del mercado se apresuraron a invertir en la tecnología. En 2009, Apple entró en el mercado con la introducción de HTTP Live Streaming (HLS). En 2010, Adobe se alejó de los protocolos de streaming personalizados con el lanzamiento de HTTP Dynamic Streaming (HDS). Y desde 2010, las principales empresas de streaming y medios de comunicación, como Microsoft, Google, Adobe, Netflix, Ericsson y Samsung, han colaborado en MPEG-DASH, un estándar abierto para el streaming de vídeo adaptativo 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 un cambio en la forma en que las empresas distribuyen el vídeo en sus redes.
Más información sobre la transmisión de vídeo en línea
En nuestro último documento técnico, Modern Video Streaming in the Enterprise: Protocols, Caching and WAN Optimization, profundizaremos en los cambios técnicos que impulsan el cambio hacia Modern Streaming, incluidas las siete características que hacen que un protocolo de streaming de vídeo sea moderno.
También analizaremos las nuevas oportunidades que presenta Modern Streaming para que las organizaciones utilicen la infraestructura de red existente para una entrega de vídeo más escalable y rentable.
Descargue su ejemplar hoy mismo!