Capítulo II: Tecnología multimedia
En este capítulo se presenta una introducción a la tecnología del streaming, a las tecnologías multimedia relacionadas y al estado del arte del streaming multimedia.
Introduccion
Noventa minutos de video sin comprimir digitalizado en formato High Definition Television (HDTV) a 1.2 Gbps requieren 791 GB de almacenamiento. Ni los más modernos dispositivos de almacenamiento permiten semejantes cantidades. Y aún, si lo proveyeran, no se podría tener semejante espacio ocupado por una sola película. Más aún si se lograra almacenar, todavía queda por ver que el ratio de transferencia desde disco, no lograría transferir la suficiente cantidad de datos como para soportar la reproducción de varios objetos en tiempo real. Un problema mas serio todavía ocurriría si se hiciera la distribución de objetos de tal tamaño, porque si bien la velocidad de las redes incrementa permanentemente no resulta económicamente posible soportar el envío simultaneo de semejantes volúmenes de información para pocos destinatarios. (1)
Para resolver estos problemas y manejar eficientemente un gran número de objetos SM (Streaming Media), se necesita comprimir a los mismos. Ya que un objeto SM más pequeño requiere menos espacio de disco y menos ancho de banda. A continuación examinaremos brevemente algunos conceptos importantes de las técnicas de compresión de datos.
Codificados entrópicos y no entrópicos
La entropía (2) es una mesura del monto de información. Si en un sistema N estados son posibles, cada uno con una probabilidad pi y donde
luego S = -
Donde S es la entropía y describe la menor cantidad de bits requeridos para describir a todas las partes del sistema. Un ejemplo clásico es la cantidad de bits necesarios para codificar una imagen con una distribución uniforme de tonos de gris donde la probabilidad de un tono cualquiera es de 1/256, se requerirían 8 bits para codificar cada tono de gris y se diría que la entropía de la imagen es de 8.
El codificado por entropía ignora la semántica y comprime un flujo de media tratándolo como una secuencia de bits. Los codificados Huffman (2) y Run-length (2) (3) son esquemas de codificado entrópico.
Por el contrario source coding (2) optimiza el ratio atendiendo a las características específicas del material. Por ello es también llamado codificado basado en semántica. Varios esquemas de codificado avanzado entran en esta categoría, tales como DPCM (2), DCT (2), FFT (2) y Wavelet (4). En realidad los algoritmos de compresión más populares, emplean un hibrido entre codificado semántico y entrópico, aplicando en una primera fase codificado semántico y luego codificado entrópico a los resultados de la primera fase, para reducir el tamaño de los datos.
Bitrate y codificado constante y variable
El término bitrate o tasa de bits define el número de bits que se transmiten por unidad de tiempo a través de un sistema de transmisión digital o entre dos dispositivos digitales. La unidad con que el SI (Sistema Internacional) (5) expresa el bitrate es el bit por segundo (bit/s, b/s, bps). Así pues, el bitrate es básicamente una medida de la velocidad de transferencia de datos. En multimedia el bitrate es la relación de bits por segundo que consume un fichero de audio, o de vídeo.
Cuando hablamos de códecs, la codificación con tasa de bits constante implica que la tasa de salida del codificador de los datos es constante. La codificación Constant Bit Rate (CBR) es muy útil para flujo de datos multimedia con canales de capacidad limitada. Sin embargo, CBR no es la mejor opción para almacenaje ya que no asignará suficientes bits para las secciones “complicadas” (resultantes de la degradación de la calidad) y por el contrario gastará bits innecesarios en secciones “simples”.
Muchos esquemas de codificación, como por ejemplo, la codificación Huffman producen códigos de longitud variable lo que dificulta el uso de un CBR. Esto se arregla parcialmente variando la cuantificación y por tanto la calidad. Y, se consigue solucionar el problema por completo, usando bits de relleno (padding) (6). Otra estrategia alternativa consiste en almacenar la tasa de bits en un buffer y liberar la información con una tasa de bits constante. Método conocido como leacky bucket (7).
El Variable Bit Rate (VBR), a diferencia del CBR, aplica una cuantificación no uniforme. Teniendo en cuenta si en la señal hay zonas con mayor o menor densidad de información y cuantificando la señal en forma diferenciada, asignando más bits donde mayor complejidad multimedia haya. Este método de compresión consigue una mayor calidad en ficheros de menor tamaño.
La utilización de uno u otro tipo de bitrate para la ejecución de objetos multimedia tiene un correlato obvio en el consumo de ancho de banda. En anchos de banda limitados normalmente la opción preferida es CBR, dado que este modo consume un ancho de banda constante durante toda la transmisión. La desventaja es que la calidad de la imagen variará y, aunque se mantendrá relativamente alta cuando no hay movimiento en la escena, bajará significativamente cuando aumente el movimiento.
El modo VBR, por otra parte, mantendrá una alta calidad de imagen, si así se define, sin tener en cuenta si hay movimiento o no en la escena. Esto es a menudo deseable en contenidos de alta calidad, especialmente si no hay movimiento en la escena. Dado que el consumo de ancho de banda puede variar, incluso si se define una media de ratio de bits objetivo, la infraestructura de red (el ancho de banda disponible) necesitará tener esta capacidad para un sistema de este tipo.
Codificado de vídeo
Formato MJPEG
Debido a su simplicidad, el formato Motion JPEG (MJPEG), un estándar en muchos sistemas, representa a menudo una buena elección para transmitir vídeo. Se trata básicamente de un formato de vídeo (8) donde cada frame de una secuencia está comprimido separadamente como una imagen JPEG. Ofrece un retraso limitado entre la captación de imágenes en una cámara, la codificación, la transferencia a través de la red, la descodificación y finalmente su representación en la estación de visualización. En otras palabras, Motion JPEG ofrece un tiempo de espera bajo debido a su simplicidad y, por tanto, también es apto para el procesamiento de imágenes, esto es, la detección de movimiento o el seguimiento de un objeto. Cualquier resolución de imagen práctica, desde un tamaño de pantalla de teléfono móvil (QVGA) hasta un tamaño de imagen de vídeo entera (4CIF) se encuentra disponible en Motion JPEG.
El sistema garantiza la calidad de la imagen independientemente de su complejidad o movimiento, a la vez que ofrece flexibilidad para seleccionar una calidad de imagen superior (compresión baja) o una calidad de imagen inferior (compresión alta) obteniendo así ficheros de imagen de tamaño inferior y un uso del ancho de banda y bitrate menores. La velocidad de imagen puede ajustarse fácilmente para limitar el uso de ancho de banda, sin perder la calidad de la imagen.
Sin embargo, Motion JPEG genera un volumen relativamente grande de datos para ser enviados a través de la red. El estándar Motion Picture Experts Group (MPEG), en cambio al explotar las similitudes entre frames (fotogramas), tiene la ventaja de lograr generalmente un bitrate menor (en comparación con Motion JPEG). Pero cuando el vídeo está tomado a velocidades de imagen bajas, está característica pierde parte de su efectividad compresora y el rendimiento de MJPEG equipara o incluso supera el de MPEG, tal como vemos en el siguiente gráfico:
Estándar MPEG
El grupo de trabajo Motion Picture Experts Group inició el desarrollo de estándares de vídeo para tratar el almacenamiento de vídeo y audio, a finales de los 80’. Actualmente es la International Telecommunications Union (ITU) quién se encarga del mantenimiento de los documentos MPEG. En términos del modelo OSI, los estándares MPEG se ubican residiendo en las capas de Presentación y Sesión.
Para conseguir una elevada eficiencia de compresión MPEG se basa en el cálculo de la Transformada del Coseno Discreta (DCT). De manera general, este tipo de codificadores pueden generar dos tipos de imágenes diferentes: imágenes Intra, (I), codificadas sin dependencia temporal con ninguna otra imagen e imágenes Inter, codificadas utilizando información relativa a otras imágenes anteriores y/o posteriores. Las tramas Inter pueden ser de tipo P (Predicted frames) o de tipo B (Bidirectional Frames). El primer tipo de tramas (P) toman como referencia una trama I o P.
Las tramas B toman como referencia tramas I o P codificadas anterior y/o posteriormente. Ningún tipo de trama toma como referencia una trama B, por lo que la pérdida de este tipo de tramas no produce propagación de errores. Con este tipo de frames se logran funcionalidades como FF, FR, o el acceso aleatorio.
|
|
Dependencia entre tramas
|
La compresión/descompresión de información de media en formato mpeg implica una serie de procesos los cuales pueden verse en la Error: Reference source not found. Durante el proceso de compresión, el primer cuadro de una secuencia de vídeo se codifica de modo intracuadro, sin ninguna referencia respecto a anteriores o futuros cuadros. Es lo que se llama I-picture. Los siguientes cuadros se codifican usando predicción intercuadro (P-picture). La predicción se basa en los datos del cuadro codificado inmediatamente anterior, ya sea I-picture o P-picture.
Para la codificación de las P-pictures, el cuadro anterior es almacenado (FS, frame store) tanto en el codificador como en el decodificador.
Figura - Arquitectura de un codec mpeg
Una característica importante de los algoritmos MPEG es la flexibilidad en la tasa binaria, que puede variarse ajustando el escalón de cuantificación (en la cuantificaión de los coeficientes DCT) según las exigencias de cada aplicación en particular. Esto permite el almacenamiento o transmisión de vídeo con alto nivel de compresión.
Como norma general, una secuencia codificada usando sólo I-pictures (IIII...) consigue el mayor grado de accesibilidad pero la compresión más baja. Si se codifica combinando I- y P-pictures (IPPPPPIPPPP...) se consigue una solución de compromiso entre ambos aspectos, y si se usa la combinación de las tres (IBBPBBPBBI...) se consigue un alto grado de compresión y una razonable accesibilidad, aunque se aumenta el retardo de codificación, lo que lo hace inviable para aplicaciones de videotelefonía o videoconferencia.
Los formatos que utilizan frames B (bidireccionalmente predictivo) reconstruyen estos frames utilizando datos desde un futuro frame I o P el cual sera mostrado algo después de que el frame B sea mostrado. Esto es , las codificaciones basadas en B frames requieres (para que la decodificación sea factible) que el frame I o P requerido aparezca primero. Por ejemplo, si una sección de un archivo tiene cuatro frames de tipos I, B, B, P a ser renderizados como frames 1, 2, 3 y 4 respectivamente, esos cuatro frames debe ser codificados en el siguiente orden: I, P, B, B.
De esta forma el decoder tiene toda la información que necesita para decodificar los frames B. El decoder, primero decodifica y muestra el frame I, luego decodifica el P pero no lo muestra todavía. Usando esta información el decodifica los dos B siquientes. Finalmente muestra el P que ya había sido decodificado antes.
Otros estándares Mpeg
Los siguientes estándares MPEG están disponibles actualmente para comprimir y descomprimir video.
MPEG1— Desarrollado al final de los 80’, principios de los 90’ para almacenamiento y recuperación de audio y vídeo desde dispositivos de alta capacidad como cintas y CD-ROMs.
MPEG2— Desarrollado a mediados de los 90’ para la transición de la industria de la TV desde la TV analógica a la digital (DTV). La mayoría de los DVD de hoy contienen media en formato MPEG2. La visualización de contenidos MPEG2 es una funcionalidad bajo licencia. Comunmente estos derechos están incluidos en la compra del Player.
MPEG4— Fue desarrollado a finales de los 90’ e introdujo el concepto de los contenidos como objetos manipulables individual o colectivamente. Aunque MPEG4 es un estándar, el software requiere una licencia basada en royalty. MPEG4 no contiene capacidades DRM, no obstante puede enganchar con soluciones DRM propietarias. Este formato está basado en el formato de los archivos Apple QuickTime. MPEG4 es el único estándar MPEG con capacidades para streaming.
MPEG7— Actualmente es un borrador bajo desarrollo para proveer una interface de descripción multimedia que agregue una dimensión semántica los contenidos multimedia.
MPEG21— También en desarrollo actualmente MPEG21 es un framework multimedia que cubrirá toda la cadena de distribución de contenidos multimedia incluyendo creación de contenidos, producción, distribución, comercio y consumición.
En el contexto de esta tesis MPEG-4 tiene especial importancia por ser uno de los pocos formatos para streaming soportado por los dispositivos móviles.
Streaming
Introducción al Streaming de Media
Muchas aplicaciones tradicionalmente fueron analógicas (como la TV) han evolucionado para utilizar audio y vídeo digital. La proliferación de media digital se ha visto facilitada por la amplia aceptación de los estándares de formato y compresión. Los dispositivos de hogar ya soportan desde hace rato estos estándares en Digital Versatile Disk (DVD y Digital VHS (D-VHS)). Y más todavía, el incremento de la capacidad de las redes de área local (LAN) y los protocolos de streaming como RTSP, permiten la visualización de clips de media en modo remoto. Para posibilitar esto último es necesario un Servidor Multimedia.
Formalmente un Servidor Multimedia (SMM) es un sistema que utiliza información de audio y/o video, para proveer una comunicación efectiva. Pero a diferencia de los datos tradicionales como texto e imágenes, los objetos multimedia son usualmente grandes. Por dar un ejemplo, 2 horas de video codificado en mpeg-2 (a un ratio de 4 Mb/s) ocupan 3.6 Gb. de almacenamiento. Por ello una de las tareas más críticas en la implementación de un SMM es el soporte del ancho de banda necesario para ofrecer Streaming Media (SM).
La naturaleza síncrona de los objetos para SM requiere una ejecución ordenada en el tiempo a un ratio específico. Por ejemplo el estándar NTSC requiere 30 fps. Cualquier desviación de estos requerimientos puede resultar en defectos, interrupciones y jitter, colectivamente llamados hiccups (1).
Hay un número de paradigmas posibles para mostrar objetos SM tal como se muestra en la Error: Reference source not found.
Figura - Paradigmas de distribución
Estos paradigmas se definen en concordancia con:
La ubicación del objeto SM (local vs. remoto) y
Las capacidades de la red y de los servidores (no-streaming vs. streaming).
Dependiendo de las capacidades del servidor y de la red tenemos dos paradigmas alternativos
Store-and-Display (Almacena y renderiza)
Streaming
En 1., el objeto es bajado completo antes de ser visualizado. Este paradigma es aplicable cuando el servidor y/o la red no pueden garantizar la naturaleza sincrónica del objeto. En 2., (el paradigma de streaming) los bloques de datos son recibidos y procesados por el cliente para su visualización en modo inmediato. Los bloques de datos no son almacenados localmente sino que se almacenan temporariamente en un buffer del dispositivo. Este paradigma es posible cuando tanto la red como el servidor pueden garantizar una reproducción en concordancia con la naturaleza sincrónica del contenido.
Es importante no confundir streaming con download progresivo, ya que en el download progresivo si bien el objeto SM comienza a ser visualizado apenas se comienzan a recibir sus datos (y se solapa la visualización con el download), los datos recibidos si son almacenados localmente (requiere suficiente capacidad de almacenamiento en el cliente). Según se vea, download progresivo puede ser un caso particular del paradigma de streaming (si el sistema puede garantizar que la reproducción este libre de hiccups) o un caso especial del paradigma store-and-display.
Para poder realizar streaming es necesario que el bitrate de la media sea menor que el ancho de banda de la red. En términos de ventajas y desventajas de la técnica de streaming podemos citar:
Ventajas
|
Desventajas
|
Poca espera para la visualización.
No se almacena localmente el contenido con lo cual no se vulneran derechos de propiedad en caso de que el material los tuviera.
No se requiere almacenamiento en el cliente.
Soporte de eventos en vivo.
|
El requerimiento de que tanto el servidor como la red garanticen el tiempo real.
Los paquetes perdidos o dañados pueden causar hiccup en la visualización del objeto SM.
|
|
