En
su forma más simple, tiene un archivo de manifiesto, también conocido
como lista de reproducción, que es el archivo 'principal' de una
transmisión. Este archivo contiene metadatos sobre la transmisión y una lista de URI para los segmentos de video de la transmisión. Cuando
un jugador solicita esta lista de reproducción, un servidor responde
con un archivo de manifiesto actualizado que especifica los segmentos
que se han agregado recientemente a la transmisión.
Si
está familiarizado con HLS, podría estar pensando: "¿HLS ya no es
compatible con HTML?" La respuesta: ¡más o menos! Cuando Apple inventó
HLS, también implementó un mecanismo de "reproductor" dentro de su
navegador. Esto significaba que en Safari podías agregar una línea de
HTML a la página, por ejemplo <video src=?path/to/playlist.m3u8?></video>
, y listo, ¡tendrías un reproductor HLS funcionando!
Pero,
por varias razones, otros navegadores no implementaron esto, lo que
significa que los sistemas debían diseñarse para transmitir de manera
diferente según el dispositivo y el navegador en el que operaba el
usuario. Una transmisión puede usar HLS en Safari o iOS y RTMP o HDS en el escritorio. Finalmente,
Chrome y Firefox implementaron un reproductor HLS para sus versiones
móviles, pero Chrome, Firefox e IE no usaban esta tecnología en
sus versiones de escritorio. Se necesitaba una tecnología para navegadores de escritorio para transmitir HLS en todos los dispositivos. Finalmente, se lanzaron algunas bibliotecas excelentes para resolver este problema. Flashls , que es de código abierto, y osmfhls , que es propietario, son dos bibliotecas de complementos de Flash para reproductores que habilitan HLS en el escritorio. Finalmente fue adoptado por la gran mayoría de nevegadores web debido a su versatilidad y ahorro de recursos.
HLS experimentó una adopción generalizada, pero Flash seguía siendo un requisito. El flash es pesado, lento y está lleno de fallas de seguridad . Los expertos han estado prediciendo la desaparición de flash por un tiempo ahora , y se necesita una alternativa. Para agregar algo de contexto, tendremos que desviarnos rápidamente a otro formato de video, o más bien a un MPEG-DASH estándar. Dash básicamente toma todas las cosas buenas de HLS y se deshace de las malas. Sin embargo, al igual que HLS, también se basa en archivos para admitir este nuevo formato en el navegador W3C.decidió crear nuevas API de HTML5 llamadas Extensiones de fuente de medios (MSE) y Extensiones de medios cifrados (EME). MSE brinda a los desarrolladores una API para controlar el búfer de video de la etiqueta de video e inyectar datos en él. EME es una API que proporciona compatibilidad con DRM. Como resultado, es posible inyectar datos en el reproductor de video del navegador y usarlo para implementar HLS.
Técnicamente, esto requiere una lógica de reproducción HLS que solicita archivos HLS de un servidor, los transmuxa al formato mp4 correcto en javascript y los inyecta en la etiqueta de video usando MSE. Hay algunas bibliotecas de software libre que hacen precisamente eso, incluidas: hlsjs , videojs-contrib- hls de videojs y hasplayer . Ahora tenemos HLS en el navegador de escritorio, solo con javascript, sin necesidad de Flash. Es compatible con Chrome, Firefox 42+, IE11 +, Edge y Opera.
Es el momento de las comparaciones, el rendimiento y el análisis. En esta sección, mostraré los resultados de las pruebas ejecutadas en videojs5 (con videojs-contrib-hls v1.0), su predecesor flash videojs4, hls.js y su predecesor flash flashls. Me centraré en las pruebas de rendimiento de la CPU.
Para
cada jugador, se utilizó el panel de la línea de tiempo de Chrome para
rastrear los fps del navegador, el panel de perfil para registrar cuánto
tiempo de CPU se utilizó y el administrador de tareas para monitorear
el uso general de la CPU.
Actualizado:
Al examinar el administrador de tareas de Chrome, el uso de la CPU fue principalmente del 0-2%, con picos del 3%. El uso de GPU fue principalmente del 2%, con picos del 3%.
La cantidad de fotogramas de video que se redujeron después de ver el video completo fue de 638.
Al examinar el administrador de tareas de Chrome, el uso de la CPU fue principalmente del 0-2%, con picos del 3%. El uso de GPU fue principalmente del 2%, con picos del 3%.
La cantidad de fotogramas de video que se redujeron después de ver el video completo fue 421.
Al examinar el administrador de tareas de Chrome, el uso de la CPU fue del 16% en promedio, con picos del 24% de la CPU (dividido entre flash - 20% y página - 4%)
Al examinar el administrador de tareas de Chrome, el uso de CPU de la página fue principalmente del 1-2%, con picos del 3%. La GPU fue principalmente del 2% con picos del 3%. Además, el complemento flash consumía un 2% en la mayoría de las ocasiones y un 3% en los picos.
La cantidad de fotogramas de video que se redujeron después de ver el video completo fue de 1668.
Tanto videojs5 como hlsjs funcionaron muy bien. Reprodujeron fácilmente videos HD de 30 fps sin retrasar el hilo principal. Ambas
bibliotecas cayeron en promedio menos de 1 fotograma por segundo en el
video HD de 60 fps, y videojs5 perdió un poco menos que hlsjs.
Ambas
bibliotecas javascript funcionaron mejor que flash en el consumo
general de cpu + gpu y en la cantidad de fotogramas eliminados. Flashls
tuvo un rendimiento ligeramente mejor para mantener limpio el hilo
principal de Chrome, lo cual es importante solo cuando los usuarios aún
interactúan con su sitio mientras ven el video.
Clasificando el rendimiento de la CPU de las bibliotecas, sugeriría:
La comparación no se muestra aquí, pero ambos reproductores de JavaScript comenzaron más rápido que sus contrapartes de Flash debido a los requisitos de carga asincrónica de Flash para el archivo .swf y el archivo de dominio cruzado.
Es importante mencionar que las bibliotecas utilizadas son todavía muy jóvenes y videojs aún no ha lanzado soporte para JavaScript HLS. Es probable que veamos mejoras en todas las bibliotecas. Estas innovaciones, al igual que otras, probablemente impulsarán videos de mayor calidad y crearán mejores experiencias de visualización en la web.
Peer5 es una CDN peer-to-peer que mejora la entrega de contenido para transmisiones de video en vivo y bajo demanda. ¿Quieres probar Flashless HLS? Regístrese para su prueba gratuita aquí .
Después de registrarse, seleccione JW7 y marque la casilla de verificación "Reproducir HLS en Javascript".
¿Quiere aprender a configurar sus transmisiones HLS para que se reproduzcan sin Flash? Haga clic aquí para obtener la guía de Peer5 para la reproducción sin flash.