Durante años, hubo dos modelos básicos de streaming por Internet: la tecnología propietaria basada en servidor, como RTMP, o la descarga progresiva. El streaming basado en servidor permite la entrega de flujos con múltiples tasas de bits que pueden conmutarse bajo demanda, pero requiere un costoso software de licencia. La descarga progresiva puede hacerse a través de Apache, pero el cambio de velocidad requiere detener la reproducción.
La llegada de protocolos de transmisión basados en HTTP, como HLS y Smooth Streaming, hizo posible la transmisión de secuencias a través de conexiones HTTP estándar utilizando tecnología de servidor básica, como Apache; el cambio de velocidad de bits sin interrupciones se convirtió en algo habitual y la transmisión a través de redes de distribución de contenidos (CDN) era sencilla, ya que básicamente era lo mismo que transmitir cualquier archivo a través de HTTP. El streaming HTTP ha supuesto nada menos que una revolución en la distribución de contenidos multimedia, reduciendo enormemente el coste y la complejidad del streaming de alta calidad.
A la hora de diseñar una plataforma de vídeo hay que tener en cuenta innumerables cosas. Sin embargo, una de las decisiones más importantes y que a menudo se pasa por alto es cómo tratar los archivos de manifiesto basados en HTTP.
Archivos estáticos de manifiesto
En el mundo físico, cuando compras un vídeo, miras el envoltorio, coges la caja, te diriges a la caja, pagas al cajero, te vas a casa y lo introduces en tu reproductor.
La mayoría de las plataformas de vídeo tienen una estructura bastante similar. Fundamentalmente, un grupo de metadatos (la caja) se asocia a un elemento multimedia reproducible (el vídeo). La mayoría de las plataformas de vídeo comienzan con el concepto de una única URL que conecta los metadatos a un único vídeo mp4. A medida que una plataforma de vídeo se hace más compleja, puede haber varias URL conectadas a los metadatos que representen varias velocidades de bits, resoluciones o quizás otros medios asociados al elemento principal, como previsualizaciones o características especiales.
Las cosas se complican cuando se intenta extender el modelo físico a un mundo de streaming en línea que incluye protocolos de streaming basados en HTTP, como HLS. HLS se basa en muchos fragmentos de un archivo de vídeo enlazados por un archivo de texto llamado manifiesto. Cuando se implementa HLS, el método más sencillo es simplemente añadir una URL que enlace al manifiesto, o archivo m3u8. Esto tiene la ventaja de ser extremadamente fácil, encajando básicamente en el modelo existente.
El inconveniente es que HLS no se parece en nada a un elemento multimedia estático. Por ejemplo, un MP4 se parece mucho a una pista de vídeo de un DVD; es un único vídeo con una única resolución y velocidad de bits. El manifiesto HLS consiste, muy probablemente, en múltiples bitrates, resoluciones y miles de piezas fragmentadas de vídeo. HLS tiene la capacidad de hacer mucho más que un MP4, así que ¿por qué tratarlo igual?
Listas de reproducción HLS
Una lista de reproducción HLS incluye algunos metadatos que describen elementos básicos del flujo y un conjunto ordenado de enlaces a fragmentos del vídeo. Al descargar cada fragmento o segmento del vídeo y reproducirlos en secuencia, el usuario puede ver lo que parece ser un único vídeo continuo.
- EXTM3U
- #EXT-X-PLAYLIST-TYPE:VOD
- #EXT-X-TARGETDURATION:10
- #EXTINF:10,
- archivo-0001.ts
- #EXTINF:10,
- archivo-0002.ts
- #EXTINF:10,
- archivo-0003.ts
- #EXTINF:10,
- archivo-0003.ts
- #EXT-X-ENDLIST
Arriba hay una lista de reproducción m3u8 básica. En ella se enlazan cuatro segmentos de vídeo. Para generar estos datos mediante programación, sólo se necesita el nombre de archivo del primer elemento, la duración prevista de los segmentos (en este caso, 10) y el número total de segmentos.
Manifiestos HLS
Un manifiesto HLS es una serie desordenada de enlaces a listas de reproducción. Hay dos razones para tener varias listas de reproducción: para proporcionar varias velocidades de bits y para proporcionar listas de reproducción de copia de seguridad. Esta es una lista de reproducción típica en la que cada .m3u8 es un enlace relativo a otra lista de reproducción HLS.
- #EXTM3U
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
- archivo-2040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
- archivo-1540k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
- archivo-1040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
- archivo-640k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
- file-440k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
- archivo-240k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
- archivo-64k.m3u8
Las listas de reproducción tienen distintas velocidades de bits y resoluciones para ofrecer una reproducción fluida independientemente de las condiciones de la red. Todo lo que se necesita para generar un manifiesto son las tasas de bits de cada lista de reproducción y sus rutas relativas.
Rellenar los espacios en blanco
Hay muchos otros datos importantes que una plataforma de vídeo en línea debería capturar para cada activo de vídeo codificado: el códec de vídeo, el códec de audio, el contenedor y la tasa de bits total son sólo algunos. Los datos almacenados para un único elemento de vídeo deben ser significativos para el espectador (descripción, clasificación, reparto), significativos para la plataforma (duración, visionados, participación) y significativos para las aplicaciones (formato, resolución, tasa de bits). Con estos datos, el espectador puede decidir qué ver, el sistema puede decidir cómo programar y la aplicación puede decidir cómo reproducir.
Al capturar los datos necesarios para generar programáticamente una lista de reproducción, un manifiesto y la información del códec para cada una de las listas de reproducción, se hace posible disponer de un sistema en el que los manifiestos y las listas de reproducción se generan por solicitud.
Ejemplo - La primera lista de reproducción
La especificación HLS determina que la lista de reproducción que aparezca en primer lugar en el manifiesto será la primera elegida para reproducirse. En el ejemplo de la sección anterior, el primer elemento de la lista era también la pista de mayor calidad. Eso está bien para los usuarios con una conexión a Internet rápida y estable, pero para las personas con conexiones más lentas la reproducción tardará un poco en iniciarse.
Sería mejor determinar si el dispositivo parece tener una buena conexión a Internet y luego personalizar la lista de reproducción en consecuencia. Por suerte, con la generación dinámica de manifiestos, eso es exactamente lo que el sistema está preparado para hacer.
A efectos de este ejercicio, supongamos que se solicita un manifiesto con una matriz ordenada de velocidades de bits. Por ejemplo, la petición [2040,1540,1040,640,440,240,64] devolvería una lista de reproducción idéntica a la de la sección anterior. En iOS, es posible determinar si el usuario está conectado por WiFi o por móvil. Dado que se han capturado datos sobre cada lista de reproducción, incluyendo bitrate, resolución y otros parámetros similares, una aplicación puede decidir de forma inteligente cómo ordenar el manifiesto.
Por ejemplo, se puede determinar que es mejor empezar entre 800-1200kbps si el usuario está en WiFi y entre 200-600kbps si el usuario está en una conexión celular. Si el usuario estuviera en wifi, la aplicación solicitaría un array parecido a: [1040,2040,1540,640,440,240,64]. Si la aplicación sólo detectara una conexión móvil, solicitaría [440,2040,1540,1040,640,240,64].
Ejemplo - El dispositivo heredado
En Android, el soporte de vídeo es una especie de caja negra. Durante años, la documentación oficial de Android sólo admitía el uso de vídeo mp4 h.264 de 640×480 de línea de base, aunque algunos modelos eran capaces de manejar 1080p. En el caso de HLS, el soporte es aún más fragmentado y difícil de entender.
Por suerte, Android está dominado por un puñado de dispositivos estrella. Con los manifiestos dinámicos, la aplicación no solo puede determinar cuál es la mejor lista de reproducción para empezar, sino también excluir las listas de reproducción que se consideren incompatibles.
Dado que nuestros elementos multimedia también capturan datos como la resolución y la información del códec, la asistencia puede dirigirse a dispositivos específicos. Una aplicación podría decidir enviar todas las variantes de representación: [2040,1540,1040,640,440,240,64]. O bien, un dispositivo antiguo que sólo admita hasta 720p podría eliminar la variante de representación más alta: [1540,1040,640,440,240,64]. Además, más allá del mundo de los dispositivos móviles, si la aplicación es un televisor conectado, podría eliminar las variantes de representación de menor calidad: [2040,1540,1040,640].
Dinámico o estático
Elegir un modelo de manifiesto estático está perfectamente bien. Se pierde algo de flexibilidad, pero la simplicidad no tiene nada de malo. Muchos casos de uso, especialmente en el mundo del contenido generado por el usuario, no requieren la cantidad de complejidad que implica la generación dinámica; sin embargo, la generación dinámica de manifiestos abre muchas puertas para aquellos dispuestos a dar el paso.
El modo en que se traten los manifiestos tendrá un impacto significativo en la flexibilidad a largo plazo de una plataforma de vídeo, y es algo que debería discutirse con su compresionista residente.
