Streaming Adaptativo en Internet
octubre 24, 2011 in Internet, Television
Hay 4 cosas que importan para dar un servicio de streaming en Internet:
- El códec y contenedor: típicamente se usa el códec H.264 en un contenedor MP4 Part 14 o Flash
- El protocolo: HTTP progressive download o Streaming.
- El servidor de streaming: existen buenas comparativas en Internet de ellos.
- El cliente
Aquí trataremos de explicar lo que hay que saber y tener en cuenta para dar o recibir un servicio de streaming por Internet con calidad.
El códec
Parece que el códec H.264 se impone sobre su competencia Silverlight, Flash, VP8 u otros como el standard de la industria. Por lo tanto este tema parece claro y no será objeto de este post.
Detalle del estado de los códecs soportados por los PC’s y móviles
Los protocolos de distribución de vídeo en Internet e implementaciones varias: HTTP Progressive download vs streaming
En lo que sí parece que hay más debate y cierto lío es entre los diferentes protocolos de distribución del vídeo, diferenciándose 2 familas: Download progresivo o streaming. El siguiente gráfico nos presenta la diferentes alternativas:
La experiencia de usuario usando cualquier de estos protocolos de distribución es similar, pero sin embargo son distintos.
1) El más veterano es el segundo, la distribución por media streaming. Usa los protocolos IP RTSP, RTP y RTCP o RTMP para Flash, protocolos mucho más eficientes en cuanto al consumo de ancho de banda en el servidor y cliente, pero a costa de mayor complejidad en el lado del servidor y mayores requerimientos de CPU, memoria, baterías, etc. de los dispositivos. Típicamente se distribuyen contenedores Flash y Quicktime.
2) Sin embargo, en los últimos tiempos, con la aparición del iOS y la férrea oposición de Steve Jobs/Apple a dar soporte a Flash en sus dispositivos, así como la decisión final sobre el códec a emplear en la especificación HTML5 (para etiqueta “video”) se ha popularizado adopción de protocolos de distribución de vídeo basados en HTTP.
Existen fundamentalmente 3, HTTP Live Streaming respaldado por Apple, Smooth Streaming de Microsoft y HTTP Dynamic Streaming defendido por Adobe. Todos ellos tienen algo en común: todos usan MPEG-4 H.264 como entrada.
Los tres métodos son Adaptive Bit Rate Streaming, lo que permite que la experiencia de usuario se ajuste al verdadero ancho de banda del que dispone el usuario en cada momento y del estado de su CPU. En otras palabras, un streaming adaptativo puede subir o bajar en bit rate o resolución de una transmisión en “real time” en función de las condiciones del player en un momento dado.
¿Cómo funciona el HTTP progressive download?
La siguiente es la arquitectura de streaming de HLS de Apple, quizá la más sencilla de explicar:
En la misma podemos ver la fuente de vídeo, el encoder, el segmenter, la distribución de ficheros en server web tradicional y el cliente. Trataré de explicar el funcionamiento de los protocolos de Streaming HTTP partiendo de la base éste y apoyándome en el workflow de Adobe Flash Media Server que es igual para todos.
![clip_image002[4]](http://www.javierrodriguez.com.es/blog/wp-content/uploads/2011/10/clip_image0024.jpg "clip_image002[4]")
En una configuración típica, existen 4 fases:
- Preparación: un encoder hardware (p.e. Envivio) toma el audio y video de entrada, lo codifica como vídeo H.264 y audio AAC, y lo devuelve en un archivo MPEG-2 Transport Stream, que luego se divide en una serie de pequeños ficheros multimedia de unos 10 segundos de duración (llamados chunks o segmentos) por parte de un segmenter software. Estos archivos se colocan en un servidor web normal como un Apache. El segmentador también crea y mantiene un archivo de índice que contiene una lista de los archivos en los que se ha partido el vídeo original. La dirección URL del archivo de índice se publica en el servidor web. El index file es un
.M3U8, laplaylist. Este proceso de codificación y segmentación se repite para cada una de las calidades que deseen emitir del vídeo (lo que es la base del Adaptative Streaming). - Distribución: La URL del fichero index es accedida por los clientes, los cuales entonces piden los ficheros indexados en secuencia. Los ficheros son servidos por un servidor web tradicional, como Apache o IIS.
- DRM: es una etapa opcional.
- El software de cliente es el responsable de determinar los ficheros o chunks apropiados a pedir por HTTP, descargarlos y reemsamblarlos para poder presentarlos al usuario en un stream de vídeo continuo. Si en un momento dado las condiciones del cliente varian, es el responsable de pedir chunks de calidad más baja y regular así la calidad del stream.
HTTP Dynamic Streaming de Adobe es más o menos lo mismo, pero se diferencia fundamentalmente de HLS en que la etapa del segmenter para el VoD la hacen las herramientas del propio Adobe Flash Media Server, tiene soporte de contenedores FLV y el usuario no se descarga el fichero completamente para ver el vídeo como en HLS. HTTP Smooth Streaming de Microsoft se diferencia fundamentalmente de HLS en que la etapa del segmenter para el VoD la hacen las herramientas del propio IIS y que soporta Silverlight como contenedor de vídeo tb.
Todos ellos soportan emisiones en directo, siguiendo el mismo workflow que el VoD.
Adaptive Bit Rate Streaming
Los tres métodos son Adaptive Bit Rate Streaming, lo que permite que la experiencia de usuario se ajuste al verdadero ancho de banda del que dispone el usuario en cada momento y al estado de su CPU. En otras palabras, un streaming adaptativo puede subir o bajar en bit rate o resolución de una transmisión en “real time” en función de las condiciones del player en un momento dado. Simplemente el player tiene que descargar nuevos chunks de calidad más baja y reproducir los nuevos.
Ventajas/Inconvenientes del progressive download
Ambos métodos para hacer distribución de vídeo (descarga progresiva o streaming real) son perfectamente viables. Sin embargo, a niveles de costes para el editor o distribuidor de vídeo, es más interesante hacer descarga progresiva ya que:
- Se pueden usar los mismos servidores web de siempre, no se requieren servidores de streaming específicos y licencias caras.
- Se puede usar las CDNs tradicionales web de toda la vida, ya que los chunks no son más que pequeños ficheros de vídeo bien identificados
- Sin embargo, ya que se baja un fichero temporalmente al dispositivo de cliente, es menos robusto ante el pirateo de contenidos.
Para el cliente:
- Menos exigencias de recursos para CPU, memoria
- Sin embargo, el usuario se descarga el fichero completamente para ver el vídeo (vs en streaming que sólo descarga lo que ha visto), salvo en las implementaciones de HTTP Dynamic Streaming de Adobe.
- Dado lo anterior, las exigencias de ancho de banda son mayores, ya que para un vídeo 20MB en streaming tradicional un usuario se puede bajar 20MB máximo si ve el vídeo completo, mientras que en HTTP download progresivo puede llegar a bajarse, para ver el vídeo completo, 20MB multiplicado por el nº de calidad disponibles en el servidor, p.e. 100MB
Concluyendo
El quick de la cuestión es que el “HTTP download progresivo” mejora de costes para los editores, aunque genere ineficiencias en cuanto a tráfico para el cliente final…
En cuanto a referencia quizá lo más importante sea que varios grandes emisores de video de US como la ABC, Netflix o Hulu estan adoptando HLS en sus iPad Apps. O que en UK la BBC esta haciendo pruebas HD HTTP Streaming . Mientras en España el Grupo Prisa ya usa el encoder de Envivio para hacer HLS tb.
Añadido
Como curiosidad podemos ver la arquitectura de un grande de todo esto en Internet, Justin.tv.
Más info:
http://videotechnology.blogspot.com/2011/06/hls-http-live-streaming.html
http://mashable.com/2011/01/25/adaptive-bit-rate-video-streaming/
http://blogs.adobe.com/actionscriptdocs/2010/06/tutorial_http_dynamic_streamin_1.html
http://help.adobe.com/en_US/HTTPStreaming/1.0/Using/index.html
http://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems#General
http://www.adobe.com/products/flashmediastreaming/
http://www.adobe.com/products/httpdynamicstreaming/
Twineame
Menéame
Tradicionalmente los operadores Tier 2 y 3 han huido de las soluciones de IPTV con Microsoft debido al alto coste que tenía el middleware en términos de licenciamiento así como alto nº requerido de servidores.
