incorporación de corrección de errores y métricas de calidad

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érmino
la actual memoria. Gracias a mi familia y amigos por el apoyo que me han dado en éstos meses de
trabajo.
1
Capítulo 2
Introducción
Con el avance de la tecnología, la necesidad de información en tiempo real se ha hecho cada
vez más inminente. La distribución de contenido multimedia en internet, en particular de video, ha
alcanzado cada vez un mayor auge. Sin embargo, aún en la actualidad no existen aplicaciones que
realicen esta tarea en tiempo real de manera satisfactoria.
La dificultad principal de este tipo de aplicaciones, radica en la gran cantidad de información
que es necesario transmitir, y en la imposibilidad de asegurar la correcta transmisión de ésta desde
el 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 desarrollar
una aplicación que aproveche la plataforma de trabajo desarrollada por las investigaciones anteriores, agregando mayor tolerancia a la pérdida de datos en la transmisión y conservando lo mejor
posible la calidad del video original.
Se pretende incorporar corrección de errores producidos por pérdidas en la imagen recibida por
el cliente, y definir métricas de calidad perceptual del video para evaluar las mejoras producidas
por 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 contenido multimedia, y en particular de video en tiempo real, ha alcanzado cada vez un mayor auge. Este
tipo de aplicaciones presentan un gran desafío en términos de desarrollo e investigación, debido
a que la calidad del servicio está determinada no sólo por la eficiencia en la transmisión de los
datos, sino que por la calidad de la imagen percibida por el usuario. En la actualidad las técnicas
de compresión utilizadas se enfocan principalmente en la primera parte: transmitir la mayor cantidad 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 segundo
objetivo. Es necesario entonces tener en cuenta dos puntos: definir cuál es la forma más eficiente
de transferencia de datos para disminuir el porcentaje de degradación de la imagen percibido por
el 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 de
servicio 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 redes
IP, son altamente demandantes de recursos de red, debido a la gran cantidad de información que
es necesario transmitir. Distintas tecnologías se han desarrollado en el último tiempo para satisfacer las crecientes necesidades de los usuarios de este tipo de contenido. Entre éstas se encuentran
el desarrollo de redes de mayor ancho de banda y de dispositivos de almacenamiento de mayor
velocidad [20], junto con el mejoramiento de las técnicas de compresión de datos. El concepto inherente de estas últimas es el de disminuir la cantidad de información transmitida a través de la red
mediante la reducción de redundancias en los datos enviados. Por ejemplo, durante la reproducción
de un video, se puede decidir enviar sólo los bits de información que han cambiado entre cuadros
consecutivos.
Uno de los grandes problemas de la transferencia de datos a través de Internet es la pérdida de
paquetes entre el emisor y el receptor. En aplicaciones de video en tiempo real esto es aún más
crítico, ya que no es factible esperar la retransmisión de dichos paquetes sin afectar la calidad del
servicio percibido por el usuario. La solución entonces es desplegar los datos conforme se van re3
cibiendo, ya que para el usuario es menos molesto ver un video de manera continua pero de calidad
deteriorada que tener que esperar para ver una imagen completa. El enfoque actual es entonces
definir métricas de calidad [6, 18] , de manera de poder determinar de forma más específica cuáles
son las condiciones bajo las que el servicio se ve mejorado o deteriorado y además en qué medida
se 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 el
usuario 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 bastante
precisos, sin embargo son de gran complejidad y costo computacional, debido a que muchas de las
características de la visión humana aún no son completamente claras. b) Otras métricas aprovechan
el 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 medición sobre estos para análisis posteriores.
Una vez recibidos los datos en el cliente, si se detectan pérdidas de paquetes durante la transmisión, se debe buscar entonces una forma de corregir dichas pérdidas. Existen distintos enfoques para
realizar esto, uno de las cuales es incorporar redundancia de datos a los paquetes enviados. De esta
manera, en caso de existir una pérdida, es posible reconstruir parte o la totalidad de la información
faltante. 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 datos
redundantes y recuperar la información faltante. Sobre este protocolo se han realizado modificaciones 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 mecanismos 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 por
Cristian Junge [4]. En particular se desea estudiar más a fondo la forma de distribuir de la información de video en paquetes para disminuir la degradación en la calidad de la imagen percibida por
el usuario. Además se espera determinar bajo qué nivel de pérdidas es posible realizar correccio4
nes sobre la imagen final e implementar dichas correcciones en una aplicación. Para realizar esto
se estudiarán algunas métricas de calidad de servicio (QoS) definidas actualmente para entregar
resultados 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], Alvise
Bolsi [1] y Cristian Junge [4], tomando como base sus resultados y realizar experimentos
sobre éstos para estudiar cuáles son los puntos que requieran una mejora y implementar éstas
en una aplicación posterior.
Estudiar algunas métricas de calidad de servicio en sistemas de video sobre Internet para
entregar resultados formales de la calidad de servicio provista por la aplicación de video bajo
distintas configuraciones y distintas condiciones de red.
Estudiar la mejor forma de distribuir la información en paquetes para disminuir el efecto
producida 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 de
red e implementar dichas correcciones en la aplicación final.
Desarrollar una aplicación de demostración que integre los resultados de las investigaciones
realizadas para mostrar de manera empírica los avances obtenidos.
Concluir sobre los resultados obtenidos, entregando recomendaciones basadas en la experiencia 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 particular
con 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 obtenidos 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 los
bloques de imagen a transmitir, con el fin de minimizar el impacto producido por pérdidas en la
imagen final.
Para lograr familiarización con el código y modo de funcionamiento del codec, la primera tarea 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 para
mejorar la mantenibilidad de este en futuras versiones. Esta tarea requirió prácticamente de una
re-escritura completa del programa, pero permitió a la vez lograr un entendimiento cabal del funcionamiento de cada una de las capas del códec.
Una vez logrado este objetivo se procedió a implementar cambios enfocados a medir la calidad
del video recibido por el cliente y a ocultar los pixeles perdidos durante la transferencia. Para esto
se efectuaron las siguientes tareas:
1. Se incorporó un módulo de recolección de estadísticas por cuadro de video. A partir de éste
se pueden almacenar datos de cantidad de bytes, paquetes y bloques enviados y recibidos por
la aplicación bajo distintas configuraciones y distintos niveles de pérdidas de paquetes. Esta
informació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 detección de errores. Éste se encarga de detectar diferencias de cada pixel con sus vecinos cercanos
mediante distintas técnicas. Entre estas se pueden destacar, comparación de distancia entre
colores con los vecinos directos, diferencia con el promedio de colores de los vecinos, diferencia con la mediana de los vecinos. En cada uno de los casos citados, si la diferencia es
mayor que un cierto margen obtenido experimentalmente, entonces se considera que el pixel
esta perdido y se aumenta el valor de la degradación de la imagen. Para realizar una evaluación del funcionamiento de las distintas técnicas, se agregó un módulo de visualización de
errores. Éste permitió ver en línea los errores detectados a través de una ventana adicional
la 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 pixeles
perdidos a partir de la información de los vecinos, es decir, el color de cada pixel perdido se
reemplazó por un valor obtenido a partir de los pixeles cercanos. Para obtener dicho valor se
realizaron 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 manera
efectiva las mejoras introducidas por cada técnica, se implementó una aplicación de prueba
que 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 incorporarla al programa para corregir los errores en tiempo real, debido a esto se observaron
mejoras 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 la
degradació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 caso
para 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 realizado. El capítulo 2 contiene una revisión bibliográfica de los conceptos relevantes para el desarrollo
de la memoria. El capítulo 3 describe en detalle las características del codec implementado y el
trabajo realizado. El capítulo 4 detalla las pruebas realizadas con la aplicación y los resultados
obtenidos. El capítulo 5 describe algunas modificaciones finales realizadas a la aplicación y algún trabajo relacionado con la misma. El capítulo 6 corresponde a las conclusiones. El capítulo 7
entrega 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 investigación se ha realizado en los temas de Streaming de video, calidad de servicio, adaptabilidad a
condiciones de red, etc. Un buen ejemplo de esto se puede encontrar en [20]. En éste se realiza
una 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ón
continua de contenido multimedia, servidores de transmisión de contenido multimedia, sincronización de medios y protocolos de transmisión. Para cada una de estas áreas se explica la función que
cumplen dentro del sistema y se describen algunas de las técnicas utilizadas actualmente para su
implementación. La lectura de este documento sirve como introducción al tópico de transmisión de
video sobre internet y es una buena fuente de referencias, en particular para el tema de calidad de
servicio, 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 previamente
en 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 de
los técnicas de codificación de video vigentes en la actualidad y su tolerancia a fallas. El resultado
más importante obtenido durante este trabajo es el desarrollo de un codec para la transmisión de
video en tiempo real. Para el desarrollo de éste se utilizó una técnica denominada detección de
movimiento, descrita en el documento, la cual consiste en transmitir sólo los bloques de la imagen
que cambian, incorporando un límite temporal sobre los bloques para evitar que un bloque no
recibido por el cliente nunca se refresque. También se analiza la importancia del espaciamiento
temporal 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 éste
se realiza un estudio de técnicas de compresión de video con el objetivo de disminuir el uso de
ancho de banda del codec desarrollado por Fermín Uribe [11]. El resultado más importante de este
trabajo es la disminución del ancho de banda en un orden de magnitud (de 2700 Kb/s a 210 Kb/s
en movimiento normal) para la transmisión de video. Esto se logró aplicando compresión JPEG
a los bloques de video y descomprimiéndolos en el lado del cliente. Además, se logró mejorar
la eficiencia del codec utilizando el espacio de colores YUV en vez de RGB para las imágenes
capturadas, lo cual evita el costo producido por las múltiples transformaciones de espacio de color
necesarias 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 la
experimentación realizada sobre la distribución de los pixeles en los paquetes IP en el codec de
video. Uno de los resultados más importantes obtenidos en este último punto es que la distribución
de pixeles de manera aleatoria minimiza el daño producido por la pérdida de paquetes, ya que se
evita que se vean tramas de pérdidas en la imagen del receptor, sin embargo presenta un problema
con algunos algoritmos de compresión de imágenes, lo que hace que la integración con [1] no sea
posible.
3.2. Métricas de calidad
Entre los objetivos de la investigación a realizar se encuentra el de aplicar métricas de calidad
de servicio a aplicaciones de video IP. Dentro de este tema existen diversas perspectivas respecto
a cómo se deben realizar las mediciones, ya que la calidad del video depende principalmente de
la 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 la
imagen, otras se enfocan en los factores que ocasionan la disminución de ésta. En [6] se puede encontrar un ejemplo de este último. En este documento se presenta una visión general de los puntos
a considerar en el diseño de una métrica de calidad. Se establece un modelo de trabajo en el cuál
se relacionan los requerimientos dados por los usuarios para el servicio, con parámetros de análisis
de calidad y los recursos asociados a dichos parámetros. En particular, se presenta el desarrollo de
una 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 calidad
que involucra todos los factores mencionados anteriormente.
Otro enfoque posible es considerar que la calidad de la imagen de video depende, a fin de cuentas, de la percepción de fallas en ésta por el ojo humano. Algunas métricas ignoran este punto y
utilizan mediciones basadas en diferencias a nivel de pixeles entre la imagen original y recibida por
el cliente. Según este último enfoque, sin embargo, puede ser de mayor utilidad medir la calidad
de la imagen como un todo. En [17] se describen distintos factores de calidad tomando el punto
de vista del usuario considerando el modo de funcionamiento de la visión humana. Entre estos
factores se encuentran: sensibilidad al color, al brillo, a las diferencias de luz, a la naturalidad de
la imagen. Algunos de éstos son analizados desde el punto de vista de la fisonomía de la visión
humana, entregando pautas para la incorporación a un sistema de medición de calidad perceptual
de video. En general existe poca investigación en este última línea debido a la gran complejidad
que presenta el modelamiento de la visión humana.
En el trabajo actual se ha optado por simplificar el problema, considerando la pérdida de paquetes IP como factor principal en la degradación de la imagen final. En la aplicación desarrollada
durante las memorias anteriores [11, 1, 4], se pueden observar patrones de error en la imagen
asociados directamente con las pérdidas de red. Este comportamiento se debe a la forma de implementación de la detección de movimiento mediante división en bloques, con lo cual la pérdida de
paquetes se traduce en pérdida de bloques de imagen. En [18] se describen y comparan tres métricas
de calidad perceptual de video para el análisis de errores para este tipo de implementación. Estas
métricas tienen en común que no requieren de la imagen original para realizar las mediciones. Una
de las técnicas citadas es descrita en mayor profundidad en [14]. Para realizar la medición, esta
métrica modela los patrones de pérdidas por bloques como una interferencia en la transmisión y
luego mide la intensidad de dicha interferencia. Esta medición se realiza en los ejes X e Y de la
imagen, para luego obtener un promedio entre ambas. Durante el trabajo realizado se estudió, entre
otras 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 en
el video recibido por el cliente. En este ámbito existen diversas técnicas desarrolladas, una de las
cuales es la de incorporación de redundancia en los datos enviados. En [8] se describe la aplicación de un protocolo que utiliza Forward Error Correction (FEC) denominado AFEC (Adaptative
Forward Error Correction), en la transmisión de video para disminuir el nivel de error en el video
recibido por el cliente. En éste se muestran también los resultados de la aplicación de este protocolo como capa de transporte para video de compresión MPEG. En [7] se describe en mayor
profundidad 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 es
inestable. En aplicaciones de video en tiempo real, la retransmisión de datos no es una posibilidad. Se hace necesario entonces incorporar redundancia en los paquetes transferidos para permitir
la corrección de errores en la imagen. Sin embargo, se debe tener un buen control en el nivel de
redundancia para evitar generar tráfico excesivo en la red.
Una variante a las técnicas descritas previamente involucra aplicar distintos niveles de redundancia para información de distinta prioridad dentro de la transmisión. En [5] se realiza primero
una descripción en profundidad del protocolo FEC y propone AdFEC Adaptable Forward Error
Correction. Esta modificación aplica FEC con baja redundancia a información que no es crítica para el video, pero cuya pérdida ocasiona molestias en el lado receptor (por ejemplo datos de pixeles
de 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 este
documento permite entender la base matemática del protocolo FEC, transformándola en una fuente
importante 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 la
transmisió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 vecinos
más cercanos. De manera similar, la información de un bloque puede ser reconstruida a partir de la
informació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 equivalente
más cercano. En [9, 13] se describen algunos métodos de interpolación temporal y espacial para
disimulación de errores (Error Concealment). Durante el trabajo realizado se estudió la integración
de 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 de
calidad de video y corrección de errores, algunas de las cuales han sido descritos en la actual
revisió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ón
directa. Sería deseable, por ejemplo, utilizar una métrica de calidad para medir qué tan bueno es
el algoritmo de corrección de errores, utilizándola para analizar los parámetros bajo los cuales se
obtienen mejores resultados. Este es precisamente el enfoque de trabajo que se utilizará durante la
memoria.
12
Capítulo 4
Desarrollo
En el capítulo anterior se revisaron conceptos relacionados con el ámbito de trabajo y el estado
del arte actual. El presente capítulo describe el trabajo realizado durante el transcurso de la presente
memoria.
En primer lugar se describe la plataforma utilizada para el desarrollo. A continuación se describe el funcionamiento del sistema en términos generales y los pasos efectuados para lograr una
familiarización con el modo de funcionamiento de éste, así como las optimizaciones iniciales realizadas al programa. Finalmente se explican los cambios y desarrollos incorporados concernientes
al ámbito de la memoria actual.
4.1. Configuración
La plataforma de hardware utilizada para el desarrollo consistió en un computador con un procesador 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 las
imágenes obtenidas se empleó una tarjeta capturadora de video Prolink PixelView PlayTV. Esta
tarjeta 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 sistema
posee una avanzada capacidad de reconocimiento de hardware y además incluye las bibliotecas de
la 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 de
eficiencia, pero también por ser el lenguaje de implementación original del programa. Como se
podrá 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 por
segundo, 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 de
funcionamiento de la aplicación, previamente a lo agregado durante el transcurso de la memoria
actual.
El codec posee dos partes. Un servidor que captura el video, lo procesa y transmite a través
de la red, y un cliente que recibe el flujo de datos y lo procesa para poder desplegarlo en el lado
receptor.
4.2.1.
Servidor de Video
La aplicación realiza cuatro etapas para la transmisión de los datos, tal como se muestra en la
figura 4.1(a). Éstas son, captura de datos de video (desde una archivo o una cámara), detección
de bloques de movimiento en la imagen, distribución de información en paquetes IP y envío de
paquetes.
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ún
dispositivo conectado al PC, tal como una cámara web o una tarjeta capturadora de video, obteniendo datos mediante la interfaz de Video for Linux, o un archivo guardado en memoria. Cada
cuadro de imagen es guardado como un arreglo de bytes, utilizando 4 bytes para describir cada
pixel, utilizando el modelo de color RGB32 [15].
Detectar bloques con movimiento
Cada cuadro capturado se compara con el inmediatamente anterior para detectar si ha habido
movimiento dentro de la imagen. Para realizar esto, se considera la imagen como un conjunto de
bloques cuadrados de 8x8 pixeles, denominados macro-bloques, cada uno de éstos es comparado
con su equivalente en el cuadro anterior utilizando la varianza de las componentes del color en
el sistema RGB como indicador, considerando los 64 pixeles, las diferencias entre dos cuadros
consecutivos 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 considera que el macro-bloque ha cambiado y este debe ser marcado para envío. Además, de manera
periódica, los bloques deben ser marcados para envío incluso si no se han registrado cambios. Esto
es necesario, ya que podría ocurrir que un bloque no recibido nunca volviera a cambiar en el servidor, lo cual ocasionaría un error persistente en el cliente. Como no existe una retroalimentación de
los 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 de
video al cliente. Esto es logrado transmitiendo solo la información de imagen que cambia en el
tiempo, de manera que el receptor perciba el movimiento ocurrido. Este proceso es comúnmente
usado 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 macrounidad denominada bloque virtual. El máximo tamaño de una de estas unidades es de 255 macrobloques, con lo cual puede contener no más de 64 ∗ 255 = 16320 pixeles. De acuerdo al tamaño
del bloque virtual, se define una distribución aleatoria de pixeles. Éstos son divididos en cuatro
paquetes IP, de manera que el primer pixel de la secuencia aleatoria se agrega al primer paquete, el
segundo al segundo paquete y así sucesivamente hasta recorrer la secuencia completa. Dado que se
utiliza la misma función de aleatorización tanto en el cliente como en el servidor, entonces no es
necesario enviar el orden de los pixeles al cliente.
Utilizando esta estrategia de distribución, se logra disminuir el impacto ocasionado en la imagen
por causa de pérdidas de paquetes. El resultado producido por éstas es la pérdida de sólo algunos
pixeles 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 de
pé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 transmisión UDP.
4.2.2.
Cliente de Video
La aplicación realiza tres etapas para poder mostrar el video recibido, tal como se muestra en
la figura 4.1(b). Recibir paquetes IP, obtener información de imagen de éstos y desplegar imagen
actualizada.
Recibir paquetes
Los paquetes IP son recuperados desde la red, utilizando protocolo de transmisión UDP. El
cliente 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ón
respecto 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 manera que al recibir un paquete de la secuencia de cuatro detallada en la sección anterior, es posible
obtener la información de color y posición exacta de los pixeles recibidos. Una vez recuperados
los 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 en
ellos. Este conocimiento es crucial para los objetivos de la memoria actual, ya que los algoritmos
de 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 realizada
anteriormente. Para ello se partió de la aplicación desarrollada por Fermín Uribe [11], realizando
algunas optimizaciones y re-estructuración del código para mejorar la mantenibilidad de la aplicación. En base al nuevo esquema se procedió a incorporar las mejoras introducidas por Cristian
Junge en su trabajo de memoria [4], para hacer uso de esos avances como punto de partida del trabajo 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. Tal
esquema posee numerosas ventajas:
Detección de dependencias de la aplicación en la plataforma destino y adaptación de la misma
a 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 comunes de distribuciones *nix.
Creación de paquetes comprimidos fácilmente distribuibles a través de Internet para su instalació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 de
compilación, dependencias de la aplicación (headers C, funciones requeridas) y mensajes de
alerta. Es utilizado por la aplicación autoconf para generar el fichero ejecutable de configuración.
Makefile.am: Debe ser definido en cada carpeta para especificar las subcarpetas necesarias
de acceder y los ejecutables o bibliotecas a crear. Junto con cada ejecutable se debe detallar
cada 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 este
archivo 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 desarrolladores, instrucciones de instalación y otras que puedan ser necesarias.
Una vez incorporados los archivos señalados, se pueden generar los archivos necesarios para la
configuració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 compilar 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 cabalidad
el funcionamiento de la misma. Dado que, para el trabajo realizado por Cristian Junge, numerosas
versiones habían sido desarrolladas, la mantenibilidad del código había sido perdida en parte, por
lo cual se optó por reestructurar el mismo. Del análisis realizado pudo detectarse las siguientes
sub-funcionalidades en la aplicación.
Captura de video: Consiste en el proceso de llevar a memoria un cuadro de imagen obtenido
desde una fuente de video particular. Dicha fuente puede ser obtenida desde un dispositivo
de captura (tarjeta capturadora, cámara web), como desde un archivo en disco. El cuadro
capturado se representa en memoria de acuerdo al modelo de color escogido. En el caso
actual se utilizo el modelo RGB32 [15], por lo que la imagen se representa como un arreglo
de 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 almacenada en memoria y determina si ha hubo algún cambio con respecto al cuadro anterior. Para
lograr esto, la imagen completa se divide en cuadrados de 8x8 pixeles o macro-bloques. La
información de color de cada uno de éstos, es comparada con la información del bloque respectivo del cuadro inmediatamente anterior. Si se detectan diferencias que superan un umbral
determinado, entonces significa que dicho bloque debe ser actualizado (o transmitido). Esta
funcionalidad permite realizar compresión temporal sobre los datos de video, es decir, sólo
los cambios en la imagen son transmitidos, disminuyendo el ancho de banda requerido por
la aplicación.
Distribución de información en paquetes: La información de la imagen debe ser luego
procesada para ser enviada al cliente, esta funcionalidad se encarga de distribuir los datos en
paquetes para su transmisión. La información puede ser distribuida de distintas formas para
disminuir el impacto producido por las pérdidas. En el caso del trabajo de Fermín Uribe, los
macro-bloques son distribuidos en forma de grilla, para evitar que segmentos completos de
imagen puedan perderse.
Envío de paquetes: El último paso de transmisión consiste en enviar cada paquete al receptor
utilizando un socket UDP, este proceso es bastante simple, y equivale a escribir datos en un
archivo.
Recepción de paquetes: Esta funcionalidad permite a la aplicación cliente recibir la información enviada por el servidor, para su posterior procesamiento.
Recuperación de información en paquetes: La información de la imagen contenida en los
paquetes es recuperada y actualizada en memoria para su posterior despliegue.
Despliegue de imágenes: Consiste en mostrar en pantalla la imagen tanto transmitida como
recibida. Es equivalente a dibujar cada uno de los pixeles almacenados en memoria en un área
específica de la pantalla. Debe considerarse, sin embargo, como una funcionalidad aislada del
resto.
Utilidades Varias: Dentro de la aplicación se pudo encontrar también otras funcionalidades
para realizar diversas tareas, como transformaciones de espacio de color y generación de
arreglos aleatorios, entre otras. Estas pueden ser consideradas aisladas del resto, de manera
de 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 de
la 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 a
la 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ón
y 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 de
paquetes (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 independiente 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, posibilitando que la entrada y salida de cada una se mantenga. Ambas mejoras mostraron ser útiles en
etapas posteriores del trabajo. En la figura indicada anteriormente, se puede apreciar en detalle la
separación de módulos y los archivos asociados a cada uno.
Una vez finalizada la reestructuración, se procedió a incorporar las mejoras introducidas por
Cristian Junge a la aplicación. Para esto fue necesario modificar la capa de Procesamiento, ya que
dichas mejoras estaban relacionadas principalmente con la distribución de la información de video
en 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 a
cabalidad el modo de funcionamiento de la aplicación, y la interoperabilidad de las distintas partes
de 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 aplicación como preludio al inicio del trabajo en los objetivos particulares de la memoria. En la presente
sección se detalla el esfuerzo realizado para lograr dichos objetivos.
La primera etapa del trabajo consistió en incorporar mediciones a la funcionalidad de la aplicación. Los esfuerzos se concentraron en recolectar información de dos tipos diferentes: valores de
red, como ancho de banda del servidor y cliente y tasa de pérdidas de paquetes; y valores de calidad perceptual de video. Para esto último se desarrolló una métrica que permitiera medir el nivel
de degradación del video obtenido en el lado cliente, tomando en cuenta las diferencias de colores
entre 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 de
datos, cuyo propósito es almacenar información de apoyo a la experimentación, es decir, obtener
cifras y estimadores que permitan evaluar de manera objetiva el desempeño y mejoras alcanzadas
por la aplicación en la medida que se observan avances. El tipo de información recopilada difiere
de acuerdo a si se está transmitiendo o recibiendo video. El cuadro 4.1 detalla cada uno de los datos
considerados.
Distintos tipos de datos son obtenidos en distintas etapas del procesamiento. Por ejemplo, el
tiempo de recepción de un cuadro sólo puede ser actualizado una vez que se haya recibido toda
23
Dato
Frame
Time
Transmisión
Sí
Sí
Recepción
Sí
Sí
Bytes
Packets
Sí
Sí
Sí
Sí
Packet Loss
Virtual Block Loss
Frame Loss
No
No
No
Sí
Sí
Sí
Detalle
Último cuadro transmitido o recibido
Tiempo transcurrido para la transmisión o recepción del último cuadro
Cantidad de bytes transmitidos o recibidos
Cantidad de paquetes transmitidos o recibidos
Cantidad de paquetes perdidos.
Cantidad de bloques virtuales perdidos.
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 actualizada inmediatamente tras enviar o recibir un nuevo paquete. Debido a ésto, se desarrolló una
serie de funciones para actualizar la información de la aplicación, las cuales pueden ser invocadas
en cualquier parte del procesamiento. El cuadro 4.2 enumera cada una de estos procedimientos y
detalla 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 de
forma posterior a cada experimento. Combinando la información de número de paquetes enviados
con 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 cifras
representativas 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 en
el lado receptor del mismo. Bajo este concepto, no es posible medir de forma objetiva la mejora o
deterioro 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, desarrollar
una métrica de calidad de video que permita comparar resultados de transmisión.
24
Función
stats_update_bytes
Descripción
Actualiza la cantidad de bytes recibidos de acuerdo a la información contenida en el header length del paquete. Dicho valor considera tanto el tamaño del header como el de los datos contenidos en el
paquete.
stats_update_packets
Actualiza la cantidad de paquetes recibidos. Es equivalente a incrementar un contador cada vez que se recibe un nuevo paquete.
stats_update_packet_loss Actualiza la cantidad de paquetes perdidos. Esta información se obtiene utilizando la secuencia del paquete contenida en el header del
mismo. Si la diferencia entre el paquete actual y el recibido anteriormente es mayor que 1 entonces se determina que se perdieron
paquetes y se realiza esta invocación.
stats_update_v_blk_loss Actualiza la cantidad de bloques virtuales perdidos. Dentro de los
datos de cada paquete se incluye información respecto a la secuencia
en el cuadro del bloque virtual que se está recibiendo actualmente.
De la misma forma que la función anterior, si la diferencia entre
dos paquetes consecutivos es mayor que 1, entonces se considera el
bloque virtual como perdido y se realiza este llamado.
stats_update_frame
Realiza varios procedimientos: calcula el tiempo de procesamiento
del cuadro completo, determina si hubo pérdida de cuadros desde la
última actualización y decide qué hacer con los datos recolectados
desde ésta, ya sea desplegarlos en pantalla o almacenarlos en un archivo CSV. Por último, vuelve los valores a cero para la siguiente
recolección.
Cuadro 4.2: Detalle procedimientos de recopilación de datos
Existen trabajos desarrollados en términos de métricas de calidad. Particularmente interesante
es el descrito en el documento Blind Measurement of Blocking Artifacts in Images [14]. Este propone un algoritmo de medición de blockiness (defecto producido en la imagen por aproximaciones
realizadas durante la compresión). Este algoritmo sólo requiere del flujo recibido de video para
operar y simula el deterioro del video como la interferencia de una señal en la recepción (blocky
signal). Utilizando FFT (Fast Fourier Transform) mide la intensidad de esa señal entregando un
valor de calidad de video.
Durante esta etapa del trabajo, se realizó un estudio sobre transformada de Fourier para analizar
su posible aplicación a una métrica. Se investigó acerca de la aplicación de transformada discreta de
Fourier y tranformada discreta de coseno al procesamiento y compresión de imágenes [2]. Debido
a 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 era
posible 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 a
continuación.
Detección de errores en la imagen
Con el algoritmo de transmisión utilizado, las pérdidas generadas en la imagen son claramente identificables como un haz de pixeles, los cuales presentan un color distinto al del fondo de
la imagen. En la figura 4.4, se puede apreciar que un movimiento brusco del sujeto deja como
consecuencia 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, que
detecte los pixeles que presentan alguna diferencia con sus vecinos superior a algún umbral. Es
decir, para detectar errores se puede partir de la hipótesis, de que la distribución de valores entre
pixeles vecinos en una imagen es relativamente uniforme. Este enfoque fue el utilizado para el
desarrollo 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 de
errores, fue necesario incorporar al cliente de video un módulo que permitiera graficar cada uno de
los errores detectados. Para lograr esto se utilizó la biblioteca libplot que forma parte del proyecto
GNU plotutils [3].
Con el algoritmo desarrollado, es necesario recorrer todos los pixeles de la imagen para detectar
cuáles son los erróneos. En una ventana externa a la de video, utilizando libplot, se pinta cada uno
de estos errores detectados de un color diferente al del fondo, de esta manera, si la detección es
satisfactoria, el patrón producido por el error en la ventana de video, debe ser similar o idéntico al
producido en la ventana de errores. En la figura 4.5, se observa la detección de errores con una de
las técnicas probadas y su correspondiente gráfico. El valor numérico en el gráfico corresponde al
porcentaje 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 que
puedan ocurrir algunos falsos positivos. Si se tiene un objeto que presenta mucho contraste con
el fondo, como un cuadrado negro sobre un fondo blanco, al comparar colores en los bordes del
cuadrado, estos serían detectados como pixeles erróneos por un algoritmo muy simplista. Uno de
los factores considerados al probar distintas técnicas fue la cantidad de falsos positivos generados
por cada una, de manera que al menos éstos puedan ser despreciados. Asimismo, se consideraron
tambié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 promedio
a vecinos, distancia a mediana de los vecinos y distancia a vecinos más cercanos. A continuación
se 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 bastante
intuitivo, la distancia en colores entre dos pixeles corresponde a "la suma de los cuadrados de las
diferencias 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. Para
calcular 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 sensible
a las variaciones de luz que de color. La razón por la cual se escogió YUV en vez de RGB, fue para
evitar 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 de
color 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 que
generara 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 detectado
fue que, si la diferencia en intensidad entre los pixeles erróneos y la imagen no es suficientemente
grande, 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 la
distancia de colores, este consiste en la "suma de los cuadrados de los componentes de color", es
decir, equivale a:
R 2 + G2 + B 2
(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 vector
de 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 y
se calcula el módulo de color de cada uno de éstos. Utilizando estos valores se obtiene la mediana
del conjunto, es decir se extrae el valor en el punto medio de grupo, ordenando numéricamente los
pixeles. Si la diferencia de la mediana con el módulo del pixel evaluado es mayor que un cierto
umbral (55000), entonces se considera como un error. En la figura 4.7 se pueden observar los
resultados obtenidos por este método.
29
(a) Imagen
(b) Gráfico
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 el
método anterior, de acuerdo a la observación de los gráficos, presenta demasiados falsos positivos
para ser ignorado, incluso modificando el valor umbral. Haciendo un análisis más profundo del
funcionamiento de este algoritmo, se llega a la conclusión que el módulo no es un buen factor
de comparación. Esto se debe a que, particularmente en RGB, muchas combinaciones retornan el
mismo 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
|G|2 = 02 + 2552 + 02 = 65025
|B|2 = 02 + 02 + 2552 = 65025
(4.4)
(4.5)
(4.6)
Los valores resultado son idénticos, lo que implica además la alta probabilidad de falsos negativos, es decir, considerar que colores totalmente diferentes tienen una diferencia nula, de acuerdo
a 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 distancias
del pixel evaluado con sus vecinos inmediatamente superior e izquierdo, respectivamente. Cada
distancia es comparada independientemente con un valor umbral, si ambas superan dicho umbral a
la 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 la
imagen, en caso de encontrar una desviación muy grande de la curva obtenida, tal como se muestra
en la figura 4.8(a), es razonable considerar al pixel como posibilidad de error. Para obtener un grado
de certeza en la evaluación es necesario entonces, intersectar la fila y columna correspondiente a
este punto. Si se considerase sólo un eje se podrían observar casos de mucho contraste, como el
mostrado 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 satisfactorios de las tres técnicas probadas, de acuerdo a las observaciones de los gráficos, aunque aún puede
observarse cierta cantidad de falsos positivos, éstos pueden ser considerados despreciables.
31
(a) Imagen
(b) Gráfico
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 a
vecinos cercanos. El nivel de degradación de la imagen es calculado entonces como la razón entre
la 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 la
esquina superior derecha, ese valor corresponde a la degradación porcentual del video calculada
mediante el método correspondiente.
Con la determinación de una métrica de calidad de video, es posible entonces realizar experimentos y comparaciones entre las distintas versiones de la aplicación y demostrar el avance efectivo
en é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 satisfactorio
para corrección (ocultamiento) de errores. Dentro de esta etapa del trabajo, se estudiaron diversas
investigaciones actuales con tal enfoque, en particular destaca [10] en donde se presentan algunas
técnicas de interpolación de pixeles y bloques para flujos de video. De la misma manera que con
métricas de calidad, el esquema de procesamiento y transmisión utilizado en el codec actual hace
que la aplicación de estas técnicas sea poco factible.
Para ocultar efectivamente los errores de la imagen recibida, se probaron varias técnicas distintas, que funcionan bajo el mismo concepto. Al momento de reconstruir la imagen a partir de
los paquetes recibidos, es fácil saber cuáles pixeles no fueron posibles de actualizar, por no tener
disponible el paquete correspondiente. Cada uno de estos pixeles no actualizados, es calculado a
partir del valor sus vecinos, a la manera de un filtro de imagen. Para el cálculo realizado, no es
necesario saber si los pixeles colindantes son correctos, ya que los filtros se enfocan en calcular el
valor 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 permite
observar una imagen en tres estados distintos:
1. Imagen Original: Es equivalente a pausar la transmisión (tomar una fotografía de la captura
de 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 bloque
indicado inicialmente. Los pixeles perdidos pueden ser reconocidos como puntos negros en
la imagen, para permitir observar correctamente el deterioro causado.
3. Imagen corregida: Se corrigen los errores generados anteriormente en la imagen, utilizando
alguna de las técnicas indicadas al iniciar la aplicación. Los pixeles perdidos son determinados y recorridos tal como se hace en el programa cliente. Finalmente muestra el resultado de
la corrección.
33
La aplicación fue desarrollada para poder comparar de manera visual las mejoras introducidas
por cada una de las técnicas de corrección, ya que tal comparación no era posible de realizar de
manera 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 componentes
del rojo, verde y azul en el espacio RGB de cada uno de los vecinos son sumadas y divididas por
el total de pixeles para obtener el valor de cada componente del pixel perdido. La justificación para
este método es que la variación de valor entre pixeles colindantes es, en general, suficientemente
pequeña, por lo que es posible reemplazar el valor de un pixel determinado por el del promedio de
sus 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, el
resultado obtenido es aceptable, pero los errores nunca son ocultados completamente, incluso en
pruebas con menores niveles de pérdidas, el efecto observado es similar a difuminar (blur) los
errores 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 es
la mediana de los vecinos. Los pixeles colindantes son ordenados de acuerdo a su módulo de color
y las componentes R, G y B del pixel perdido son reemplazadas por las componentes R, G y B del
punto medio del conjunto. Este método puede ser justificado, a partir de la suposición de que los
valores escalares (módulos) entre pixeles vecinos son similares, por lo que sería factible reemplazar
el 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 obtenido
no es tan bueno como con el filtro de promedio. Se puede observar que no sólo los errores persisten 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 mas
dramático si se aumentan los porcentajes de pérdidas de pixeles. Este resultado induce a descartar
la suposición inicial. Como se mencionó anteriormente, el módulo de color no es una buena medida
de comparación, ya que varios distintos combinaciones de componentes retornan el mismo valor
(por ejemplo rojo, verde y azul).
(a) Original
(b) Pérdidas
(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 como
la mediana de la componente respectiva de los pixeles colindantes. Este método es inspirado en el
filtro 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 los
errores 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 resultados
parecidos a los de mediana de módulo, sin embargo, a simple vista este método muestra mejoras
considerables respecto a los anteriores.
(a) Original
(b) Pérdidas
(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 pixeles
centrada en el pixel perdido. La información de color de los 24 pixeles escogidos es agrupada
en conjuntos de acuerdo a la tabla 4.3. El conjunto con más elementos es el que tiene mayor
probabilidad de contener al pixel perdido. Las componentes de color de éste, son reemplazados
respectivamente por la componente promedio de los pixeles en el conjunto escogido. Esta técnica
es inspirada por el filtro de reducción de ruido basado en histograma descrito en [19].
37
Azul (B)
Rojo (R)
0 - 127
0 - 127
5
128 - 255
8
128 - 255
9
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 correctamente
por este método, retornando resultados satisfactorios. El mayor problema observado se produce en
las partes de la imagen en que hay un cambio drástico de colores, como en los bordes de alguna
figura. Debido al modo de funcionamiento del algoritmo, el color en esas secciones no puede ser
bien definido por lo que se produce una pérdida de información en éstas. El efecto se hace más
drástico cuando se aumentan las pérdidas de pixeles.
(a) Original
(b) Pérdidas
(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érminos
de la calidad obtenida en el video tras la corrección de errores. Éstas son corrección de errores
probabilística y corrección de errores por mediana de componentes. Ambas técnicas logran corregir errores casi completamente bajo condiciones de 25 % de pérdidas. Sólo análisis más profundos
podrán determinar cuál se comporta mejor utilizada en la recepción de video y bajo distintas condiciones. 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ódigo
fuente de la aplicación con diversos propósitos. Lo primero fue agregar mantenibilidad y modularidad al código para una mayor facilidad de modificación. A continuación se incorporaron las
herramientas autoconf y automake para hacer más sencilla la compilación y versionamiento de la
aplicación.
En lo que respecta al trabajo en los objetivos de la memoria, se incorporó metricas de calidad de
red y de calidad perceptual de video a la aplicación para ser utilizadas como apoyo a la experimentación. En el último tipo de métrica, diferentes técnicas fueron probadas, en base a detección de
pixeles perdidos (ver cuadro 4.4), destacándose la de distancia a vecinos cercanos, la cual detecta
errores en la imagen comparando cada pixel con sus vecinos cercanos detectando variaciones en
sus distancias.
También se incorporó un módulo de corrección de errores a la aplicación, este permite ocultar
los 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: corrección de errores probabilística y corrección de errores por mediana de componentes. Análisis más
profundos permitirán determinar cuál de las dos funciona mejor en la mayor cantidad de condiciones.
39
Métrica
Distancia promedio a vecinos
Resultados
satisfactorios
No
Distancia a mediana de vecinos
No
Distancia a vecinos más cercanos
Si
Detalles
Pocos falsos positivos. Falsos negativos
donde diferencia de color no es significativa
Detección satisfactoria de errores. Cantidad de falsos positivos muy alta para ser
ignorada.
Mejores resultados. Detección satisfactoria de errores. Cantidad de falsos positivos despreciable.
Cuadro 4.4: Comparación de resultados entre técnicas de detección de errores
Técnica
Promedio
Resultados
satisfactorios
No
Mediana de módulo
No
Mediana de componentes
Si
Probabilística
Si
Detalles
Errores no son ocultados completamente.
Efecto difuminación de errores.
Errores no son ocultados completamente.
Efecto de agrupación de errores en áreas
mas densas.
Corrección satisfactoria, errores eliminados casi completamente.
Corrección satisfactoria, errores eliminados casi completamente. Perdida de información en zonas donde hay cambio drástico 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 efectiva
entre ellas. El parámetro de análisis considerado fue el nivel calidad de video, valor obtenido a
partir de la utilización de la métrica definida.
Para mantener las mismas condiciones de ejecución durante las diversas pruebas a realizar, se
capturaron dos secuencias de video para ser utilizadas reiteradamente en las evaluaciones. Cada una
tiene 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, por
lo que hay poca posibilidad de pérdidas. La segunda contiene una mayor cantidad de movimientos
rápidos, principalmente mucha expresión con las manos, se demanda gran cantidad de ancho de
banda 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 algunas debido a la capacidad de procesamiento del equipo. Para simular ambientes de pérdidas
controlados, la aplicación puede descartar paquetes al momento de envío con una cierta probabilidad, para alcanzar algún nivel establecido. La probabilidad de perder un paquete es uniforme, es
decir, se calcula sin dependencia de paquetes anteriores. Por ejemplo, si se desea obtener pérdidas
de 30 %, entonces al momento de enviar un paquete particular, este es descartado con esa probabilidad (aproximadamente 1/3 de las veces). Una simulación más realista podría ser realizada a partir
del 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 se
encarga de ejecutar el cliente y el servidor para distintos niveles de pérdidas y almacenar los datos
en una ubicación específica para su posterior análisis. La configuración utilizada fue considerada
para pérdidas entre 0 % y 35 %.
El tamaño del video de prueba es 352x240, tamaño que permite un consumo de ancho de banda
razonable (1 MByte/s) a 30 cuadros por segundo. Entre las pruebas realizadas no se tomó en cuenta
la cantidad de información transmitida, por no tener reelevancia para los objetivos esperados de la
memoria 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 % para
3 casos distintos: recepción de video sin corrección, utilizando técnica probabilística de corrección
y utilizando técnica de mediana de componentes. Dicha comparación fue realizada para las dos
secuencias de video mencionadas anteriormente. En las figuras 5.1 y 5.2 se puede observar los
resultados del experimento realizado. Se puede notar una clara diferencia entre los porcentajes de
error detectados para las 3 evaluaciones distintas. El método mediana de componentes, resulta ser el
que retorna mejores resultados, pero claramente el método probabilístico introduce grandes mejoras
a 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 %, como
el 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 utilizando
corrección por mediana, se obtiene que 0.48 % de error corresponde a 411 pixeles erróneos, es
decir se obtuvo una mejora de al menos un 60 %. El mismo valor puede obtenerse al aproximar
las curvas por una recta, tal como se muestra en la figura 5.3. La pendiente de la recta indica la
razón de aparición de errores para cada nivel de pérdidas, esto implica que a menor pendiente, es
menor el efecto de las pérdidas sobre el video recibido. El cambio de la pendiente desde 0.0452 (sin
corrección) a 0.0129 (corrección por mediana) indica una mejora de más de un 60 % en la calidad
general del video.
42
Al examinar el video recibido simulando pérdidas sobre 25 %, se puede observar una pérdida de
precisión en el funcionamiento del algoritmo de corrección. Esto ocurre porque en la medida que
las pérdidas aumentan, también aumenta el porcentaje de pixeles no actualizados sobre los macrobloques, llegando incluso a producirse pérdidas de macro-bloques completos. Como las técnicas de
corrección utilizan la información de los vecinos cercanos para realizar la interpolación, entonces
grandes pérdidas de pixeles implican que no se pueda realizar este proceso correctamente, produciéndose un efecto de atenuación de límites entre bloques, lo cual contribuye de manera negativa a
la calidad final de la imagen. Bajo 25 % de pérdidas, sin embargo, los resultados obtenidos por la
té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én
realizar un análisis de la métrica de calidad. En los gráficos se puede observar que para 0 % de
pérdidas, el valor retornado por la métrica es distinto de cero, tal como era esperado de acuerdo
al modo de funcionamiento de la misma. Los valores obtenidos, 0.091 % para la secuencia lenta
y 0.042 % para la secuencia rápida, corresponden a los falsos positivos detectados por la métrica
para cada video. Como la aplicación está pensada principalmente para video conferencia, el entorno dentro de la imagen nunca cambia completamente, por lo que se puede asumir que los falsos
positivos 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 %, a
lo largo de cada una de las secuencias de video (utilizando corrección). En las figuras 5.4 y 5.6
se muestran los resultados obtenidos para la secuencia rápida y lenta, respectivamente. A partir del
gráfico y la observación del video, se puede notar que el comportamiento de la métrica es consistente con los niveles de movimiento en la imagen. En la secuencia lenta, hay una cantidad considerable
de movimiento al inicio y luego sólo movimiento de los labios del sujeto. En el gráfico correspondiente (5.6), se observa el mismo comportamiento, un alza importante en el valor de la métrica al
inicio y un comportamiento relativamente uniforme a continuación. Este efecto también puede ser
apreciado para la secuencia rápida, las alzas mostradas en el gráfico, coinciden con segmentos de
video con mayor cantidad de movimiento. Esto es de esperar por el modo de funcionamiento de
la 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 escena, la calidad mejora lentamente en la medida que los macro-bloques faltantes van llegando. Este
comportamiento 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 esperable, el valor de la métrica aumenta en la medida que el nivel de pérdidas es incrementado. Dicho
aumento muestra ser bastante uniforme para distintos niveles, mostrando sólo algunas variaciones
que 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 sin
correcció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. Debido
al modo de funcionamiento de la métrica, esto resulta en pérdida de confiabilidad de los resultados
retornados por ésta, ya que sólo son detectados como erróneos los pixeles en los bordes de los
bloques 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 masivas
ya que implica que uno de cada cuatro paquetes no pudo ser recibido, lo cual supera los umbrales
actuales en Internet.
Con respecto al rendimiento, el procedimiento para calcular la métrica resulta ser muy demandante de recursos, ya que se debe analizar la imagen completa, pixel por pixel, 30 veces por
segundo. Esto presenta un aspecto negativo sobre la técnica utilizada. Durante la recepción, si se
despliega la imagen en pantalla y a la vez se analiza la misma, el tiempo que se tarda en realizar
ambos procedimientos resulta en un aumento de las pérdidas de paquetes, por no poder procesarlos
en la medida que son recibidos. Para realizar los análisis, fue necesario omitir el despliegue de imagen, 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 secuencia
rá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 niveles
de pérdidas entre 0 y 35 % para tres casos distintos: sin efectuar corrección, corrección por técnica
probabilística y corrección por método de mediana de componentes. Las pruebas fueron realizadas
utilizando dos secuencias de video, una con gran cantidad de movimiento y otra con movimiento
moderado.
Los resultados obtenidos fueron los esperados de acuerdo a las hipótesis iniciales. La técnica
de corrección por mediana introdujo una mejora en la calidad de aproximadamente un 60 % y la
técnica probabilística de aproximadamente un 30 %. Se determinó también que ambos resultados
son confiables bajo niveles de pérdidas de 25 %, lo que resulta altamente satisfactorio para los
objetivos de la memoria.
La métrica desarrollada también mostró ser congruente con lo esperado. El valor retornado
por ésta aumenta en la medida que se detectan más pérdidas, tanto en promedio, como durante el
transcurso de una secuencia de video particular. Como lado negativo, se observó que la aplicación
de esta medición resulta en un gran consumo de recursos, lo cual tiene el efecto contraproducente
de generar pérdidas cuando se combina su uso con el despliegue de video. Sin embargo, para
propósitos experimentales, los resultados retornados por ésta mostraron ser de gran utilidad para
los análisis.
En términos generales, se puede considerar que los resultados obtenidos son congruentes de
manera satisfactoria con los objetivos deseados. Es posible, de manera simple, disminuir el impacto producido por pérdidas de paquetes en la recepción de video. Sin agregar redundancia ni
informació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 la
aplicación de video con el fin de mejorar otros aspectos de la misma. En particular se concentraron
los esfuerzos en disminuir de alguna forma el ancho de banda requerido para la transmisión de
video. En este aspecto, se hicieron algunas modificaciones a la detección de movimiento en el
servidor, así como agregar la posibilidad de limitar la tasa de captura de cuadros de video. Ambas
secciones del procesamiento tienen relación directa con el uso de ancho de banda. Una mejor
detección de movimiento permite transmitir sólo la información efectivamente modificada durante
la captura y tal como fue estudiado en trabajos de memoria anteriores, la tasa de captura tiene una
razón directamente proporcional con el ancho de banda utilizado [4].
Trabajo adicional fue realizado, en términos de poder estudiar el funcionamiento de la aplicación en otras plataformas de software y de hardware. Con este fin se desarrolló una versión del
cliente 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átiles
como 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 del
color visible, tiene su fundamento de manera muy cercana a la fisiología de la visión humana. El
trabajo realizado por Alvise Bolsi [1], demostró que realizar detección de movimiento utilizando
este 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 de
esto es que el ojo humano es mucho más sensible a los cambios de luminosidad que de color, con
lo 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 efectuaron
modificaciones al módulo de detección de movimiento de la aplicación. Una conversión de espacio
de 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
U = −0,14713 ∗ R − 0,28886 ∗ G + 0,436 ∗ B
V = +0,615 ∗ R − 0,51499 ∗ G − 0,10001 ∗ B
(6.1)
(6.2)
(6.3)
Dicha fórmula requiere del uso de coeficientes de punto flotante para la conversión, lo cual
resulta en una disminución del desempeño de la aplicación completa, por la ineficiencia en general
de los procesadores para manejar este tipo de valores. Sin embargo es posible realizar dicha conversión sin la necesidad de utilizar valores decimales. A partir de la siguiente fórmula es posible
realizar dicho procedimiento, haciendo uso sólo de valores enteros [16].
Y = min(abs(R ∗ 2104 + G ∗ 4130 + B ∗ 802 + 4096 + 131072) >> 13, 235)
U = min(abs(R ∗ −1214 + G ∗ −2384 + B ∗ 3598 + 4096 + 1048576) >> 13, 240)
V = min(abs(R ∗ 3598 + G ∗ −3013 + B ∗ −585 + 4096 + 1048576) >> 13, 240)
(6.4)
(6.5)
(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 manera
notoria el rendimiento del servidor de video. La fórmula utilizada para detectar movimiento en
RGB (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 un
macro-bloque.
Con el cambio realizado se logró reducir el uso de ancho de banda en aproximadamente un
60 %, de un promedio de 3 MBytes/segundo se disminuyó a 1MByte/segundo, con un mínimo de
300 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 de
banda 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 la
visión humana es 30 cuadros por segundo, pueden haber casos en donde sea razonable sacrificar
fluidez de video por ancho de banda.
Se realizó una modificación al servidor de video, la cual a partir de un parámetro definido en
el archivo de configuración de la aplicación, permite bajar la tasa de captura de cuadros, introduciendo un tiempo de espera al final del procesamiento de cada imagen. El resultado obtenido fue
satisfactorio, una reducción de la tasa de captura en un 50 %, tiene como resultado la reducción del
ancho 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 la
capacidad 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 de
paquetes.
6.3. Cliente Java
Para aplicaciones de transmisión multimedia, en particular para video-conferencia, portabilidad
entre distintas plataformas se transforma en una ventaja importante, más aún si se desea realizar una
versión utilizable por el público general. Con el propósito de analizar el funcionamiento en otras
plataformas, se desarrolló una versión del cliente utilizando lenguaje de programación Java, el cual
permite la ejecución de la aplicación de manera casi independiente de la plataforma de hardware y
software utilizada. Como dicho lenguaje es de más alto nivel que C, por consiguiente incurriendo
en una degradación de eficiencia, se hace interesante estudiar el comportamiento de los algoritmos
de recepción de video en esta nueva versión.
El desarrollo del cliente fue relativamente directo, el algoritmo utilizado para reconstruir el
video 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 paquetes en el servidor, primero se crea una estructura de datos en C, con la información en la
cabecera del paquete, incluyendo un puntero a la sección en memoria que contiene la información propiamente tal de la imagen, para luego concatenar dicha información en el cuerpo
del paquete. Esto tuvo la consecuencia que, para implementar la recepción, fue necesario
realizar algunas pruebas para determinar qué partes de los datos recibidos correspondían a
la cabecera y qué partes al cuerpo paquete. De dichas pruebas, se determinó que era necesario ignorar algunos bytes del mensaje para poder interpretarlo de manera exacta a como fue
enviado.
Aleatorización de pixeles Uno de los fundamentos de la aplicación desarrollada en C, es
que el método de generación de números aleatorios es exactamente el mismo en el servidor
que en el cliente, esto evita que se tenga que transmitir información respecto al orden de los
pixeles dentro del paquete. Esta propiedad, sin embargo, no se cumple al cambiar el lenguaje
de programación. Para mantener dicho fundamento, fue necesario implementar una función
de números pseudo-aleatorios, incorporándola tanto al servidor como al cliente. Con esta
modificació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 necesarios 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 bytes
necesarios 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 al
intercambiar ambas componentes de color.
Despliegue de imagen: A pesar que existe una biblioteca de Java especializada para multimedia, es una desventaja conocida que ésta no permite la reproducción de video a más de 15
cuadros por segundo, lo cual entra en conflicto con lo deseado para el cliente. Además, dado
que 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. Para
lograr 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. Con
esto se logró desplegar imágenes a la tasa deseada.
La aplicación final desarrollada mostró bastante eficiencia en el despliegue de video en tiempo real, produciéndose sólo algunas pérdidas por capacidad de procesamiento del lenguaje, pero
el resultado final es satisfactorio. En la figura 6.1 se puede ver la aplicación ejecutándose en el
sistema operativo Mac OS X. De acuerdo a lo observado, es posible desarrollar una aplicación
multi-plataforma utilizando el lenguaje Java. Cabe mencionar que no se incorporó corrección de
errores 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 plantea
un punto de vista interesante sobre los límites del funcionamiento y rendimiento de la aplicación
cliente. De particular interés es probar la aplicación funcionando sobre dispositivos móviles, los
cuales presentan capacidades de procesamiento y memoria más limitados que un computador de
escritorio. Además presenta la posibilidad de ver el comportamiento del algoritmo de transmisión
sobre 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 al
modo de funcionamiento del cliente Java, fue posible reutilizar la mayor parte de las componentes
de software de éste para el desarrollo del cliente móvil. Sólo fue necesario realizar algunos cambios
en la forma de recepción y de despliegue de video. Se requirió, sin embargo, realizar algunos
cambios a la configuración por omisión de la aplicación. El máximo tamaño de bloque virtual
fue modificado de 255 a 32, para disminuir el tamaño de los paquetes enviados. El tamaño de
captura de video se redujo a 160x120, ya que no se necesita una resolución mayor para dispositivos
móviles. Dentro de la aplicación cliente se incorporó una pantalla para modificar los valores de la
configuración. Además se agregó una característica para permitir escalar el video a la pantalla en
caso 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 equipo
N91 cuenta con conectividad via Wireless LAN. Utilizando conectividad por red inalámbrica, se
pudo recibir el video en tiempo real, a 30 cuadros por segundo, sólo presentando algunos errores
por pérdidas menores. Como era de esperar, al utilizar conectividad EDGE, se produjeron gran
cantidad de pérdidas debido a las limitaciones de ancho de banda, mostrando que las limitaciones
para ejecutar el cliente en equipos móviles, están asociadas a la velocidad de la conexión, más que
a 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 puede
ver el equipo recibiendo video desde el servidor utilizando red inalámbrica. Puede apreciarse que
la transmisión es en tiempo real. En la figura 6.4 se puede ver el equipo recibiendo video desde
el servidor utilizando red EDGE, se puede observar que la transmisión presenta un retraso con
respecto 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 informació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 usuario
final de errores en la imagen, no era posible realizar una comparación objetiva entre versiones de
la aplicación de video. Este problema fue solucionado mediante el desarrollo de una métrica de
calidad perceptual de video, basada en detección de errores por comparación entre pixeles. Ésta
permitió asociar un valor numérico a la degradación en la imagen recibida, con lo cual fue posible
evaluar las mejoras alcanzadas por el trabajo realizado.
Para ocultar efectivamente los errores se requirió probar distintas técnicas. Cada una de éstas
funciona mediante calcular el valor de un pixel no actualizado en base a la información de los
pixeles 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 acuerdo
a 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 video
constantes, se obtuvo como resultado que la técnica de corrección por mediana de componentes
producía una mejora de calidad mayor que la corrección probabilística. Se determinó incremento
de calidad de aproximadamente 60 % con respecto a no utilizar corrección de errores, para pérdidas
inferiores a 25 %.
Como trabajo lateral, en términos de uso de ancho de banda, se logró reducir en 2/3 los requerimientos de red de la aplicación, mediante la utilización de detección de movimiento en el espacio
de 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ón
en diferentes plataformas. Se desarrolló también un cliente J2ME para su utilización en teléfonos
celulares. El rendimiento mostrado por ambas aplicaciones fue satisfactorio, lográndose recibir
video 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 dentro
de flujos de video, sin la necesidad de incorporar algún tipo de redundancia de datos, y sólo tomando
como base la información ya existente en la imagen recibida.
Este sistema fue instalado y demostrado en Entel PCS, generando muchas expectativas de parte
de las áreas de ingeniería, y generando un proyecto de trabajo conjunto entre el DCC y Entel PCS
en ésta área.
63
Capítulo 8
Trabajo Futuro
Durante los diversos trabajos en la materia de estudio actual, numerosos avances han sido logrados, incluyendo los mostrados durante el trabajo actual. Sin embargo, aún quedan muchas posibilidades 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 aplicación y la retro alimentación de información desde el cliente al servidor, para adaptar el algoritmo
de 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 pixeles
presenta un gran avance en tolerancia a pérdidas y cuando es combinado con corrección de errores
aún más, tal como se explicó en el trabajo actual. Sin embargo, este procedimiento presenta una
gran desventaja, la cuál es hacer imposible la incorporación de técnicas de compresión lossy, como
JPEG. 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 las
diferencias entre pixeles colindantes. Al aleatorizar los puntos a transmitir, dicha correlación se
pierde, con lo cual aplicar compresión resulta en una pérdida de la información de color de la
imagen.
64
Otras técnicas de compresión se declaran lossless (PNG, GIF), es decir que la información de
color 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 obtener
tasas de despliegue mayores a 20 cuadros por segundo.
La compresión PNG, en términos simples, se compone de tres etapas. La primera etapa realiza
una transformación aritmética sobre los datos, para hacer la información más compresible. En la
segunda etapa, se comprimen los datos utilizando un algoritmo denominado como Ziv-Lempel. La
información es luego comprimida aún más utilizando el algoritmo de Huffman en la tercera fase
del 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 sentido 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 de
ocurrencias de caracteres en el texto a comprimir, con el fin de generar un nuevo diccionario que utilice menor cantidad de información para codificar los caracteres más usados. Tales técnicas tienen
también sus versiones adaptativas, en donde se adapta el diccionario de la misma forma tanto para
comprimir 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 mediante
una transformación de RGB32 a RGB565. Si se considera el conjunto de información como una
secuencia de caracteres, dicha simplificación aumenta la probabilidad de repetición de éstos dentro
de 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ón
para su uso particular dentro de la aplicación y evaluar los niveles de compresión posibles de alcanzar 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 capacidades
de red entre el servidor y el cliente. Es decir, cada una de las partes transmite o recibe a la máxima
capacidad que lo permite su conexión de red. Esto es un factor importante a considerar, ya que si la
velocidad de transmisión es mucho mayor que la de recepción, entonces se producirán pérdidas en
el 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 respecto
a las capacidades de los clientes conectados, más aún, no posee ningún medio para saber que la
informació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 de
forma paralela a la transmisión de video, utilizando protocolo TCP/IP, de manera de que el servidor pueda obtener una retro-alimentación acerca del funcionamiento del cliente, tal como cantidad
de paquetes perdidos, bytes recibidos, etc. Esto permitiría al servidor adaptar el algoritmo de transmisión, introduciendo pausas entre el envío de paquetes, por ejemplo, para mejorar la calidad de
recepción de video.
La implementación de dichas mejoras, resultaría en un incremento general del nivel del algoritmo 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 espacial. 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. Memoria
de Ingeniería Civil en Computación. Universidad de Chile, 2005.
[5] Bernd Lamparter, Otto Boehrer, Wolfgang Effelsberg, and Volker Turau. Adaptable forward
error 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. In
MULTIMEDIA ’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 CSDTR97 -038, Department of Computer Sciences, Purdue University, 1997.
[8] Kihong Park and Wei Wang. QoS-Sensitive Transport of Real-Time MPEG Video Using
Adaptive 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 encoded
video streams, 1995. P. Salama, N. B. Shroff, E. J. Coyle, and E. J. Delp, Error Concealment
Techniques 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 Transactions
on Image Processing, 1999.
67
[11] Fermin Uribe. Codificación y decodificación de video tolerante a fallas. Memoria de Ingenierí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: A
review, 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. in
Proc. 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 Processing
78(2), 1999.
[18] S. Winkler, A. Sharma, and D. McNally. Perceptual video quality and blockiness metrics for
multimedia streaming applications, 2001. Stefan Winkler, Animesh Sharma, David McNally: Perceptual video quality and blockiness metrics for multimedia streaming applications. in
Proceedings of the International Symposium on Wireless Personal Multimedia Communications, pp. 547–552, Aalborg, Denmark, September 9–12, 2001.
[19] A. Wrangsjö and H. Knutsson. Histogram filters for noise reduction. In Proceedings of the
SSAB Symposium on Image Analysis, March 2003.
[20] D. Wu, Y. Hou, W. Zhu, Y. Zhang, and J. Peha. Streaming video over the internet: Approaches
and 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 un
conjunto de especificaciones de comunicación entre componentes de software.
Blockiness: Efecto en imágenes normalmente debido a simplificación en compresión. Normalmente en compresión JPEG la imagen es dividida en bloques de 8x8, sobre los cuales se
realiza algún tipo de simplificación de colores, para disminuir la cantidad de información a
procesar, de manera independiente del resto de la imagen. Cuando se utiliza compresión muy
alta, los bordes de los bloques se hacen demasiado evidentes al descomprimir, produciendo
este efecto.
Bloque Virtual: Conjunto de macro-bloques de tamaño máximo 255, utilizado en la técnica
de aleatorización de pixeles. Una secuencia aleatoria de pixeles es creada a partir de este
conjunto, la cual es distribuida en distintos paquetes para minimizar el impacto producido
por pérdidas.
Codec: (Codificador/Decodificador) Tecnología capaz de codificar y decodificar una secuencia 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 cantidad
de datos a enviar, transmitiendo sólo los cambios detectados entre cuadros consecutivos de
la secuencia de video.
FFT: Fast Fourier Transform - Transformada Rápida de Fourier, es un algoritmo de gran
eficiencia para realizar el cálculo de la transformada discreta de Fourier y su inversa. Es de
gran importancia en una gran variedad de aplicaciones, en particular en procesamiento digital
de imágenes.
69
GSM: Global System for Mobile Communications, es el estándar de comunicación entre
telé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ón
de 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 de
movimiento entre cuadros consecutivos de video.
MIDP: Mobile Information Device Profile, versión de J2ME integrada en el hardware de
telé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 puede
representar 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 representar
una imagen.
RGB: Modelo de color que representa cada valor del espectro como una combinación de
rojo, verde y azul (Red, Green, Blue). Cada color puede tomar un valor entre 0 y 255, lo
cual define un espectro de 16 millones de colores. Un color se puede describir utilizando
3 bytes, uno para cada componente, aunque modelos como ARGB incluyen un valor Alpha
para 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, basado
en el intercambio de datagramas. No requiere de establecer una conexión. No posee confirmación de recepción ni control de flujo de paquetes.
Video4Linux (V4L): API para linux desarrollada para interacción con dispositivos de captura 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 una
componente de luminancia y dos componentes de crominancia. Es una representación mas
fiel de la forma de percibir colores por el ojo humano que RGB, pero más alejada del modo
de funcionamiento de los monitores.
70