incorporaciÓn de correcciÓn de errores y mÉtricas de ... · se desarrolló una técnica de...

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

INCORPORACIÓN DE CORRECCIÓN DE ERRORES Y MÉTRICAS DE CALIDAD AL CODEC DE TRANSMISIÓN

DE VIDEO TOLERANTE A FALLAS

MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN

FELIPE IVAN LALANNE ROJAS

PROFESOR GUÍA: JOSE MIGUEL PIQUER GARDNER

MIEMBROS DE LA COMISIÓN: PATRICIO INOSTROZA FAJARDIN

ERIC PIERRE TANTER

SANTIAGO DE CHILE ABRIL 2007

RESUMEN DE LA MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN POR: FELIPE LALANNE R. FECHA: 16/04/2007 PROF. GUÍA: Sr. JOSÉ MIGUEL PIQUER "INCORPORACIÓN DE CORRECCIÓN DE ERRORES Y MÉTRICAS DE CALIDAD

AL CODEC DE TRANSMISIÓN DE VIDEO TOLERANTE A FALLAS"

Durante el trabajo realizado se estudiaron métricas de calidad de video y técnicas de corrección de errores de imagen, para su incorporación a una aplicación de transmisión de video. El objetivo principal del estudio es el de aumentar la tolerancia de dicha aplicación a pérdidas de red, entregando resultados numéricos formales que demuestren las mejoras alcanzadas. La distribución de contenido multimedia sobre Internet debe considerar las pérdidas de paquetes como un factor fundamental e ineludible. Las aplicaciones de transmisión de video actuales realizan una gran labor en términos de compresión de datos, pero presentan importantes falencias en términos de tolerancia a pérdidas. Durante trabajos realizados por memoristas anteriores se ha ido desarrollando una aplicación de distribución de video, la cual ha mostrado grandes avances en términos de minimizar el impacto producido por pérdidas de paquetes durante la transmisión. En la última versión se obtuvo una escena identificable aún bajo condiciones de 30% de pérdidas. La degradación producida en el video recibido toma la forma de pixeles erróneos claramente distinguibles del resto de la imagen. El problema actual consiste en encontrar una forma de corregir los errores producidos por pérdidas en la imagen recibida, demostrando el incremento de calidad logrado a través de resultados formales. Tales cambios tendrán como resultado un aumento de la tolerancia de la aplicación a pérdidas de red. Se desarrolló una técnica de corrección de errores, en donde cada píxel erróneo es reemplazado por el valor de sus vecinos cercanos. Para evaluar la mejora obtenida por este método, se diseño e implementó una métrica de calidad, en base a detección de errores en la imagen, analizando las variaciones del valor de los pixeles en la imagen recibida. Los resultados retornados por la métrica mostraron una mejora significativa en la calidad de la imagen como causa de la corrección efectuada. La métrica, por su parte, mostró consistencia con los errores observados en el video, demostrando ser una buena herramienta de evaluación. Se concluyó que es posible realizar corrección de errores satisfactoriamente, sin necesidad de agregar datos adicionales o redundancia a la transmisión.

A mis Padres, por su eterno apoyo.

Índice general

1. Agradecimientos 1

2. Introducción 2

2.1. Justificación / Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Situación Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5. Trabajo Realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.6. Estructura de la Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3. Revisión Bibliográfica 8

I

3.1. Trabajo Previo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2. Métricas de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3. Transmisión tolerante a fallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4. Desarrollo 13

4.1. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2. Descripción del codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1. Servidor de Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.2. Cliente de Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3. Optimizaciones Iniciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.1. Incorporación de herramientas autoconf y automake . . . . . . . . . . . . 19

4.3.2. Reestructuración de código . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4. Desarrollo de métricas de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4.1. Métricas de parámetros de red . . . . . . . . . . . . . . . . . . . . . . . . 23

II

4.4.2. Métricas de calidad perceptual de video . . . . . . . . . . . . . . . . . . . 24

4.5. Corrección de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5.1. Aplicación de prueba de técnicas . . . . . . . . . . . . . . . . . . . . . . . 33

4.5.2. Corrección de errores por promedio . . . . . . . . . . . . . . . . . . . . . 34

4.5.3. Corrección de errores por mediana de módulo . . . . . . . . . . . . . . . . 35

4.5.4. Corrección de errores por mediana de componentes . . . . . . . . . . . . . 36

4.5.5. Corrección de errores probabilística . . . . . . . . . . . . . . . . . . . . . 37

4.5.6. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5. Análisis 41

5.1. Métodos de corrección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2. Métrica de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6. Mejoras finales y trabajo relacionado 53

III

6.1. Detección de movimiento en YUV . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2. Limitación de tasa de captura de video . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3. Cliente Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.4. Cliente J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7. Conclusiones 62

8. Trabajo Futuro 64

8.1. Compresión de imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.2. Retro-alimentación de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A. Glosario 69

IV

Capítulo 1

Agradecimientos

Gracias a NIC Chile y Entel PCS por proveer el financiamiento necesario para llevar a términola actual memoria. Gracias a mi familia y amigos por el apoyo que me han dado en éstos meses detrabajo.

1

Capítulo 2

Introducción

Con el avance de la tecnología, la necesidad de información en tiempo real se ha hecho cadavez más inminente. La distribución de contenido multimedia en internet, en particular de video, haalcanzado cada vez un mayor auge. Sin embargo, aún en la actualidad no existen aplicaciones querealicen esta tarea en tiempo real de manera satisfactoria.

La dificultad principal de este tipo de aplicaciones, radica en la gran cantidad de informaciónque es necesario transmitir, y en la imposibilidad de asegurar la correcta transmisión de ésta desdeel servidor al cliente. Es por eso que la propiedad de tolerancia a pérdidas adquiere relevancia.

La presente memoria pretende extender el trabajo realizado por memoristas anteriores [11, 1, 4],en el área de transmisión en tiempo real sobre redes IP tolerante a fallas. La intención es desarrollaruna aplicación que aproveche la plataforma de trabajo desarrollada por las investigaciones ante-riores, agregando mayor tolerancia a la pérdida de datos en la transmisión y conservando lo mejorposible la calidad del video original.

Se pretende incorporar corrección de errores producidos por pérdidas en la imagen recibida porel cliente, y definir métricas de calidad perceptual del video para evaluar las mejoras producidaspor dicha corrección.

2

2.1. Justificación / Motivación

Con el creciente aumento de las velocidades de conexión en Internet, la distribución de conteni-do multimedia, y en particular de video en tiempo real, ha alcanzado cada vez un mayor auge. Estetipo de aplicaciones presentan un gran desafío en términos de desarrollo e investigación, debidoa que la calidad del servicio está determinada no sólo por la eficiencia en la transmisión de losdatos, sino que por la calidad de la imagen percibida por el usuario. En la actualidad las técnicasde compresión utilizadas se enfocan principalmente en la primera parte: transmitir la mayor canti-dad de información en un corto tiempo. Sin embargo, de acuerdo a la estructura actual de Internet,es fundamental considerar las pérdidas de datos durante la transmisión para alcanzar el segundoobjetivo. Es necesario entonces tener en cuenta dos puntos: definir cuál es la forma más eficientede transferencia de datos para disminuir el porcentaje de degradación de la imagen percibido porel usuario, y estudiar una estrategia a seguir en caso de pérdidas de datos para establecer en quécasos es posible corregir los defectos en la imagen final de manera de proveer una mejor calidad deservicio para el usuario final. El desarrollo de estos dos puntos es lo que motiva este trabajo.

2.2. Situación Actual

Las aplicaciones de transmisión de video en tiempo real sobre Internet, en particular sobre redesIP, son altamente demandantes de recursos de red, debido a la gran cantidad de información quees necesario transmitir. Distintas tecnologías se han desarrollado en el último tiempo para satisfa-cer las crecientes necesidades de los usuarios de este tipo de contenido. Entre éstas se encuentranel desarrollo de redes de mayor ancho de banda y de dispositivos de almacenamiento de mayorvelocidad [20], junto con el mejoramiento de las técnicas de compresión de datos. El concepto in-herente de estas últimas es el de disminuir la cantidad de información transmitida a través de la redmediante la reducción de redundancias en los datos enviados. Por ejemplo, durante la reproducciónde un video, se puede decidir enviar sólo los bits de información que han cambiado entre cuadrosconsecutivos.

Uno de los grandes problemas de la transferencia de datos a través de Internet es la pérdida depaquetes entre el emisor y el receptor. En aplicaciones de video en tiempo real esto es aún máscrítico, ya que no es factible esperar la retransmisión de dichos paquetes sin afectar la calidad delservicio percibido por el usuario. La solución entonces es desplegar los datos conforme se van re-

3

cibiendo, ya que para el usuario es menos molesto ver un video de manera continua pero de calidaddeteriorada que tener que esperar para ver una imagen completa. El enfoque actual es entoncesdefinir métricas de calidad [6, 18] , de manera de poder determinar de forma más específica cuálesson las condiciones bajo las que el servicio se ve mejorado o deteriorado y además en qué medidase pueden reparar los errores ocasionados por pérdida de datos.

Una métrica de calidad de video se encarga de estimar la calidad de la imagen percibida por elusuario final. Dentro del desarrollo de métricas, se pueden distinguir dos enfoques distintos [18]:a) Unos utilizan modelos computacionales de la visión humana. Generalmente estos son bastanteprecisos, sin embargo son de gran complejidad y costo computacional, debido a que muchas de lascaracterísticas de la visión humana aún no son completamente claras. b) Otras métricas aprovechanel conocimiento de los algoritmos y métodos utilizados para compresión y transmisión de video.De esta forma se puede determinar cuales son los errores que el usuario percibe y realizar una me-dición sobre estos para análisis posteriores.

Una vez recibidos los datos en el cliente, si se detectan pérdidas de paquetes durante la transmi-sión, se debe buscar entonces una forma de corregir dichas pérdidas. Existen distintos enfoques pararealizar esto, uno de las cuales es incorporar redundancia de datos a los paquetes enviados. De estamanera, en caso de existir una pérdida, es posible reconstruir parte o la totalidad de la informaciónfaltante. Uno de los protocolos más utilizados para esto es el de FEC (Forward Error Correction).Éste utiliza álgebra binaria, particularmente el uso de O exclusivo (XOR), para calcular los datosredundantes y recuperar la información faltante. Sobre este protocolo se han realizado modifica-ciones para adaptar el nivel de redundancia de manera consistente con la congestión en la red [7].Dentro de este último, denominado AFEC, se pone de manifiesto la importancia de los mecanis-mos de control de redundancia, ya que superando un cierto punto puede volverse contraproducente,resultando en un aumento de la congestión de la red.

2.3. Objetivo General

El objetivo de este trabajo es complementar los resultados del trabajo de título realizado porCristian Junge [4]. En particular se desea estudiar más a fondo la forma de distribuir de la informa-ción de video en paquetes para disminuir la degradación en la calidad de la imagen percibida porel usuario. Además se espera determinar bajo qué nivel de pérdidas es posible realizar correccio-

4

nes sobre la imagen final e implementar dichas correcciones en una aplicación. Para realizar estose estudiarán algunas métricas de calidad de servicio (QoS) definidas actualmente para entregarresultados formales en la investigación.

2.4. Objetivos Específicos

Complementar el trabajo realizado en las memorias de título de Fermín Uribe [11], AlviseBolsi [1] y Cristian Junge [4], tomando como base sus resultados y realizar experimentossobre éstos para estudiar cuáles son los puntos que requieran una mejora y implementar éstasen una aplicación posterior.

Estudiar algunas métricas de calidad de servicio en sistemas de video sobre Internet paraentregar resultados formales de la calidad de servicio provista por la aplicación de video bajodistintas configuraciones y distintas condiciones de red.

Estudiar la mejor forma de distribuir la información en paquetes para disminuir el efectoproducida por las pérdidas en la calidad de la imagen final.

Estudiar formas de corregir los errores en la imagen desplegada, ocasionados por pérdidas dered e implementar dichas correcciones en la aplicación final.

Desarrollar una aplicación de demostración que integre los resultados de las investigacionesrealizadas para mostrar de manera empírica los avances obtenidos.

Concluir sobre los resultados obtenidos, entregando recomendaciones basadas en la expe-riencia adquirida durante el proyecto.

2.5. Trabajo Realizado

En la primera etapa se realizó una revisión bibliográfica y del estado del arte actual, en particularcon respecto a técnicas de corrección u ocultamiento de errores en imágenes.

Se decidió trabajar con el codec de Cristian Junge, por la importancia de los resultados obteni-dos en el área de transmisión de paquetes, con el objetivo de minimizar la degradación perceptual

5

por causa de pérdidas. Este codec distribuye de manera aleatoria en paquetes los pixeles de losbloques de imagen a transmitir, con el fin de minimizar el impacto producido por pérdidas en laimagen final.

Para lograr familiarización con el código y modo de funcionamiento del codec, la primera ta-rea realizada fue reordenar el programa en capas de captura de video, detección de movimiento,transmisión y recepción de paquetes. Junto con esto se procedió a documentar todo el código paramejorar la mantenibilidad de este en futuras versiones. Esta tarea requirió prácticamente de unare-escritura completa del programa, pero permitió a la vez lograr un entendimiento cabal del fun-cionamiento de cada una de las capas del códec.

Una vez logrado este objetivo se procedió a implementar cambios enfocados a medir la calidaddel video recibido por el cliente y a ocultar los pixeles perdidos durante la transferencia. Para estose efectuaron las siguientes tareas:

1. Se incorporó un módulo de recolección de estadísticas por cuadro de video. A partir de éstese pueden almacenar datos de cantidad de bytes, paquetes y bloques enviados y recibidos porla aplicación bajo distintas configuraciones y distintos niveles de pérdidas de paquetes. Estainformación se hace necesaria como complemento a las métricas de calidad de video.

2. Con el fin de detectar degradación en la imagen recibida, se implementó un módulo de detec-ción de errores. Éste se encarga de detectar diferencias de cada pixel con sus vecinos cercanosmediante distintas técnicas. Entre estas se pueden destacar, comparación de distancia entrecolores con los vecinos directos, diferencia con el promedio de colores de los vecinos, dife-rencia con la mediana de los vecinos. En cada uno de los casos citados, si la diferencia esmayor que un cierto margen obtenido experimentalmente, entonces se considera que el pixelesta perdido y se aumenta el valor de la degradación de la imagen. Para realizar una evalua-ción del funcionamiento de las distintas técnicas, se agregó un módulo de visualización deerrores. Éste permitió ver en línea los errores detectados a través de una ventana adicionalla cual los desplegaba en un color distinto al del fondo. Con los datos obtenidos, se definiócomo métrica de calidad el porcentaje de error de la imagen.

3. Para mejorar la calidad final de la imagen ante pérdidas, se procedió a corregir los pixelesperdidos a partir de la información de los vecinos, es decir, el color de cada pixel perdido sereemplazó por un valor obtenido a partir de los pixeles cercanos. Para obtener dicho valor serealizaron pruebas con distintas técnicas: promedio de los vecinos, mediana de los vecinos,mediana de componentes de vecinos y corrección probabilística. Para apreciar de maneraefectiva las mejoras introducidas por cada técnica, se implementó una aplicación de pruebaque simulaba pérdidas en una imagen, para posteriormente corregirlas utilizando alguno de

6

los métodos antes mencionados. Una vez determinada la mejor técnica, se procedió a in-corporarla al programa para corregir los errores en tiempo real, debido a esto se observaronmejoras considerables en la calidad final de la imagen, incluso para altas tasas de pérdidas.

Se llevaron a cabo diversos experimentos bajo distintos niveles de pérdidas para comparar ladegradación de la imagen determinada por la métrica de la imagen con y sin corrección de errores.Dichos experimentos se realizaron de manera controlada, utilzando clips de video en cada casopara asegurar que los resultados fueran comparables.

2.6. Estructura de la Memoria

El capítulo 1 contiene una introducción sobre el los objetivos y justificación del trabajo realiza-do. El capítulo 2 contiene una revisión bibliográfica de los conceptos relevantes para el desarrollode la memoria. El capítulo 3 describe en detalle las características del codec implementado y eltrabajo realizado. El capítulo 4 detalla las pruebas realizadas con la aplicación y los resultadosobtenidos. El capítulo 5 describe algunas modificaciones finales realizadas a la aplicación y al-gún trabajo relacionado con la misma. El capítulo 6 corresponde a las conclusiones. El capítulo 7entrega algunas pautas para la continuación del trabajo.

7

Capítulo 3

Revisión Bibliográfica

3.1. Trabajo Previo

Existe una gran cantidad de material disponible en el área de video sobre IP. Extensa inves-tigación se ha realizado en los temas de Streaming de video, calidad de servicio, adaptabilidad acondiciones de red, etc. Un buen ejemplo de esto se puede encontrar en [20]. En éste se realizauna descripción de las seis áreas claves en el desarrollo de un sistema de transmisión de video:compresión de video, calidad de servicio (QoS) en nivel de aplicación, servicios de distribucióncontinua de contenido multimedia, servidores de transmisión de contenido multimedia, sincroniza-ción de medios y protocolos de transmisión. Para cada una de estas áreas se explica la función quecumplen dentro del sistema y se describen algunas de las técnicas utilizadas actualmente para suimplementación. La lectura de este documento sirve como introducción al tópico de transmisión devideo sobre internet y es una buena fuente de referencias, en particular para el tema de calidad deservicio, el cuál es uno de los objetivos de esta memoria.

Para el desarrollo del tema se ha tomado como punto de partida el trabajo realizado previamenteen las memorias de Fermín Uribe, Alvise Bolsi y Cristian Junge, descritas a continuación:

8

Codificación y decodificación de video tolerante a fallas [11] En éste se realiza un estudio delos técnicas de codificación de video vigentes en la actualidad y su tolerancia a fallas. El resultadomás importante obtenido durante este trabajo es el desarrollo de un codec para la transmisión devideo en tiempo real. Para el desarrollo de éste se utilizó una técnica denominada detección demovimiento, descrita en el documento, la cual consiste en transmitir sólo los bloques de la imagenque cambian, incorporando un límite temporal sobre los bloques para evitar que un bloque norecibido por el cliente nunca se refresque. También se analiza la importancia del espaciamientotemporal de los paquetes para evitar ráfagas de estos que no podrán ser procesadas.

Optimización de codec de video tolerante a fallas utilizando compresión espacial [1] En éstese realiza un estudio de técnicas de compresión de video con el objetivo de disminuir el uso deancho de banda del codec desarrollado por Fermín Uribe [11]. El resultado más importante de estetrabajo es la disminución del ancho de banda en un orden de magnitud (de 2700 Kb/s a 210 Kb/sen movimiento normal) para la transmisión de video. Esto se logró aplicando compresión JPEGa los bloques de video y descomprimiéndolos en el lado del cliente. Además, se logró mejorarla eficiencia del codec utilizando el espacio de colores YUV en vez de RGB para las imágenescapturadas, lo cual evita el costo producido por las múltiples transformaciones de espacio de colornecesarias para la detección de movimiento en RGB.

Transmisión Eficiente y Tolerante a Fallas de Video sobre Redes IP [4] En éste se detalla laexperimentación realizada sobre la distribución de los pixeles en los paquetes IP en el codec devideo. Uno de los resultados más importantes obtenidos en este último punto es que la distribuciónde pixeles de manera aleatoria minimiza el daño producido por la pérdida de paquetes, ya que seevita que se vean tramas de pérdidas en la imagen del receptor, sin embargo presenta un problemacon algunos algoritmos de compresión de imágenes, lo que hace que la integración con [1] no seaposible.

3.2. Métricas de calidad

Entre los objetivos de la investigación a realizar se encuentra el de aplicar métricas de calidadde servicio a aplicaciones de video IP. Dentro de este tema existen diversas perspectivas respectoa cómo se deben realizar las mediciones, ya que la calidad del video depende principalmente dela percepción del usuario final, pero ésta se ve afectada por otros factores. La discusión entonces

9

está en el enfoque, mientras que algunas métricas se preocupan de medir la calidad perceptual de laimagen, otras se enfocan en los factores que ocasionan la disminución de ésta. En [6] se puede en-contrar un ejemplo de este último. En este documento se presenta una visión general de los puntosa considerar en el diseño de una métrica de calidad. Se establece un modelo de trabajo en el cuálse relacionan los requerimientos dados por los usuarios para el servicio, con parámetros de análisisde calidad y los recursos asociados a dichos parámetros. En particular, se presenta el desarrollo deuna métrica, la cual analiza la relación entre el uso de recursos (ancho de banda, espacio en disco,carga de CPU) con la satisfacción del usuario medida a través de parámetros como jitter, delay,tasa de pérdidas y variaciones en la sincronización, dando como resultado una ecuación de calidadque involucra todos los factores mencionados anteriormente.

Otro enfoque posible es considerar que la calidad de la imagen de video depende, a fin de cuen-tas, de la percepción de fallas en ésta por el ojo humano. Algunas métricas ignoran este punto yutilizan mediciones basadas en diferencias a nivel de pixeles entre la imagen original y recibida porel cliente. Según este último enfoque, sin embargo, puede ser de mayor utilidad medir la calidadde la imagen como un todo. En [17] se describen distintos factores de calidad tomando el puntode vista del usuario considerando el modo de funcionamiento de la visión humana. Entre estosfactores se encuentran: sensibilidad al color, al brillo, a las diferencias de luz, a la naturalidad dela imagen. Algunos de éstos son analizados desde el punto de vista de la fisonomía de la visiónhumana, entregando pautas para la incorporación a un sistema de medición de calidad perceptualde video. En general existe poca investigación en este última línea debido a la gran complejidadque presenta el modelamiento de la visión humana.

En el trabajo actual se ha optado por simplificar el problema, considerando la pérdida de pa-quetes IP como factor principal en la degradación de la imagen final. En la aplicación desarrolladadurante las memorias anteriores [11, 1, 4], se pueden observar patrones de error en la imagenasociados directamente con las pérdidas de red. Este comportamiento se debe a la forma de imple-mentación de la detección de movimiento mediante división en bloques, con lo cual la pérdida depaquetes se traduce en pérdida de bloques de imagen. En [18] se describen y comparan tres métricasde calidad perceptual de video para el análisis de errores para este tipo de implementación. Estasmétricas tienen en común que no requieren de la imagen original para realizar las mediciones. Unade las técnicas citadas es descrita en mayor profundidad en [14]. Para realizar la medición, estamétrica modela los patrones de pérdidas por bloques como una interferencia en la transmisión yluego mide la intensidad de dicha interferencia. Esta medición se realiza en los ejes X e Y de laimagen, para luego obtener un promedio entre ambas. Durante el trabajo realizado se estudió, entreotras cosas, la integración de esta última al codec de transmisión de video.

10

3.3. Transmisión tolerante a fallas

Otro objetivo del estudio realizado es analizar la posibilidad de aplicar corrección de errores enel video recibido por el cliente. En este ámbito existen diversas técnicas desarrolladas, una de lascuales es la de incorporación de redundancia en los datos enviados. En [8] se describe la aplica-ción de un protocolo que utiliza Forward Error Correction (FEC) denominado AFEC (AdaptativeForward Error Correction), en la transmisión de video para disminuir el nivel de error en el videorecibido por el cliente. En éste se muestran también los resultados de la aplicación de este pro-tocolo como capa de transporte para video de compresión MPEG. En [7] se describe en mayorprofundidad el funcionamiento del protocolo AFEC, que se adapta al nivel de congestión de la red,incrementando el nivel de redundancia de datos si se detecta que el comportamiento de la red esinestable. En aplicaciones de video en tiempo real, la retransmisión de datos no es una posibili-dad. Se hace necesario entonces incorporar redundancia en los paquetes transferidos para permitirla corrección de errores en la imagen. Sin embargo, se debe tener un buen control en el nivel deredundancia para evitar generar tráfico excesivo en la red.

Una variante a las técnicas descritas previamente involucra aplicar distintos niveles de redun-dancia para información de distinta prioridad dentro de la transmisión. En [5] se realiza primerouna descripción en profundidad del protocolo FEC y propone AdFEC Adaptable Forward ErrorCorrection. Esta modificación aplica FEC con baja redundancia a información que no es crítica pa-ra el video, pero cuya pérdida ocasiona molestias en el lado receptor (por ejemplo datos de pixelesde imagen) y utiliza alta redundancia a información crítica para el funcionamiento de la aplicación,tal como segmentos de control, información de formatos y tablas de colores. La revisión de estedocumento permite entender la base matemática del protocolo FEC, transformándola en una fuenteimportante de información para su posible aplicación en el trabajo a realizar.

Otra opción para corrección de errores es la de reconstruir bloques o pixeles perdidos durante latransmisión a través de técnicas de interpolación espacial o temporal. En la interpolación espacial,la información de un pixel perdido se reconstruye a partir de la información de sus pixeles vecinosmás cercanos. De manera similar, la información de un bloque puede ser reconstruida a partir de lainformación obtenida de los bordes de los bloques más cercanos a éste. En interpolación temporal,se reconstruye la información de bloque utilizando la información del bloque anterior equivalentemás cercano. En [9, 13] se describen algunos métodos de interpolación temporal y espacial paradisimulación de errores (Error Concealment). Durante el trabajo realizado se estudió la integraciónde técnicas de interpolación espacial al codec de transmisión de video.

11

3.4. Resumen

Diversas técnicas y protocolos han sido desarrollados para cubrir los temas de medición decalidad de video y corrección de errores, algunas de las cuales han sido descritos en la actualrevisión. En general, se aprecia un amplio nivel de interés y de profundización en estas áreas,pero a pesar de la clara relación entre ambas, existe poco trabajo en que se vea una asociacióndirecta. Sería deseable, por ejemplo, utilizar una métrica de calidad para medir qué tan bueno esel algoritmo de corrección de errores, utilizándola para analizar los parámetros bajo los cuales seobtienen mejores resultados. Este es precisamente el enfoque de trabajo que se utilizará durante lamemoria.

12

Capítulo 4

Desarrollo

En el capítulo anterior se revisaron conceptos relacionados con el ámbito de trabajo y el estadodel arte actual. El presente capítulo describe el trabajo realizado durante el transcurso de la presentememoria.

En primer lugar se describe la plataforma utilizada para el desarrollo. A continuación se des-cribe el funcionamiento del sistema en términos generales y los pasos efectuados para lograr unafamiliarización con el modo de funcionamiento de éste, así como las optimizaciones iniciales rea-lizadas al programa. Finalmente se explican los cambios y desarrollos incorporados concernientesal ámbito de la memoria actual.

4.1. Configuración

La plataforma de hardware utilizada para el desarrollo consistió en un computador con un pro-cesador AMD Sempron 2600+ con un Gbyte de memoria RAM. Para la captura de video se usóuna cámara analógica Sony, modelo Handycam Video8 CCD-TR380. Para la digitalización de lasimágenes obtenidas se empleó una tarjeta capturadora de video Prolink PixelView PlayTV. Estatarjeta fue escogida por utilizar el chipset BT878, el cual es soportado por linux mediante la API

13

de Video4Linux (V4L) [12].

El sistema operativo seleccionado fue la distribución de Linux Fedora Core 5. Este sistemaposee una avanzada capacidad de reconocimiento de hardware y además incluye las bibliotecas dela API de V4L, lo cual facilitó el proceso de configuración del software para su utilización.

El lenguaje de programación utilizado para el desarrollo es C, principalmente por motivos deeficiencia, pero también por ser el lenguaje de implementación original del programa. Como sepodrá ver mas adelante, también fue posible desarrollar una aplicación cliente en lenguaje Java,obteniendo una eficiencia satisfactoria, lográndose despliegue de video recibido a 30 cuadros porsegundo, similarmente a lo obtenido por la aplicación en C.

4.2. Descripción del codec

Previamente a la descripción del trabajo realizado, es necesario detallar brevemente el modo defuncionamiento de la aplicación, previamente a lo agregado durante el transcurso de la memoriaactual.

El codec posee dos partes. Un servidor que captura el video, lo procesa y transmite a travésde la red, y un cliente que recibe el flujo de datos y lo procesa para poder desplegarlo en el ladoreceptor.

4.2.1. Servidor de Video

La aplicación realiza cuatro etapas para la transmisión de los datos, tal como se muestra en lafigura 4.1(a). Éstas son, captura de datos de video (desde una archivo o una cámara), detecciónde bloques de movimiento en la imagen, distribución de información en paquetes IP y envío depaquetes.

14

(a) Servidor (b) Cliente

Figura 4.1: Diagrama de flujo de cliente y servidor

Capturar cuadros de video

Se lleva a memoria un cuadro de imagen obtenido desde alguna fuente, la cual puede ser algúndispositivo conectado al PC, tal como una cámara web o una tarjeta capturadora de video, obte-niendo datos mediante la interfaz de Video for Linux, o un archivo guardado en memoria. Cadacuadro de imagen es guardado como un arreglo de bytes, utilizando 4 bytes para describir cadapixel, utilizando el modelo de color RGB32 [15].

Detectar bloques con movimiento

Cada cuadro capturado se compara con el inmediatamente anterior para detectar si ha habidomovimiento dentro de la imagen. Para realizar esto, se considera la imagen como un conjunto debloques cuadrados de 8x8 pixeles, denominados macro-bloques, cada uno de éstos es comparadocon su equivalente en el cuadro anterior utilizando la varianza de las componentes del color enel sistema RGB como indicador, considerando los 64 pixeles, las diferencias entre dos cuadrosconsecutivos se calculan de la siguiente forma, para el cuadro i.

15

64!

j=1

(Ri,j !Ri−1,j)2 + (Gi,j !Gi−1,j)

2 + (Bi,j !Bi−1,j)2 (4.1)

Si dicho valor supera un cierto umbral, determinado experimentalmente [11], entonces se con-sidera que el macro-bloque ha cambiado y este debe ser marcado para envío. Además, de maneraperiódica, los bloques deben ser marcados para envío incluso si no se han registrado cambios. Estoes necesario, ya que podría ocurrir que un bloque no recibido nunca volviera a cambiar en el servi-dor, lo cual ocasionaría un error persistente en el cliente. Como no existe una retroalimentación delos bloques recibidos efectivamente, la utilización de esta estrategia es indispensable.

El fin de esta etapa es disminuir la cantidad de datos necesarios a enviar por cada cuadro devideo al cliente. Esto es logrado transmitiendo solo la información de imagen que cambia en eltiempo, de manera que el receptor perciba el movimiento ocurrido. Este proceso es comúnmenteusado por aplicaciones de distribución de video en Internet y se denomina compresión temporal.

Distribuir información en paquetes IP

Los bloques marcados para envío son ordenados aleatoriamente y agrupados en una macro-unidad denominada bloque virtual. El máximo tamaño de una de estas unidades es de 255 macro-bloques, con lo cual puede contener no más de 64 " 255 = 16320 pixeles. De acuerdo al tamañodel bloque virtual, se define una distribución aleatoria de pixeles. Éstos son divididos en cuatropaquetes IP, de manera que el primer pixel de la secuencia aleatoria se agrega al primer paquete, elsegundo al segundo paquete y así sucesivamente hasta recorrer la secuencia completa. Dado que seutiliza la misma función de aleatorización tanto en el cliente como en el servidor, entonces no esnecesario enviar el orden de los pixeles al cliente.

Utilizando esta estrategia de distribución, se logra disminuir el impacto ocasionado en la imagenpor causa de pérdidas de paquetes. El resultado producido por éstas es la pérdida de sólo algunospixeles del bloque, con lo cual el contenido de la imagen recibida aún es identificable por el usuario.En la figura 4.2 [4], se puede ver la imagen recibida aplicando este método bajo condiciones depérdidas, se observa una degradación de la calidad, pero el contenido aún es distinguible.

16

Figura 4.2: Imagen recibida utilizando distribución aleatoria de pixeles

Enviar paquetes

Una vez llenados los paquetes, éstos son enviados al cliente mediante el protocolo de transmi-sión UDP.

4.2.2. Cliente de Video

La aplicación realiza tres etapas para poder mostrar el video recibido, tal como se muestra enla figura 4.1(b). Recibir paquetes IP, obtener información de imagen de éstos y desplegar imagenactualizada.

Recibir paquetes

Los paquetes IP son recuperados desde la red, utilizando protocolo de transmisión UDP. Elcliente escucha constantemente en un puerto y procesa los paquetes en la medida que los recibe.

17

Reconstruir imagen

Cada vez que se recibe un paquete, se procesa para obtener la información de imagen de éste.El proceso es posible gracias a los headers incluidos en el paquete, éstos contienen informaciónrespecto al cuadro al que pertenecen los datos, tamaño, bloques contenidos en la sección de datos,etc. La misma secuencia aleatoria de pixeles del servidor es generada también en esta etapa, de ma-nera que al recibir un paquete de la secuencia de cuatro detallada en la sección anterior, es posibleobtener la información de color y posición exacta de los pixeles recibidos. Una vez recuperadoslos pixeles, son actualizados en una imagen almacenada en memoria para su posterior despliegue.De la misma forma, también es posible saber qué paquetes se perdieron y los pixeles contenidos enellos. Este conocimiento es crucial para los objetivos de la memoria actual, ya que los algoritmosde corrección de errores se aplican en esta etapa.

Desplegar imagen

Una vez recibida la información completa de un cuadro de imagen, la versión en memoria deésta es desplegada en una ventana utilizando el entorno X11.

4.3. Optimizaciones Iniciales

La primera etapa del trabajo realizado fue de familiarización con la implementación realizadaanteriormente. Para ello se partió de la aplicación desarrollada por Fermín Uribe [11], realizandoalgunas optimizaciones y re-estructuración del código para mejorar la mantenibilidad de la apli-cación. En base al nuevo esquema se procedió a incorporar las mejoras introducidas por CristianJunge en su trabajo de memoria [4], para hacer uso de esos avances como punto de partida del tra-bajo actual. En la actual sección se describirá en detalle cada una de las modificaciones realizadas.

18

4.3.1. Incorporación de herramientas autoconf y automake

Autoconf y Automake son herramientas de apoyo al desarrollo de aplicaciones en entornos *nix.Éstas permiten la generación automática de archivos de configuración y compilación de código. Talesquema posee numerosas ventajas:

Detección de dependencias de la aplicación en la plataforma destino y adaptación de la mismaa la configuración existente.

Generación de archivos Makefile para compilación simple mediante el comando make.

Gestión y documentación de cambios realizados al código.

Control de versiones.

Generación de ejecutables (y/o bibliotecas) e instalación de los mismos en directorios comu-nes de distribuciones *nix.

Creación de paquetes comprimidos fácilmente distribuibles a través de Internet para su ins-talación en otras máquinas.

Utilización de licencias de software.

Para hacer uso de estas herramientas fue necesario crear los siguientes archivos:

configure.in: Este archivo define entre otras cosas: versión de la distribución, programa decompilación, dependencias de la aplicación (headers C, funciones requeridas) y mensajes dealerta. Es utilizado por la aplicación autoconf para generar el fichero ejecutable de configu-ración.

Makefile.am: Debe ser definido en cada carpeta para especificar las subcarpetas necesariasde acceder y los ejecutables o bibliotecas a crear. Junto con cada ejecutable se debe detallarcada uno de los archivos necesarios para la compilación exitosa.

COPYING: Cuando se utiliza algún tipo de licencia en la aplicación, se debe agregar estearchivo para definir los términos de la misma.

ChangeLog: Define cambios realizados por cada versión de la aplicación.

19

AUTHORS, README, INSTALL: Información útil para el usuario, contacto de los desarro-lladores, instrucciones de instalación y otras que puedan ser necesarias.

Una vez incorporados los archivos señalados, se pueden generar los archivos necesarios para laconfiguración y compilación, utilizando el siguiente comando.

> autoheader & autoconf & automake

Cuando se ha generado una distribución estable, un usuario cualquiera puede configurar y com-pilar el programa realizando la siguiente secuencia de pasos.

> tar xvfx <programa>-<version>.tar.gz> cd <programa>-<version>> ./configure> make

4.3.2. Reestructuración de código

El primer paso realizado fue estudiar el código de la aplicación para comprender a cabalidadel funcionamiento de la misma. Dado que, para el trabajo realizado por Cristian Junge, numerosasversiones habían sido desarrolladas, la mantenibilidad del código había sido perdida en parte, porlo cual se optó por reestructurar el mismo. Del análisis realizado pudo detectarse las siguientessub-funcionalidades en la aplicación.

Captura de video: Consiste en el proceso de llevar a memoria un cuadro de imagen obtenidodesde una fuente de video particular. Dicha fuente puede ser obtenida desde un dispositivode captura (tarjeta capturadora, cámara web), como desde un archivo en disco. El cuadrocapturado se representa en memoria de acuerdo al modelo de color escogido. En el casoactual se utilizo el modelo RGB32 [15], por lo que la imagen se representa como un arreglode bytes, donde se utilizan 4 bytes por pixel (indicando transparencia, rojo, verde y azul).

20

Detección de movimiento Esta funcionalidad toma la información de la imagen almacena-da en memoria y determina si ha hubo algún cambio con respecto al cuadro anterior. Paralograr esto, la imagen completa se divide en cuadrados de 8x8 pixeles o macro-bloques. Lainformación de color de cada uno de éstos, es comparada con la información del bloque res-pectivo del cuadro inmediatamente anterior. Si se detectan diferencias que superan un umbraldeterminado, entonces significa que dicho bloque debe ser actualizado (o transmitido). Estafuncionalidad permite realizar compresión temporal sobre los datos de video, es decir, sólolos cambios en la imagen son transmitidos, disminuyendo el ancho de banda requerido porla aplicación.

Distribución de información en paquetes: La información de la imagen debe ser luegoprocesada para ser enviada al cliente, esta funcionalidad se encarga de distribuir los datos enpaquetes para su transmisión. La información puede ser distribuida de distintas formas paradisminuir el impacto producido por las pérdidas. En el caso del trabajo de Fermín Uribe, losmacro-bloques son distribuidos en forma de grilla, para evitar que segmentos completos deimagen puedan perderse.

Envío de paquetes: El último paso de transmisión consiste en enviar cada paquete al receptorutilizando un socket UDP, este proceso es bastante simple, y equivale a escribir datos en unarchivo.

Recepción de paquetes: Esta funcionalidad permite a la aplicación cliente recibir la infor-mación enviada por el servidor, para su posterior procesamiento.

Recuperación de información en paquetes: La información de la imagen contenida en lospaquetes es recuperada y actualizada en memoria para su posterior despliegue.

Despliegue de imágenes: Consiste en mostrar en pantalla la imagen tanto transmitida comorecibida. Es equivalente a dibujar cada uno de los pixeles almacenados en memoria en un áreaespecífica de la pantalla. Debe considerarse, sin embargo, como una funcionalidad aislada delresto.

Utilidades Varias: Dentro de la aplicación se pudo encontrar también otras funcionalidadespara realizar diversas tareas, como transformaciones de espacio de color y generación dearreglos aleatorios, entre otras. Estas pueden ser consideradas aisladas del resto, de manerade permitir su utilización en distintas partes de la aplicación.

En base a las funcionales encontradas, se definió un modelo de capas para el lado servidor dela aplicación, que es el que más tareas debe realizar. Dicho modelo puede verse en la figura 4.3(a).Por la simplicidad de la capa de envío y por eficiencia de implementación se optó por integrarla ala capa de procesamiento de información.

21

(a) Servidor (b) Cliente

Figura 4.3: Estructura de capas de la aplicación. Interacción entre las distintas etapas de transmisióny recepción de video.

Un modelo de capas similar fue definido para el lado cliente de la aplicación (figura 4.3(b)).Por la simplicidad de la capa de recepción y su relación directa con la etapa de procesamiento depaquetes (recuperación de información), se optó por unir ambas.

La reestructuración realizada consistió en separar cada una de esas capas en un módulo inde-pendiente del resto, de esta manera fue posible reutilizar funcionalidades en nuevas aplicaciones,además de permitir modificar el modo de funcionamiento de una capa sin afectar al resto, posibi-litando que la entrada y salida de cada una se mantenga. Ambas mejoras mostraron ser útiles enetapas posteriores del trabajo. En la figura indicada anteriormente, se puede apreciar en detalle laseparación de módulos y los archivos asociados a cada uno.

Una vez finalizada la reestructuración, se procedió a incorporar las mejoras introducidas porCristian Junge a la aplicación. Para esto fue necesario modificar la capa de Procesamiento, ya quedichas mejoras estaban relacionadas principalmente con la distribución de la información de videoen los paquetes. Dadas las modificaciones realizadas anteriormente, sólo hubo necesidad de alterar

22

un archivo para poder apreciar los resultados en la aplicación.

Con la culminación de esta primera etapa, se logró el objetivo inicial de la misma: comprender acabalidad el modo de funcionamiento de la aplicación, y la interoperabilidad de las distintas partesde su código. Esto permitió dar inicio el trabajo en los aspectos concernientes a la memoria actual.

4.4. Desarrollo de métricas de calidad

En la sección anterior se presentaron las optimizaciones y modificaciones realizadas a la aplica-ción como preludio al inicio del trabajo en los objetivos particulares de la memoria. En la presentesección se detalla el esfuerzo realizado para lograr dichos objetivos.

La primera etapa del trabajo consistió en incorporar mediciones a la funcionalidad de la apli-cación. Los esfuerzos se concentraron en recolectar información de dos tipos diferentes: valores dered, como ancho de banda del servidor y cliente y tasa de pérdidas de paquetes; y valores de cali-dad perceptual de video. Para esto último se desarrolló una métrica que permitiera medir el nivelde degradación del video obtenido en el lado cliente, tomando en cuenta las diferencias de coloresentre pixeles vecinos.

4.4.1. Métricas de parámetros de red

La recolección de estadísticas se desarrolló en base a un módulo especial de recopilación dedatos, cuyo propósito es almacenar información de apoyo a la experimentación, es decir, obtenercifras y estimadores que permitan evaluar de manera objetiva el desempeño y mejoras alcanzadaspor la aplicación en la medida que se observan avances. El tipo de información recopilada difierede acuerdo a si se está transmitiendo o recibiendo video. El cuadro 4.1 detalla cada uno de los datosconsiderados.

Distintos tipos de datos son obtenidos en distintas etapas del procesamiento. Por ejemplo, eltiempo de recepción de un cuadro sólo puede ser actualizado una vez que se haya recibido toda

23

Dato Transmisión Recepción DetalleFrame Sí Sí Último cuadro transmitido o recibidoTime Sí Sí Tiempo transcurrido para la transmisión o re-

cepción del último cuadroBytes Sí Sí Cantidad de bytes transmitidos o recibidosPackets Sí Sí Cantidad de paquetes transmitidos o recibi-

dosPacket Loss No Sí Cantidad de paquetes perdidos.Virtual Block Loss No Sí Cantidad de bloques virtuales perdidos.Frame Loss No Sí Cantidad de cuadros perdidos.

Cuadro 4.1: Detalle recolección estadísticas

la información de este último, pero la cantidad total de paquetes o bytes recibidos puede ser ac-tualizada inmediatamente tras enviar o recibir un nuevo paquete. Debido a ésto, se desarrolló unaserie de funciones para actualizar la información de la aplicación, las cuales pueden ser invocadasen cualquier parte del procesamiento. El cuadro 4.2 enumera cada una de estos procedimientos ydetalla su modo de funcionamiento.

La información capturada por cuadro puede ser almacenada en disco para su posterior análisis.Cabe mencionar que existe otra forma de determinar la pérdida de paquetes en la aplicación deforma posterior a cada experimento. Combinando la información de número de paquetes enviadoscon el número de paquetes recibidos, es posible determinar con exactitud la pérdida ocurrida.

La adición del módulo de estadísticas permitirá en experimentos posteriores, mostrar cifrasrepresentativas del avance (o retroceso) obtenido al probar distintas técnicas de transmisión.

4.4.2. Métricas de calidad perceptual de video

La calidad del video depende, a fin de cuentas, de la percepción del usuario que se encuentra enel lado receptor del mismo. Bajo este concepto, no es posible medir de forma objetiva la mejora odeterioro producido por cambios realizados a la aplicación durante el proceso de experimentación.El enfoque de esta etapa del trabajo en la memoria actual fue precisamente lograr ese fin, desarrollaruna métrica de calidad de video que permita comparar resultados de transmisión.

24

Función Descripciónstats_update_bytes Actualiza la cantidad de bytes recibidos de acuerdo a la informa-

ción contenida en el header length del paquete. Dicho valor conside-ra tanto el tamaño del header como el de los datos contenidos en elpaquete.

stats_update_packets Actualiza la cantidad de paquetes recibidos. Es equivalente a incre-mentar un contador cada vez que se recibe un nuevo paquete.

stats_update_packet_loss Actualiza la cantidad de paquetes perdidos. Esta información se ob-tiene utilizando la secuencia del paquete contenida en el header delmismo. Si la diferencia entre el paquete actual y el recibido ante-riormente es mayor que 1 entonces se determina que se perdieronpaquetes y se realiza esta invocación.

stats_update_v_blk_loss Actualiza la cantidad de bloques virtuales perdidos. Dentro de losdatos de cada paquete se incluye información respecto a la secuenciaen el cuadro del bloque virtual que se está recibiendo actualmente.De la misma forma que la función anterior, si la diferencia entredos paquetes consecutivos es mayor que 1, entonces se considera elbloque virtual como perdido y se realiza este llamado.

stats_update_frame Realiza varios procedimientos: calcula el tiempo de procesamientodel cuadro completo, determina si hubo pérdida de cuadros desde laúltima actualización y decide qué hacer con los datos recolectadosdesde ésta, ya sea desplegarlos en pantalla o almacenarlos en un ar-chivo CSV. Por último, vuelve los valores a cero para la siguienterecolección.

Cuadro 4.2: Detalle procedimientos de recopilación de datos

Existen trabajos desarrollados en términos de métricas de calidad. Particularmente interesantees el descrito en el documento Blind Measurement of Blocking Artifacts in Images [14]. Este pro-pone un algoritmo de medición de blockiness (defecto producido en la imagen por aproximacionesrealizadas durante la compresión). Este algoritmo sólo requiere del flujo recibido de video paraoperar y simula el deterioro del video como la interferencia de una señal en la recepción (blockysignal). Utilizando FFT (Fast Fourier Transform) mide la intensidad de esa señal entregando unvalor de calidad de video.

Durante esta etapa del trabajo, se realizó un estudio sobre transformada de Fourier para analizarsu posible aplicación a una métrica. Se investigó acerca de la aplicación de transformada discreta deFourier y tranformada discreta de coseno al procesamiento y compresión de imágenes [2]. Debidoa que las técnicas de compresión y distribución de contenido incorporadas al codec desarrollado,son distintas de las utilizadas para otras aplicaciones del mismo tipo, se determinó que no eraposible aplicar tales herramientas al desarrollo actual en un corto plazo y sin salirse del alcance

25

Figura 4.4: Ejemplo de errores producidos por pérdidas

de un trabajo de memoria. Por esta razón se decidió estudiar otras alternativas que se detallarán acontinuación.

Detección de errores en la imagen

Con el algoritmo de transmisión utilizado, las pérdidas generadas en la imagen son claramen-te identificables como un haz de pixeles, los cuales presentan un color distinto al del fondo dela imagen. En la figura 4.4, se puede apreciar que un movimiento brusco del sujeto deja comoconsecuencia un halo de pixeles del color del objeto en movimiento (las manos en este caso).

Utilizando este conocimiento, es posible desarrollar un algoritmo de escaneo de la imagen, quedetecte los pixeles que presentan alguna diferencia con sus vecinos superior a algún umbral. Esdecir, para detectar errores se puede partir de la hipótesis, de que la distribución de valores entrepixeles vecinos en una imagen es relativamente uniforme. Este enfoque fue el utilizado para eldesarrollo de una métrica de calidad.

26

(a) Imagen (b) Grafico

Figura 4.5: Ejemplo de gráfico de errores en la aplicación

Graficación de errores

Con el propósito de determinar el modo de funcionamiento de una técnica de detección deerrores, fue necesario incorporar al cliente de video un módulo que permitiera graficar cada uno delos errores detectados. Para lograr esto se utilizó la biblioteca libplot que forma parte del proyectoGNU plotutils [3].

Con el algoritmo desarrollado, es necesario recorrer todos los pixeles de la imagen para detectarcuáles son los erróneos. En una ventana externa a la de video, utilizando libplot, se pinta cada unode estos errores detectados de un color diferente al del fondo, de esta manera, si la detección essatisfactoria, el patrón producido por el error en la ventana de video, debe ser similar o idéntico alproducido en la ventana de errores. En la figura 4.5, se observa la detección de errores con una delas técnicas probadas y su correspondiente gráfico. El valor numérico en el gráfico corresponde alporcentaje de error entregado por la métrica para el cuadro desplegado.

Como el esquema utilizado se basa en comparación de pixeles con vecinos, es posible quepuedan ocurrir algunos falsos positivos. Si se tiene un objeto que presenta mucho contraste conel fondo, como un cuadrado negro sobre un fondo blanco, al comparar colores en los bordes delcuadrado, estos serían detectados como pixeles erróneos por un algoritmo muy simplista. Uno delos factores considerados al probar distintas técnicas fue la cantidad de falsos positivos generadospor cada una, de manera que al menos éstos puedan ser despreciados. Asimismo, se considerarontambién los falsos negativos, o errores no detectados, dentro de la evaluación de las mismas.

27

Tres técnicas distintas fueron evaluadas para la comparación entre pixeles: Distancia promedioa vecinos, distancia a mediana de los vecinos y distancia a vecinos más cercanos. A continuaciónse explicará y detallará cada una de éstas.

Distancia promedio a los vecinos

Para esta implementación se definió el concepto de distancia de colores. El concepto es bastanteintuitivo, la distancia en colores entre dos pixeles corresponde a "la suma de los cuadrados de lasdiferencias entre sus respectivas componentes", es decir, es equivalente a:

(Y1 ! Y2)2 + (U1 ! U2)

2 + (V1 ! V2)2 (4.2)

Y, U, V corresponden a los valores de componentes de color del pixel en el espacio YUV. Paracalcular la distancia entre pixeles, primero es necesario convertir dichas componentes desde RGB.En el sistema YUV se separa color (U, V) de la luminancia Y. El ojo humano es mucho mas sensiblea las variaciones de luz que de color. La razón por la cual se escogió YUV en vez de RGB, fue paraevitar que el resultado de la métrica se viese alterado por variaciones poco sensibles al ojo humano(U,V).

En la técnica de distancia promedio, para cada pixel de la imagen se calcula la distancia decolor con cada uno de sus vecinos, si el promedio de estas distancias supera un cierto valor umbral(11000), entonces se considera el pixel como erróneo. Dicho umbral fue escogido como el quegenerara menor cantidad de falsos positivos, determinados a partir de la observación del gráfico.En la figura 4.6 se observa el resultado obtenido por este método. El mayor problema detectadofue que, si la diferencia en intensidad entre los pixeles erróneos y la imagen no es suficientementegrande, se producen falsos negativos, es decir, pixeles no reconocidos como erróneos.

28

(a) Imagen (b) Gráfico

Figura 4.6: Distancia promedio a los vecinos

Distancia a mediana de los vecinos

Para esta técnica fue necesario definir el concepto de módulo de color. De manera similar a ladistancia de colores, este consiste en la "suma de los cuadrados de los componentes de color", esdecir, equivale a:

R2 + G2 + B2 (4.3)

R, G, B corresponden a los valores de los componentes de color del pixel en el espacio RGB.El nombre módulo de color tiene relación con que si se interpreta el color del pixel como un vectorde 3 componentes, entonces el valor retornado por esta fórmula corresponde al largo del vector(módulo) elevado al cuadrado.

En la técnica de distancia a mediana, para cada pixel de la imagen se obtienen los vecinos yse calcula el módulo de color de cada uno de éstos. Utilizando estos valores se obtiene la medianadel conjunto, es decir se extrae el valor en el punto medio de grupo, ordenando numéricamente lospixeles. Si la diferencia de la mediana con el módulo del pixel evaluado es mayor que un ciertoumbral (55000), entonces se considera como un error. En la figura 4.7 se pueden observar losresultados obtenidos por este método.

29


Figura 4.7: Distancia a mediana de los vecinos

El mayor defecto de esta técnica, es que, a pesar de detectar de mejor manera los errores que elmétodo anterior, de acuerdo a la observación de los gráficos, presenta demasiados falsos positivospara ser ignorado, incluso modificando el valor umbral. Haciendo un análisis más profundo delfuncionamiento de este algoritmo, se llega a la conclusión que el módulo no es un buen factorde comparación. Esto se debe a que, particularmente en RGB, muchas combinaciones retornan elmismo valor. Por ejemplo, si se calcula el módulo para los valores extremos de este modelo, rojo,verde y azul, se obtiene:

|R|2 = 2552 + 02 + 02 = 65025 (4.4)|G|2 = 02 + 2552 + 02 = 65025 (4.5)|B|2 = 02 + 02 + 2552 = 65025 (4.6)

Los valores resultado son idénticos, lo que implica además la alta probabilidad de falsos nega-tivos, es decir, considerar que colores totalmente diferentes tienen una diferencia nula, de acuerdoa este método.

30

(a) Posible pixel erróneo (b) Posible falso positivo

Figura 4.8: Casos posibles de evaluación

Distancia a vecinos más cercanos

Esta técnica corresponde a la más simple de las evaluadas, funciona calculando las distanciasdel pixel evaluado con sus vecinos inmediatamente superior e izquierdo, respectivamente. Cadadistancia es comparada independientemente con un valor umbral, si ambas superan dicho umbral ala vez, entonces se considera que el pixel es erróneo.

Este método es equivalente a evaluar diferencias en cada fila y cada columna de pixeles de laimagen, en caso de encontrar una desviación muy grande de la curva obtenida, tal como se muestraen la figura 4.8(a), es razonable considerar al pixel como posibilidad de error. Para obtener un gradode certeza en la evaluación es necesario entonces, intersectar la fila y columna correspondiente aeste punto. Si se considerase sólo un eje se podrían observar casos de mucho contraste, como elmostrado en la figura 4.8(b), la cual generaría un falso positivo.

Los resultados obtenidos con este algoritmo, mostrados en la figura 4.9, son los más satisfacto-rios de las tres técnicas probadas, de acuerdo a las observaciones de los gráficos, aunque aún puedeobservarse cierta cantidad de falsos positivos, éstos pueden ser considerados despreciables.

31


Figura 4.9: Distancia a vecinos más cercanos

Definición de Métrica

De acuerdo a las pruebas realizadas, el método con mejores resultados fue el de distancia avecinos cercanos. El nivel de degradación de la imagen es calculado entonces como la razón entrela cantidad de pixeles erróneos detectados, a la cantidad de pixeles totales de la imagen, es decir:

Calidad = 1! Errores

Ancho " Alto(4.7)

En cada una de las imágenes de demostración de las técnicas se puede observar un valor en laesquina superior derecha, ese valor corresponde a la degradación porcentual del video calculadamediante el método correspondiente.

Con la determinación de una métrica de calidad de video, es posible entonces realizar experi-mentos y comparaciones entre las distintas versiones de la aplicación y demostrar el avance efectivoen ésta. Este criterio será el utilizado de aquí en adelante.

32

4.5. Corrección de errores

El último objetivo del trabajo de memoria actual, consiste en desarrollar un método satisfactoriopara corrección (ocultamiento) de errores. Dentro de esta etapa del trabajo, se estudiaron diversasinvestigaciones actuales con tal enfoque, en particular destaca [10] en donde se presentan algunastécnicas de interpolación de pixeles y bloques para flujos de video. De la misma manera que conmétricas de calidad, el esquema de procesamiento y transmisión utilizado en el codec actual haceque la aplicación de estas técnicas sea poco factible.

Para ocultar efectivamente los errores de la imagen recibida, se probaron varias técnicas dis-tintas, que funcionan bajo el mismo concepto. Al momento de reconstruir la imagen a partir delos paquetes recibidos, es fácil saber cuáles pixeles no fueron posibles de actualizar, por no tenerdisponible el paquete correspondiente. Cada uno de estos pixeles no actualizados, es calculado apartir del valor sus vecinos, a la manera de un filtro de imagen. Para el cálculo realizado, no esnecesario saber si los pixeles colindantes son correctos, ya que los filtros se enfocan en calcular elvalor más probable para el pixel perdido.

4.5.1. Aplicación de prueba de técnicas

Con el fin de observar con mayor facilidad el funcionamiento de cada técnica, se desarrollóuna aplicación de pruebas. Esta aplicación captura video desde la cámara o un archivo y permiteobservar una imagen en tres estados distintos:

1. Imagen Original: Es equivalente a pausar la transmisión (tomar una fotografía de la capturade video), el propósito es permitirle al usuario observar la imagen ideal a recibir.

2. Imagen con pérdidas: Simula pérdidas sobre un porcentaje de bloques y pixeles por bloqueindicado inicialmente. Los pixeles perdidos pueden ser reconocidos como puntos negros enla imagen, para permitir observar correctamente el deterioro causado.

3. Imagen corregida: Se corrigen los errores generados anteriormente en la imagen, utilizandoalguna de las técnicas indicadas al iniciar la aplicación. Los pixeles perdidos son determina-dos y recorridos tal como se hace en el programa cliente. Finalmente muestra el resultado dela corrección.

33

La aplicación fue desarrollada para poder comparar de manera visual las mejoras introducidaspor cada una de las técnicas de corrección, ya que tal comparación no era posible de realizar demanera confiable y en el nivel de detalle deseado, al mirar una imagen con movimiento.

4.5.2. Corrección de errores por promedio

Reemplaza el valor del pixel por el color promedio de los pixeles colindantes. Las componentesdel rojo, verde y azul en el espacio RGB de cada uno de los vecinos son sumadas y divididas porel total de pixeles para obtener el valor de cada componente del pixel perdido. La justificación paraeste método es que la variación de valor entre pixeles colindantes es, en general, suficientementepequeña, por lo que es posible reemplazar el valor de un pixel determinado por el del promedio desus vecinos.

En la figura 4.10 se pueden observar los resultados de aplicar el filtro a una imagen con errores.En la imagen 4.10(b) se simularon pérdidas de bloques del 50 % y 25 % de pixeles por paquete,lo que es equivalente a una pérdida de datos de un 25 %. Bajo las condiciones mencionadas, elresultado obtenido es aceptable, pero los errores nunca son ocultados completamente, incluso enpruebas con menores niveles de pérdidas, el efecto observado es similar a difuminar (blur) loserrores de la imagen.

34

(a) Original (b) Pérdidas

(c) Corregida

Figura 4.10: Resultados corrección por promedio

4.5.3. Corrección de errores por mediana de módulo

En esta técnica, el valor del pixel perdido es reemplazado por el valor del pixel cuyo módulo esla mediana de los vecinos. Los pixeles colindantes son ordenados de acuerdo a su módulo de colory las componentes R, G y B del pixel perdido son reemplazadas por las componentes R, G y B delpunto medio del conjunto. Este método puede ser justificado, a partir de la suposición de que losvalores escalares (módulos) entre pixeles vecinos son similares, por lo que sería factible reemplazarel pixel perdido por el del punto medio de los pixeles circundantes a éste.

En la figura 4.11 se pueden observar los resultados obtenidos por el filtro. El efecto obtenidono es tan bueno como con el filtro de promedio. Se puede observar que no sólo los errores persis-ten después de la corrección, sino que éstos son agrupados en áreas mas densas, siendo aún mas

35

notorios en la imagen final. En pruebas experimentales, se pudo observar que tal efecto es aún masdramático si se aumentan los porcentajes de pérdidas de pixeles. Este resultado induce a descartarla suposición inicial. Como se mencionó anteriormente, el módulo de color no es una buena medidade comparación, ya que varios distintos combinaciones de componentes retornan el mismo valor(por ejemplo rojo, verde y azul).


(c) Corregida

Figura 4.11: Resultados corrección por mediana de módulo

4.5.4. Corrección de errores por mediana de componentes

En esta técnica, cada componente del espacio RGB es calculada para el pixel perdido comola mediana de la componente respectiva de los pixeles colindantes. Este método es inspirado en elfiltro de mediana utilizado para reducción de ruido en algunas aplicaciones de edición de imágenes.En la figura 4.12 se pueden observar los resultados de aplicar esta técnica. Se puede notar que loserrores son casi totalmente corregidos, sólo quedando algunos defectos en la imagen donde había

36

mayor concentración de éstos. Bajo mayores niveles de pérdidas de pixeles se obtienen resultadosparecidos a los de mediana de módulo, sin embargo, a simple vista este método muestra mejorasconsiderables respecto a los anteriores.


(c) Corregida

Figura 4.12: Resultados corrección por mediana de componentes

4.5.5. Corrección de errores probabilística

Este método utiliza el concepto de histograma de color. Se considera una matriz de 5x5 pixelescentrada en el pixel perdido. La información de color de los 24 pixeles escogidos es agrupadaen conjuntos de acuerdo a la tabla 4.3. El conjunto con más elementos es el que tiene mayorprobabilidad de contener al pixel perdido. Las componentes de color de éste, son reemplazadosrespectivamente por la componente promedio de los pixeles en el conjunto escogido. Esta técnicaes inspirada por el filtro de reducción de ruido basado en histograma descrito en [19].

37

Rojo (R)

Azul (B)0 - 127 128 - 255

0 - 127 5 9128 - 255 8 2

Cuadro 4.3: Agrupación de pixeles

En la figura 4.13 se puede observar que la mayoría de los errores son ocultados correctamentepor este método, retornando resultados satisfactorios. El mayor problema observado se produce enlas partes de la imagen en que hay un cambio drástico de colores, como en los bordes de algunafigura. Debido al modo de funcionamiento del algoritmo, el color en esas secciones no puede serbien definido por lo que se produce una pérdida de información en éstas. El efecto se hace másdrástico cuando se aumentan las pérdidas de pixeles.


(c) Corregida

Figura 4.13: Resultados corrección probabilística

38

4.5.6. Resultados

En términos comparativos, se encontraron dos técnicas que sobresalen del resto en términosde la calidad obtenida en el video tras la corrección de errores. Éstas son corrección de erroresprobabilística y corrección de errores por mediana de componentes. Ambas técnicas logran corre-gir errores casi completamente bajo condiciones de 25 % de pérdidas. Sólo análisis más profundospodrán determinar cuál se comporta mejor utilizada en la recepción de video y bajo distintas con-diciones. En el siguiente capítulo precisamente se realizarán dichos análisis.

4.6. Resumen

Durante el desarrollo del trabajo de la memoria se hicieron diversas modificaciones al códigofuente de la aplicación con diversos propósitos. Lo primero fue agregar mantenibilidad y modu-laridad al código para una mayor facilidad de modificación. A continuación se incorporaron lasherramientas autoconf y automake para hacer más sencilla la compilación y versionamiento de laaplicación.

En lo que respecta al trabajo en los objetivos de la memoria, se incorporó metricas de calidad dered y de calidad perceptual de video a la aplicación para ser utilizadas como apoyo a la experimen-tación. En el último tipo de métrica, diferentes técnicas fueron probadas, en base a detección depixeles perdidos (ver cuadro 4.4), destacándose la de distancia a vecinos cercanos, la cual detectaerrores en la imagen comparando cada pixel con sus vecinos cercanos detectando variaciones ensus distancias.

También se incorporó un módulo de corrección de errores a la aplicación, este permite ocultarlos errores producidos por pérdidas de paquetes de hasta 25 %. Diversas técnicas fueron probadas(ver cuadro 4.5) , encontrándose dos que entregaban resultados similarmente satisfactorios: correc-ción de errores probabilística y corrección de errores por mediana de componentes. Análisis másprofundos permitirán determinar cuál de las dos funciona mejor en la mayor cantidad de condicio-nes.

39

Métrica Resultadossatisfactorios

Detalles

Distancia promedio a vecinos No Pocos falsos positivos. Falsos negativosdonde diferencia de color no es significa-tiva

Distancia a mediana de vecinos No Detección satisfactoria de errores. Canti-dad de falsos positivos muy alta para serignorada.

Distancia a vecinos más cercanos Si Mejores resultados. Detección satisfacto-ria de errores. Cantidad de falsos positi-vos despreciable.

Cuadro 4.4: Comparación de resultados entre técnicas de detección de errores

Técnica Resultadossatisfactorios

Detalles

Promedio No Errores no son ocultados completamente.Efecto difuminación de errores.

Mediana de módulo No Errores no son ocultados completamente.Efecto de agrupación de errores en áreasmas densas.

Mediana de componentes Si Corrección satisfactoria, errores elimina-dos casi completamente.

Probabilística Si Corrección satisfactoria, errores elimina-dos casi completamente. Perdida de infor-mación en zonas donde hay cambio drás-tico de color.

Cuadro 4.5: Comparación de resultados entre técnicas de corrección de errores

40

Capítulo 5

Análisis

Se realizaron diversas pruebas locales para analizar las mejoras en la calidad de la imagen,incorporadas por las técnicas de corrección de errores y para realizar una comparación efectivaentre ellas. El parámetro de análisis considerado fue el nivel calidad de video, valor obtenido apartir de la utilización de la métrica definida.

Para mantener las mismas condiciones de ejecución durante las diversas pruebas a realizar, secapturaron dos secuencias de video para ser utilizadas reiteradamente en las evaluaciones. Cada unatiene una duración aproximada de 25 segundos. La primera secuencia contiene movimiento lento,principalmente de la boca del sujeto en video conferencia, se requiere poco ancho de banda, porlo que hay poca posibilidad de pérdidas. La segunda contiene una mayor cantidad de movimientosrápidos, principalmente mucha expresión con las manos, se demanda gran cantidad de ancho debanda y de capacidad de procesamiento por lo que hay mayor posibilidad de pérdidas.

Debido a que las pruebas son locales, no se producen pérdidas de red y sólo se producen al-gunas debido a la capacidad de procesamiento del equipo. Para simular ambientes de pérdidascontrolados, la aplicación puede descartar paquetes al momento de envío con una cierta probabi-lidad, para alcanzar algún nivel establecido. La probabilidad de perder un paquete es uniforme, esdecir, se calcula sin dependencia de paquetes anteriores. Por ejemplo, si se desea obtener pérdidasde 30 %, entonces al momento de enviar un paquete particular, este es descartado con esa probabi-lidad (aproximadamente 1/3 de las veces). Una simulación más realista podría ser realizada a partirdel desarrollo de un modelo de pérdidas para el estado actual de Internet, sin embargo, tal estudio

41

se encuentra fuera del ámbito de esta memoria.

Con el fin de realizar gran cantidad de pruebas, se creó una pequeña aplicación en Perl que seencarga de ejecutar el cliente y el servidor para distintos niveles de pérdidas y almacenar los datosen una ubicación específica para su posterior análisis. La configuración utilizada fue consideradapara pérdidas entre 0 % y 35 %.

El tamaño del video de prueba es 352x240, tamaño que permite un consumo de ancho de bandarazonable (1 MByte/s) a 30 cuadros por segundo. Entre las pruebas realizadas no se tomó en cuentala cantidad de información transmitida, por no tener reelevancia para los objetivos esperados de lamemoria actual.

5.1. Métodos de corrección

Se evaluó la calidad del video utilizando la métrica definida para pérdidas entre 0 y 35 % para3 casos distintos: recepción de video sin corrección, utilizando técnica probabilística de correccióny utilizando técnica de mediana de componentes. Dicha comparación fue realizada para las dossecuencias de video mencionadas anteriormente. En las figuras 5.1 y 5.2 se puede observar losresultados del experimento realizado. Se puede notar una clara diferencia entre los porcentajes deerror detectados para las 3 evaluaciones distintas. El método mediana de componentes, resulta ser elque retorna mejores resultados, pero claramente el método probabilístico introduce grandes mejorasa la visualización de la imagen, confirmando lo esperado de acuerdo a experiencias anteriores.

El valor retornado por la métrica en general es pequeño, sin embargo, un error de 1,71 %, comoel máximo de la prueba sin corrección de errores (figura 5.2), significa que 1,71 " 352 " 240/100 =1444,6 pixeles fueron encontrados erróneos. Si se realiza el cálculo para el mismo punto utilizandocorrección por mediana, se obtiene que 0.48 % de error corresponde a 411 pixeles erróneos, esdecir se obtuvo una mejora de al menos un 60 %. El mismo valor puede obtenerse al aproximarlas curvas por una recta, tal como se muestra en la figura 5.3. La pendiente de la recta indica larazón de aparición de errores para cada nivel de pérdidas, esto implica que a menor pendiente, esmenor el efecto de las pérdidas sobre el video recibido. El cambio de la pendiente desde 0.0452 (sincorrección) a 0.0129 (corrección por mediana) indica una mejora de más de un 60 % en la calidadgeneral del video.

42

Al examinar el video recibido simulando pérdidas sobre 25 %, se puede observar una pérdida deprecisión en el funcionamiento del algoritmo de corrección. Esto ocurre porque en la medida quelas pérdidas aumentan, también aumenta el porcentaje de pixeles no actualizados sobre los macro-bloques, llegando incluso a producirse pérdidas de macro-bloques completos. Como las técnicas decorrección utilizan la información de los vecinos cercanos para realizar la interpolación, entoncesgrandes pérdidas de pixeles implican que no se pueda realizar este proceso correctamente, produ-ciéndose un efecto de atenuación de límites entre bloques, lo cual contribuye de manera negativa ala calidad final de la imagen. Bajo 25 % de pérdidas, sin embargo, los resultados obtenidos por latécnica son satisfactorios para el objetivo de la memoria actual.

43

Figura 5.1: Comparación entre técnicas de corrección para secuencia lenta

Figura 5.2: Comparación entre técnicas de corrección para secuencia rápida

44

Figura 5.3: Aproximación de curvas de error por rectas.

45

5.2. Métrica de Calidad

A partir de la información obtenida para la evaluación de calidad de video, se puede tambiénrealizar un análisis de la métrica de calidad. En los gráficos se puede observar que para 0 % depérdidas, el valor retornado por la métrica es distinto de cero, tal como era esperado de acuerdoal modo de funcionamiento de la misma. Los valores obtenidos, 0.091 % para la secuencia lentay 0.042 % para la secuencia rápida, corresponden a los falsos positivos detectados por la métricapara cada video. Como la aplicación está pensada principalmente para video conferencia, el entor-no dentro de la imagen nunca cambia completamente, por lo que se puede asumir que los falsospositivos son, en general, constantes y por lo tanto despreciables.

Para analizar el comportamiento de la métrica a lo largo de una secuencia de video, se comparóel valor retornado por ésta para cuatro niveles de pérdidas distintos: 10 %, 15 %, 20 % y 25 %, alo largo de cada una de las secuencias de video (utilizando corrección). En las figuras 5.4 y 5.6se muestran los resultados obtenidos para la secuencia rápida y lenta, respectivamente. A partir delgráfico y la observación del video, se puede notar que el comportamiento de la métrica es consisten-te con los niveles de movimiento en la imagen. En la secuencia lenta, hay una cantidad considerablede movimiento al inicio y luego sólo movimiento de los labios del sujeto. En el gráfico correspon-diente (5.6), se observa el mismo comportamiento, un alza importante en el valor de la métrica alinicio y un comportamiento relativamente uniforme a continuación. Este efecto también puede serapreciado para la secuencia rápida, las alzas mostradas en el gráfico, coinciden con segmentos devideo con mayor cantidad de movimiento. Esto es de esperar por el modo de funcionamiento dela aplicación. Las pérdidas producen un daño mayor en secuencias con cambios muy repentinos,debido a que las diferencias entre cuadros consecutivos son muy grandes. Al estabilizarse la esce-na, la calidad mejora lentamente en la medida que los macro-bloques faltantes van llegando. Estecomportamiento puede observarse al hacer un acercamiento en el gráfico para un error particular,como el ocurrido para la secuencia rápida a los 12.2 segundos, tal como se muestra en la figura 5.5.

En los gráficos mencionados anteriormente, puede observarse tambien, que tal como es espera-ble, el valor de la métrica aumenta en la medida que el nivel de pérdidas es incrementado. Dichoaumento muestra ser bastante uniforme para distintos niveles, mostrando sólo algunas variacionesque pueden ser explicadas por cambios en el uso del procesador de la máquina.

En la figura 5.7 se puede ver el comportamiento de la métrica durante el tiempo con y sincorrección, para un nivel de pérdidas de 20 %, para la secuencia rápida. Como es de esperarse,las curvas son bastante similares, presentando alzas semejantes en los mismos instantes de tiempo,pero desfasadas en los valores de error como causa de la corrección.

46

Para pérdidas superiores a 25 %, la probabilidad de perder bloques completos aumenta. Debidoal modo de funcionamiento de la métrica, esto resulta en pérdida de confiabilidad de los resultadosretornados por ésta, ya que sólo son detectados como erróneos los pixeles en los bordes de losbloques perdidos, adicionalmente a los pixeles no actualizados de manera individual. Sin embargo,para el propósito de la memoria actual, un nivel de 25 % es considerado como pérdidas masivasya que implica que uno de cada cuatro paquetes no pudo ser recibido, lo cual supera los umbralesactuales en Internet.

Con respecto al rendimiento, el procedimiento para calcular la métrica resulta ser muy de-mandante de recursos, ya que se debe analizar la imagen completa, pixel por pixel, 30 veces porsegundo. Esto presenta un aspecto negativo sobre la técnica utilizada. Durante la recepción, si sedespliega la imagen en pantalla y a la vez se analiza la misma, el tiempo que se tarda en realizarambos procedimientos resulta en un aumento de las pérdidas de paquetes, por no poder procesarlosen la medida que son recibidos. Para realizar los análisis, fue necesario omitir el despliegue de ima-gen, y trabajar sólo sobre los datos almacenados tras la ejecución. La incorporación de la métrica,en el estado actual de la capacidad de procesamiento, tiene utilidad para fines de experimentación,pero no realmente para su uso permanente.

47

Figura 5.4: Comparación entre errores a 4 niveles de pérdidas en secuencia rápida

48

Figura 5.5: Amplificación de un error detectado por la métrica a 4 niveles de pérdidas en secuenciarápida

49

Figura 5.6: Comparación entre errores a 4 niveles de pérdidas en secuencia lenta

50

Figura 5.7: Valores de métrica para secuencia rápida con y sin corrección para pérdidas de 20 %

51

5.3. Resumen

Se realizaron pruebas para determinar la calidad del video mediante la métrica utilizando nivelesde pérdidas entre 0 y 35 % para tres casos distintos: sin efectuar corrección, corrección por técnicaprobabilística y corrección por método de mediana de componentes. Las pruebas fueron realizadasutilizando dos secuencias de video, una con gran cantidad de movimiento y otra con movimientomoderado.

Los resultados obtenidos fueron los esperados de acuerdo a las hipótesis iniciales. La técnicade corrección por mediana introdujo una mejora en la calidad de aproximadamente un 60 % y latécnica probabilística de aproximadamente un 30 %. Se determinó también que ambos resultadosson confiables bajo niveles de pérdidas de 25 %, lo que resulta altamente satisfactorio para losobjetivos de la memoria.

La métrica desarrollada también mostró ser congruente con lo esperado. El valor retornadopor ésta aumenta en la medida que se detectan más pérdidas, tanto en promedio, como durante eltranscurso de una secuencia de video particular. Como lado negativo, se observó que la aplicaciónde esta medición resulta en un gran consumo de recursos, lo cual tiene el efecto contraproducentede generar pérdidas cuando se combina su uso con el despliegue de video. Sin embargo, parapropósitos experimentales, los resultados retornados por ésta mostraron ser de gran utilidad paralos análisis.

En términos generales, se puede considerar que los resultados obtenidos son congruentes demanera satisfactoria con los objetivos deseados. Es posible, de manera simple, disminuir el im-pacto producido por pérdidas de paquetes en la recepción de video. Sin agregar redundancia niinformación extra en los datos enviados.

52

Capítulo 6

Mejoras finales y trabajo relacionado

Tras la realización de los análisis de calidad, se procedió a realizar algunos cambios en laaplicación de video con el fin de mejorar otros aspectos de la misma. En particular se concentraronlos esfuerzos en disminuir de alguna forma el ancho de banda requerido para la transmisión devideo. En este aspecto, se hicieron algunas modificaciones a la detección de movimiento en elservidor, así como agregar la posibilidad de limitar la tasa de captura de cuadros de video. Ambassecciones del procesamiento tienen relación directa con el uso de ancho de banda. Una mejordetección de movimiento permite transmitir sólo la información efectivamente modificada durantela captura y tal como fue estudiado en trabajos de memoria anteriores, la tasa de captura tiene unarazón directamente proporcional con el ancho de banda utilizado [4].

Trabajo adicional fue realizado, en términos de poder estudiar el funcionamiento de la apli-cación en otras plataformas de software y de hardware. Con este fin se desarrolló una versión delcliente en el lenguaje Java para portabilidad entre plataformas. Utilizando este código, se desarrollóuna versión empleando J2ME para estudiar el funcionamiento del cliente en dispositivos portátilescomo teléfonos celulares.

53

6.1. Detección de movimiento en YUV

El modelo de colores YUV, basado en las componentes de luminosidad y crominancia delcolor visible, tiene su fundamento de manera muy cercana a la fisiología de la visión humana. Eltrabajo realizado por Alvise Bolsi [1], demostró que realizar detección de movimiento utilizandoeste modelo retornaba mejores resultados en términos de cantidad de macro-bloques transmitidos,incurriendo en una disminución del ancho de banda requerido por la aplicación. La explicación deesto es que el ojo humano es mucho más sensible a los cambios de luminosidad que de color, conlo que la detección de movimiento utilizando este sistema se hace mucho más precisa.

Con el fin de incorporar algunas de las mejoras alcanzadas en dicho trabajo, se efectuaronmodificaciones al módulo de detección de movimiento de la aplicación. Una conversión de espaciode color desde RGB fue realizada, con el fin de obtener la componente Y (luminancia) del modelo,la fórmula general para la transformación de componentes desde RGB a YUV es la siguiente.

Y = +0,299 "R + 0,587 "G + 0,114 "B (6.1)U = !0,14713 "R! 0,28886 "G + 0,436 "B (6.2)V = +0,615 "R! 0,51499 "G! 0,10001 "B (6.3)

Dicha fórmula requiere del uso de coeficientes de punto flotante para la conversión, lo cualresulta en una disminución del desempeño de la aplicación completa, por la ineficiencia en generalde los procesadores para manejar este tipo de valores. Sin embargo es posible realizar dicha con-versión sin la necesidad de utilizar valores decimales. A partir de la siguiente fórmula es posiblerealizar dicho procedimiento, haciendo uso sólo de valores enteros [16].

Y = min(abs(R " 2104 + G " 4130 + B " 802 + 4096 + 131072) >> 13, 235) (6.4)U = min(abs(R " !1214 + G " !2384 + B " 3598 + 4096 + 1048576) >> 13, 240) (6.5)V = min(abs(R " 3598 + G " !3013 + B " !585 + 4096 + 1048576) >> 13, 240) (6.6)

Para realizar detección de movimiento, sólo es necesario tener la componente Y de cada pixel.

54

Utilizando la fórmula descrita, se logró realizar la detección de movimiento sin afectar de maneranotoria el rendimiento del servidor de video. La fórmula utilizada para detectar movimiento enRGB (ecuación 4.1) se convierte entonces en:

64!

j=1

(Yi,j ! Yi−1,j)2 (6.7)

En donde i es el número del cuadro de video capturado y j es el número de pixel dentro de unmacro-bloque.

Con el cambio realizado se logró reducir el uso de ancho de banda en aproximadamente un60 %, de un promedio de 3 MBytes/segundo se disminuyó a 1MByte/segundo, con un mínimo de300 KBytes/seg para secuencias con bajo movimiento, sin alterar la calidad del resultado final.

6.2. Limitación de tasa de captura de video

La tasa de captura de cuadros de video (framerate) tiene una relación lineal con el ancho debanda requerido por la aplicación, tal como fue estudiado en el trabajo realizado por Cristián Junge.Aunque la tasa de reproducción de video más congruente con el modo de funcionamiento de lavisión humana es 30 cuadros por segundo, pueden haber casos en donde sea razonable sacrificarfluidez de video por ancho de banda.

Se realizó una modificación al servidor de video, la cual a partir de un parámetro definido enel archivo de configuración de la aplicación, permite bajar la tasa de captura de cuadros, introdu-ciendo un tiempo de espera al final del procesamiento de cada imagen. El resultado obtenido fuesatisfactorio, una reducción de la tasa de captura en un 50 %, tiene como resultado la reducción delancho de banda requerido por la aplicación en un 50 %.

Esta modificación tiene especial importancia si se desea utilizar la aplicación bajo otras redes,tales como GSM (GPRS o EDGE), donde los anchos de banda soportados son mucho menores, y lacapacidad de los procesadores en los terminales es muy baja, en cuyo caso sería factible sacrificar

55

algo de fluidez de video para mejorar la calidad general del mismo, al disminuir las pérdidas depaquetes.

6.3. Cliente Java

Para aplicaciones de transmisión multimedia, en particular para video-conferencia, portabilidadentre distintas plataformas se transforma en una ventaja importante, más aún si se desea realizar unaversión utilizable por el público general. Con el propósito de analizar el funcionamiento en otrasplataformas, se desarrolló una versión del cliente utilizando lenguaje de programación Java, el cualpermite la ejecución de la aplicación de manera casi independiente de la plataforma de hardware ysoftware utilizada. Como dicho lenguaje es de más alto nivel que C, por consiguiente incurriendoen una degradación de eficiencia, se hace interesante estudiar el comportamiento de los algoritmosde recepción de video en esta nueva versión.

El desarrollo del cliente fue relativamente directo, el algoritmo utilizado para reconstruir elvideo a partir de los paquetes recibidos, es relativamente simple de implementar utilizando Java.Sin embargo se encontraron varios desafíos con los que fue necesario lidiar durante el desarrollo.

Extracción de información desde paquetes: De acuerdo a la forma en que se arman los pa-quetes en el servidor, primero se crea una estructura de datos en C, con la información en lacabecera del paquete, incluyendo un puntero a la sección en memoria que contiene la infor-mación propiamente tal de la imagen, para luego concatenar dicha información en el cuerpodel paquete. Esto tuvo la consecuencia que, para implementar la recepción, fue necesariorealizar algunas pruebas para determinar qué partes de los datos recibidos correspondían ala cabecera y qué partes al cuerpo paquete. De dichas pruebas, se determinó que era necesa-rio ignorar algunos bytes del mensaje para poder interpretarlo de manera exacta a como fueenviado.

Aleatorización de pixeles Uno de los fundamentos de la aplicación desarrollada en C, esque el método de generación de números aleatorios es exactamente el mismo en el servidorque en el cliente, esto evita que se tenga que transmitir información respecto al orden de lospixeles dentro del paquete. Esta propiedad, sin embargo, no se cumple al cambiar el lenguajede programación. Para mantener dicho fundamento, fue necesario implementar una funciónde números pseudo-aleatorios, incorporándola tanto al servidor como al cliente. Con estamodificación se logró extraer la información de orden de los pixeles en el cliente.

56

Conversión de RGB565 a RGB32: En el servidor, para disminuir la cantidad de bytes ne-cesarios a enviar, se realiza una conversión de espacio de colores desde RGB32 a RGB565,de manera previa al envío. Esto tiene como resultado disminuir de 4 a 2 la cantidad de bytesnecesarios para describir cada pixel. Al realizar la conversión inversa en Java, se observóque los colores verde y azul aparecían intercambiados en la imagen resultante. Se determinóque esto tiene relación con una diferencia en el orden de los bytes utilizados por el lenguaje,con el orden utilizado por la arquitectura del servidor. El problema fue resuelto fácilmente alintercambiar ambas componentes de color.

Despliegue de imagen: A pesar que existe una biblioteca de Java especializada para multi-media, es una desventaja conocida que ésta no permite la reproducción de video a más de 15cuadros por segundo, lo cual entra en conflicto con lo deseado para el cliente. Además, dadoque el formato de video utilizado por la aplicación es distinto de cualquier formato conocido,entonces tampoco existe una forma de desplegar las imágenes utilizando tal biblioteca. Paralograr este propósito, se utilizaron algunas clases de bajo nivel de de Java (Canvas, Graphics)para crear una ventana y luego dibujar el contenido (el cuadro) directamente sobre ésta. Conesto se logró desplegar imágenes a la tasa deseada.

La aplicación final desarrollada mostró bastante eficiencia en el despliegue de video en tiem-po real, produciéndose sólo algunas pérdidas por capacidad de procesamiento del lenguaje, peroel resultado final es satisfactorio. En la figura 6.1 se puede ver la aplicación ejecutándose en elsistema operativo Mac OS X. De acuerdo a lo observado, es posible desarrollar una aplicaciónmulti-plataforma utilizando el lenguaje Java. Cabe mencionar que no se incorporó corrección deerrores a este cliente, sin embargo no se descarta la posibilidad de agregarlo.

57

Figura 6.1: Cliente Java ejecutándose en Mac OS X

6.4. Cliente J2ME

Como se mencionó, evaluar el funcionamiento de la aplicación en distintas plataformas planteaun punto de vista interesante sobre los límites del funcionamiento y rendimiento de la aplicacióncliente. De particular interés es probar la aplicación funcionando sobre dispositivos móviles, loscuales presentan capacidades de procesamiento y memoria más limitados que un computador deescritorio. Además presenta la posibilidad de ver el comportamiento del algoritmo de transmisiónsobre otro tipo de redes, como la red celular (GSM).

Con este fin se desarrolló una aplicación utilizando J2ME con MIDP 2.0 y CDLC 1.1. Debido almodo de funcionamiento del cliente Java, fue posible reutilizar la mayor parte de las componentesde software de éste para el desarrollo del cliente móvil. Sólo fue necesario realizar algunos cambiosen la forma de recepción y de despliegue de video. Se requirió, sin embargo, realizar algunoscambios a la configuración por omisión de la aplicación. El máximo tamaño de bloque virtualfue modificado de 255 a 32, para disminuir el tamaño de los paquetes enviados. El tamaño decaptura de video se redujo a 160x120, ya que no se necesita una resolución mayor para dispositivosmóviles. Dentro de la aplicación cliente se incorporó una pantalla para modificar los valores de laconfiguración. Además se agregó una característica para permitir escalar el video a la pantalla encaso de recibirse un tamaño menor.

Para probar el funcionamiento del cliente, se contó con dos equipos móviles Nokia, modelos

58

N73 y N91. Ambos cuentan con procesadores ARM compatible de 200 y 315 Mhz respectivamente,sistema operativo Symbian Series 60 3era edición y conectividad con redes GSM. Además el equipoN91 cuenta con conectividad via Wireless LAN. Utilizando conectividad por red inalámbrica, sepudo recibir el video en tiempo real, a 30 cuadros por segundo, sólo presentando algunos errorespor pérdidas menores. Como era de esperar, al utilizar conectividad EDGE, se produjeron grancantidad de pérdidas debido a las limitaciones de ancho de banda, mostrando que las limitacionespara ejecutar el cliente en equipos móviles, están asociadas a la velocidad de la conexión, más quea la capacidad de procesamiento.

En la figura 6.2 se puede ver la pantalla de configuración de la aplicación. En 6.3 se puedever el equipo recibiendo video desde el servidor utilizando red inalámbrica. Puede apreciarse quela transmisión es en tiempo real. En la figura 6.4 se puede ver el equipo recibiendo video desdeel servidor utilizando red EDGE, se puede observar que la transmisión presenta un retraso conrespecto a la imagen capturada en el servidor.

59

Figura 6.2: Pantalla de configuración funcionando en el equipo móvil

Figura 6.3: Recepción de video en el equipo móvil utilizando red inalámbrica

60

Figura 6.4: Recepción de video en el equipo móvil utilizando EDGE

61

Capítulo 7

Conclusiones

En este trabajo, se logró exitosamente ocultar errores producidos por pérdidas de paquetes IP,por consecuencia, aumentando la tolerancia de la aplicación a las mismas, sin aumentar la infor-mación transmitida.

Con el fin de obtener datos formales para comparación a partir de las pruebas, se incorporóun módulo de estadísticas tanto a la aplicación servidor como cliente. Dicho módulo permitiórecolectar información útil con respecto a cada cuadro desplegado, para su posterior análisis.

Como la calidad del video recibido depende, a fin de cuentas, de la percepción del usuariofinal de errores en la imagen, no era posible realizar una comparación objetiva entre versiones dela aplicación de video. Este problema fue solucionado mediante el desarrollo de una métrica decalidad perceptual de video, basada en detección de errores por comparación entre pixeles. Éstapermitió asociar un valor numérico a la degradación en la imagen recibida, con lo cual fue posibleevaluar las mejoras alcanzadas por el trabajo realizado.

Para ocultar efectivamente los errores se requirió probar distintas técnicas. Cada una de éstasfunciona mediante calcular el valor de un pixel no actualizado en base a la información de lospixeles circundantes a éste. Los métodos de corrección evaluados fueron: promedio de vecinos,mediana de módulo de vecinos, mediana de componentes de vecinos y probabilística. De acuerdoa una aplicación de pruebas realizada, las mejores resultaron ser las dos últimas.

62

Al ejecutar la aplicación bajo múltiples niveles de pérdidas y utilizando secuencias de videoconstantes, se obtuvo como resultado que la técnica de corrección por mediana de componentesproducía una mejora de calidad mayor que la corrección probabilística. Se determinó incrementode calidad de aproximadamente 60 % con respecto a no utilizar corrección de errores, para pérdidasinferiores a 25 %.

Como trabajo lateral, en términos de uso de ancho de banda, se logró reducir en 2/3 los reque-rimientos de red de la aplicación, mediante la utilización de detección de movimiento en el espaciode color YUV. Se logro una reducción desde 3 MBytes/s a 1 MByte/s promedio.

Además se logró desarrollar una versión del cliente de la aplicación en Java para su utilizaciónen diferentes plataformas. Se desarrolló también un cliente J2ME para su utilización en teléfonoscelulares. El rendimiento mostrado por ambas aplicaciones fue satisfactorio, lográndose recibirvideo a 30 cuadros por segundo, al igual que con versiones anteriores.

En definitiva se demostró que es posible corregir u ocultar errores de manera satisfactoria dentrode flujos de video, sin la necesidad de incorporar algún tipo de redundancia de datos, y sólo tomandocomo base la información ya existente en la imagen recibida.

Este sistema fue instalado y demostrado en Entel PCS, generando muchas expectativas de partede las áreas de ingeniería, y generando un proyecto de trabajo conjunto entre el DCC y Entel PCSen ésta área.

63

Capítulo 8

Trabajo Futuro

Durante los diversos trabajos en la materia de estudio actual, numerosos avances han sido logra-dos, incluyendo los mostrados durante el trabajo actual. Sin embargo, aún quedan muchas posibi-lidades de mejoramiento, las que plantean desafíos interesantes de estudiar. Entre éstas se detallaráparticularmente compresión de imagen, para disminuir el ancho de banda requerido por la aplica-ción y la retro alimentación de información desde el cliente al servidor, para adaptar el algoritmode acuerdo a las condiciones de red.

8.1. Compresión de imagen

Tal como se explicó en el trabajo de Cristian Junge, el algoritmo de aleatorización de pixelespresenta un gran avance en tolerancia a pérdidas y cuando es combinado con corrección de erroresaún más, tal como se explicó en el trabajo actual. Sin embargo, este procedimiento presenta unagran desventaja, la cuál es hacer imposible la incorporación de técnicas de compresión lossy, comoJPEG. Dichas técnicas realizan compresión aprovechando la correlación de colores entre pixeles,es decir, disminuyen la cantidad de información de la imagen mediante una simplificación de lasdiferencias entre pixeles colindantes. Al aleatorizar los puntos a transmitir, dicha correlación sepierde, con lo cual aplicar compresión resulta en una pérdida de la información de color de laimagen.

64

Otras técnicas de compresión se declaran lossless (PNG, GIF), es decir que la información decolor de la imagen puede ser recuperada completamente al descomprimir la imagen. Sin embargoéstas demandan gran cantidad de tiempo de procesamiento, con lo cual, no se hace posible obtenertasas de despliegue mayores a 20 cuadros por segundo.

La compresión PNG, en términos simples, se compone de tres etapas. La primera etapa realizauna transformación aritmética sobre los datos, para hacer la información más compresible. En lasegunda etapa, se comprimen los datos utilizando un algoritmo denominado como Ziv-Lempel. Lainformación es luego comprimida aún más utilizando el algoritmo de Huffman en la tercera fasedel procedimiento.

En el algoritmo de transmisión utilizado por la aplicación, debido a la aleatorización realizada,no existe una correlación entre los pixeles enviados en un mismo paquete, por lo que no tiene sen-tido utilizar PNG, ya que algunas etapas no efectuarán un aporte en el resultado final. Sin embargo,no se puede descartar la aplicación de alguno de los algoritmos de compresión a los datos.

Técnicas de compresión como Huffman o Codificación Aritmética, se basan en la detección deocurrencias de caracteres en el texto a comprimir, con el fin de generar un nuevo diccionario que uti-lice menor cantidad de información para codificar los caracteres más usados. Tales técnicas tienentambién sus versiones adaptativas, en donde se adapta el diccionario de la misma forma tanto paracomprimir como para descomprimir los datos, evitando de esta manera la necesidad de transmitirlo.En la aplicación, durante la distribución en paquetes, se simplifica la información color medianteuna transformación de RGB32 a RGB565. Si se considera el conjunto de información como unasecuencia de caracteres, dicha simplificación aumenta la probabilidad de repetición de éstos dentrode la cadena, haciendo factible la aplicación de una de las técnicas mencionadas anteriormente.

Un problema interesante, entonces, se plantea en adaptar alguna de las técnicas de compresiónpara su uso particular dentro de la aplicación y evaluar los niveles de compresión posibles de alcan-zar mediante su utilización y su combinación con otras técnicas como interlineado de imágenes.

65

8.2. Retro-alimentación de datos

El funcionamiento de la aplicación en la actualidad no contempla diferencias en capacidadesde red entre el servidor y el cliente. Es decir, cada una de las partes transmite o recibe a la máximacapacidad que lo permite su conexión de red. Esto es un factor importante a considerar, ya que si lavelocidad de transmisión es mucho mayor que la de recepción, entonces se producirán pérdidas enel lado cliente, por no poder recibir con suficiente rapidez los paquetes transmitidos.

El modo de implementación actual no permite al servidor obtener información alguna respectoa las capacidades de los clientes conectados, más aún, no posee ningún medio para saber que lainformación esté siendo efectivamente recibida, o de la calidad de la imagen en el cliente.

Una solución interesante, se presenta entonces en implementar un canal de comunicación deforma paralela a la transmisión de video, utilizando protocolo TCP/IP, de manera de que el servi-dor pueda obtener una retro-alimentación acerca del funcionamiento del cliente, tal como cantidadde paquetes perdidos, bytes recibidos, etc. Esto permitiría al servidor adaptar el algoritmo de trans-misión, introduciendo pausas entre el envío de paquetes, por ejemplo, para mejorar la calidad derecepción de video.

La implementación de dichas mejoras, resultaría en un incremento general del nivel del algorit-mo completo, abriendo la posibilidad para su incorporación dentro de aplicaciones de uso masivo.

66

Bibliografía

[1] Alvise Bolsi. Optimización de codec de video tolerante a fallas utilizando compresión espa-cial. Memoria de Ingeniería Civil en Computación. Universidad de Chile, 2004.

[2] Hany Farid. Fundamentals of image processing. http://www.cs.dartmouth.edu/farid/tutorials/fip.pdf.

[3] GNU. The plotutils package. http://www.gnu.org/software/plotutils/.

[4] Cristian Junge. Transmisión Eficiente y Tolerante a Fallas de Video sobre Redes IP. Memoriade Ingeniería Civil en Computación. Universidad de Chile, 2005.

[5] Bernd Lamparter, Otto Boehrer, Wolfgang Effelsberg, and Volker Turau. Adaptable forwarderror correction for multimedia data streams. Technical Report TR-93-009, 1, 1993. http://citeseer.ist.psu.edu/lamparter93adaptable.html.

[6] Nalini Venkatasubramanian and Klara Nahrstedt. An integrated metric for video QoS. InMULTIMEDIA ’97: Proceedings of the fifth ACM international conference on Multimedia,pages 371–380, New York, NY, USA, 1997. ACM Press.

[7] K. Park. Afec: an adaptive forward error-correction protocol and its analysis, 1997. K. Park.AFEC: an adaptive forward error-correction protocol and its analysis. Technical Report CSD-TR97 -038, Department of Computer Sciences, Purdue University, 1997.

[8] Kihong Park and Wei Wang. QoS-Sensitive Transport of Real-Time MPEG Video UsingAdaptive Forward Error Correction. In ICMCS, Vol. 2, pages 426–432, 1999.

[9] P. Salama, N. Shroff, E. Coyle, and E. Delp. Error concealment techniques for encodedvideo streams, 1995. P. Salama, N. B. Shroff, E. J. Coyle, and E. J. Delp, Error ConcealmentTechniques for Encoded Video Streams, in IEEE Int’l Conf. on Image Processing, vol. 1, pp.9–12, 1995.

[10] P. Salama, N. Shroff, and E. Delp. Error concealment in encoded video, 1999. P. Salama, N.Shroff, and E. J. Delp, Error concealment in encoded video, submitted to IEEE Transactionson Image Processing, 1999.

67

[11] Fermin Uribe. Codificación y decodificación de video tolerante a fallas. Memoria de Ingenie-ría Civil en Computación. Universidad de Chile, 2003.

[12] Video4Linux WIKI. Video for linux. http://www.linuxtv.org/v4lwiki/index.php/Main_Page.

[13] Y. Wang and Q. Zhu. Error control and concealment for video communication: A review,1998. Y. Wang and Q.-F. Zhu, Error control and concealment for video communication: Areview, Proceedings of the IEEE, vol. 86, no. 5, pp. 974-997, May 1998.

[14] Z. Wang, A. Bovik, and B. Evans. Blind measurement of blocking artifacts in images, 2000.Z. Wang, A. C. Bovik, B. L. Evans: Blind measurement of blocking artifacts in images. inProc. ICIP, vol. 3, pp. 981–984, Vancouver, Canada, 2000.

[15] Wikipedia. RGB color model. http://en.wikipedia.org/wiki/RGB#32-bit_mode.

[16] Wikipedia. YUV color model. http://en.wikipedia.org/wiki/YUV#Converting_from_YUV_to_RGB.

[17] S. Winkler. Issues in vision modeling for perceptual video quality assessment, 1999. S.Winkler: Issues in vision modeling for perceptual video quality assessment. Signal Processing78(2), 1999.

[18] S. Winkler, A. Sharma, and D. McNally. Perceptual video quality and blockiness metrics formultimedia streaming applications, 2001. Stefan Winkler, Animesh Sharma, David McNa-lly: Perceptual video quality and blockiness metrics for multimedia streaming applications. inProceedings of the International Symposium on Wireless Personal Multimedia Communica-tions, pp. 547–552, Aalborg, Denmark, September 9–12, 2001.

[19] A. Wrangsjö and H. Knutsson. Histogram filters for noise reduction. In Proceedings of theSSAB Symposium on Image Analysis, March 2003.

[20] D. Wu, Y. Hou, W. Zhu, Y. Zhang, and J. Peha. Streaming video over the internet: Approachesand directions, 2001. http://citeseer.ist.psu.edu/wu01streaming.html.

68

Apéndice A

Glosario

API: Application Programming Interface - Interfaz de Programación de Aplicaciones, es unconjunto de especificaciones de comunicación entre componentes de software.

Blockiness: Efecto en imágenes normalmente debido a simplificación en compresión. Nor-malmente en compresión JPEG la imagen es dividida en bloques de 8x8, sobre los cuales serealiza algún tipo de simplificación de colores, para disminuir la cantidad de información aprocesar, de manera independiente del resto de la imagen. Cuando se utiliza compresión muyalta, los bordes de los bloques se hacen demasiado evidentes al descomprimir, produciendoeste efecto.

Bloque Virtual: Conjunto de macro-bloques de tamaño máximo 255, utilizado en la técnicade aleatorización de pixeles. Una secuencia aleatoria de pixeles es creada a partir de esteconjunto, la cual es distribuida en distintos paquetes para minimizar el impacto producidopor pérdidas.

Codec: (Codificador/Decodificador) Tecnología capaz de codificar y decodificar una secuen-cia de datos, utilizado generalmente en multimedia para video y audio.

Compresión Temporal: Técnica de compresión de video, en donde se minimiza la cantidadde datos a enviar, transmitiendo sólo los cambios detectados entre cuadros consecutivos dela secuencia de video.

FFT: Fast Fourier Transform - Transformada Rápida de Fourier, es un algoritmo de graneficiencia para realizar el cálculo de la transformada discreta de Fourier y su inversa. Es degran importancia en una gran variedad de aplicaciones, en particular en procesamiento digitalde imágenes.

69

GSM: Global System for Mobile Communications, es el estándar de comunicación entreteléfonos móviles mas utilizado en la actualidad.

J2ME: Java 2 Platform Micro Edition, es una colección de APIs de Java para la ejecuciónde programas en dispositivos de bajos recursos, como PDAs y teléfonos móviles.

Macro-bloque: Sección de una imagen, de tamaño 8x8 pixeles, utilizada para detección demovimiento entre cuadros consecutivos de video.

MIDP: Mobile Information Device Profile, versión de J2ME integrada en el hardware deteléfonos móviles que permite el ejecución de aplicaciones Java en estos.

Modelo de color: Simplificación del espectro de colores visible. A partir de éste se puederepresentar cada color posible como una combinación de varias variables. Es particularmenteútil en computación, para disminuir la cantidad de información necesaria para representaruna imagen.

RGB: Modelo de color que representa cada valor del espectro como una combinación derojo, verde y azul (Red, Green, Blue). Cada color puede tomar un valor entre 0 y 255, locual define un espectro de 16 millones de colores. Un color se puede describir utilizando3 bytes, uno para cada componente, aunque modelos como ARGB incluyen un valor Alphapara definir transparencia. Este es el modelo utilizado por los monitores de los computadores.

UDP: User Datagram Protocol, protocolo de transporte de datos a través de la red, basadoen el intercambio de datagramas. No requiere de establecer una conexión. No posee confir-mación de recepción ni control de flujo de paquetes.

Video4Linux (V4L): API para linux desarrollada para interacción con dispositivos de cap-tura de video y televisión, tales como cámaras web y tarjetas capturadoras.

YUV: Modelo de color que representa cada valor posible como una combinación de unacomponente de luminancia y dos componentes de crominancia. Es una representación masfiel de la forma de percibir colores por el ojo humano que RGB, pero más alejada del modode funcionamiento de los monitores.

70

incorporaciÓn de correcciÓn de errores y mÉtricas de ... · se desarrolló una técnica de...

Documents