Grupo ARCO - Universidad de Castilla

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
Captura y filtrado de vı́deo desde fuentes RTSP/RTP
Rafael Cabanillas Carrillo
Junio, 2008
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Departamento de Informática
PROYECTO FIN DE CARRERA
Captura y filtrado de vı́deo desde fuentes RTSP/RTP
Autor: Rafael Cabanillas Carrillo
Director: Francisco Moya Fernández
Junio, 2008
TRIBUNAL:
Presidente:
Vocal 1:
Vocal 2:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE
Fdo.:
VOCAL 1
Fdo.:
VOCAL 2
Fdo.:
SECRETARIO
Fdo.:
c Rafael Cabanillas Carrillo. Se permite la copia, distribución y/o modificación de este docu
mento bajo los términos de la licencia de documentación libre GNU, versión 1.1 o cualquier versión
posterior publicada por la Free Software Foundation, sin secciones invariantes. Puede consultar esta
licencia en http://www.gnu.org.
Este documento fue compuesto con LATEX. Imágenes generadas con OpenOffice.
Resumen
Existe un gran número de cámaras de vı́deo que transportan su señal a través de la red.
Serı́a una buena idea poder utilizar técnicas de tratamiento y filtrado de imágenes para poder
procesar este tipo de señales de vı́deo.
En este proyecto se propone un marco de trabajo que permita capturar la señal de vı́deo
procedente de la red, y en particular, de flujos RTSP/RTP, y una vez capturada poder realizar
cualquier tipo de tratamiento de imágenes.
Dentro de estas técnicas de tratamiento de imágenes, se ha puesto gran empeño en utilizar
técnicas basadas en la visión por computador que permitan diferenciar entre distintos gestos
y signos que se realicen con las manos.
Abstract
There is a wide number of video cameras which transmit their signal through the net. It
would be an interesting idea to be able to use image processing and filtering techniques in
order to process this type of video signals.
This project intends to propose a framework which allows capturing the video signal from
the net, and in particular, from RTSP/RTP streams. Once the signal has been captured it will
be possible to carry out any type of image processing.
Within these image processing techniques, a great emphasis has been placed on the use
of techniques based on computer vision that make it possible to distinguish between different
gestures and signs made with the hands.
A Mamá y Papá.
Porque dos no es igual que uno más uno
Agradecimientos
Necesitarı́a muchas lı́neas para agradecer a todas las personas que han contribuido, de
una manera u otra, para que llegue hasta aquı́; como el espacio es reducido espero que los no
incluidos lo entiendan.
A Francisco Moya por sus grandes ideas, su ayuda y su apoyo. A mis padres, porque sin
ellos nunca hubiera podido conseguirlo. A Amanda, gracias, por haber venido a abrigarme el
corazón. A Lara y Amparo por ser las mejores hermanas del mundo. A Iñaki y Manolo por
su compañı́a y amistad en este largo viaje. A mis compañeros del grupo Arco por cederme un
sitio donde realizar este proyecto. A Gorka, Jose, Adri, Matas, Raul y De la Cruz por formar
una gran familia en tierras escandinavas. A Pedro, por estar siempre cuando lo necesito.
Sin todos vosotros esto nunca hubiera sido posible. Muchas gracias a todos.
Índice general
Índice de figuras
III
Índice de cuadros
V
1. Introducción
1.1. Motivación . . . . . . .
1.2. Proyecto Hesperia . . . .
1.3. Justificación del trabajo .
1.4. Estructura del documento
.
.
.
.
1
1
2
4
5
2. Objetivos del proyecto
2.1. Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Objetivos secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Antecedentes, Estado de la Cuestión
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . .
3.2. Conceptos de los protocolos de transmisión de vı́deo .
3.2.1. RTSP . . . . . . . . . . . . . . . . . . . . . .
3.2.2. RTP . . . . . . . . . . . . . . . . . . . . . . .
3.3. Herramientas de captura de vı́deo RTSP/RTP . . . . .
3.3.1. Introducción . . . . . . . . . . . . . . . . . .
3.3.2. Librerı́as RTP . . . . . . . . . . . . . . . . . .
3.3.3. Codecs de audio y vı́deo . . . . . . . . . . . .
3.4. Visión por computador y procesamiento de imágenes .
3.4.1. Introducción . . . . . . . . . . . . . . . . . .
3.4.2. Aplicaciones . . . . . . . . . . . . . . . . . .
3.4.3. Etapas de un sistema de visión por computador
3.4.4. OpenCV . . . . . . . . . . . . . . . . . . . .
3.4.5. Bazar . . . . . . . . . . . . . . . . . . . . . .
3.4.6. Gandalf . . . . . . . . . . . . . . . . . . . . .
3.4.7. ARToolKit . . . . . . . . . . . . . . . . . . .
3.4.8. VXL . . . . . . . . . . . . . . . . . . . . . .
3.4.9. NeatVision . . . . . . . . . . . . . . . . . . .
3.4.10. Herramientas comerciales . . . . . . . . . . .
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
11
11
11
16
20
20
20
27
31
31
32
34
42
44
45
46
49
51
52
ÍNDICE GENERAL
II
4. Método de trabajo
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Fase de análisis y requisitos . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1. Análisis de Herramientas . . . . . . . . . . . . . . . . . . . . . .
4.2.2. Herramientas de tratamiento de imágenes y visión por computador
4.2.3. Descripción de cada caso de uso . . . . . . . . . . . . . . . . . .
4.3. Fase de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. Capturar la señal RTSP/RTP . . . . . . . . . . . . . . . . . . . .
4.3.2. Dividir la señal en frames . . . . . . . . . . . . . . . . . . . . .
4.3.3. Filtrado de cada frame por separado . . . . . . . . . . . . . . . .
4.3.4. Rehacer la señal . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.5. Enviar la señal . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6. Mostrar el vı́deo . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.7. Visión general del sistema . . . . . . . . . . . . . . . . . . . . .
4.4. Fase de implementación . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1. Capturar la señal RTP/RTSP . . . . . . . . . . . . . . . . . . . .
4.4.2. Dividir la señal en frames . . . . . . . . . . . . . . . . . . . . .
4.4.3. Filtrado de cada frame por separado . . . . . . . . . . . . . . . .
4.4.4. Rehacer la señal . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.5. Enviar la señal . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.6. Mostrar el vı́deo . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
57
58
60
63
65
75
75
77
79
81
82
83
84
87
88
92
98
108
109
110
5. Resultados
5.1. Introducción . . . . . . . . . . . . . . . .
5.2. Resultados del proceso de captura . . . .
5.2.1. Eficiencia al realizar la captura . .
5.2.2. Posibilidad de trabajo distribuido
5.3. Resultados del clasificador de Manos . . .
5.4. Resultados en la detección de gestos . . .
5.4.1. Eficiencia . . . . . . . . . . . . .
5.4.2. Interacción con el computador . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
111
111
112
114
118
122
122
124
6. Conclusiones y Propuestas
6.1. Conclusiones . . . . . . . . . . . . .
6.2. Lı́neas de investigación abiertas . . .
6.2.1. Detector de gestos . . . . . .
6.2.2. Detector de manos . . . . . .
6.2.3. Movimiento de cámaras Axis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
126
126
128
128
129
130
.
.
.
.
.
.
.
.
.
.
A. Manual de usuario
131
A.1. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.2. Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Bibliografı́a
134
Índice de figuras
1.1. Uso de la aplicación como cámara virtual . . . . . . . . . . . . . . . . . . .
5
2.1. Visión global de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
Uso de RTSP de los protocolos TCP y UDP . . . . . . . . . . . . . . . . . .
Proceso RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Encabezado de un paquete RTP . . . . . . . . . . . . . . . . . . . . . . . . .
Envio y recepción de paquetes con Java.net.RTP . . . . . . . . . . . . . . . .
Visión General VLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resonancia magnética (izquierda) e imagen binaria (derecha) resultado de
cambiar el valor de los pixels . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7. Vehiculo robot ”Stanley”desarrollado en la Univeridad de Stanford . . . . .
3.8. Etapas de la visión por computador . . . . . . . . . . . . . . . . . . . . . .
3.9. Funcionamiento de un filtro . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10. Ecualizado del histograma sobre una imagen: (arriba) imagen original con su
correspondiente histograma; (abajo) ecualizado del histograma. . . . . . . . .
3.11. Segmentación de una imagen en color . . . . . . . . . . . . . . . . . . . . .
3.12. Dependencias de una aplicación desarrollada con ARToolkit y otras librerı́as.
3.13. Proceso de ARToolKit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.14. Distintos tipos de formatos para representar una imagen en ARToolKit . . . .
3.15. Diagrama de bloques desarrollado dentro de NeatVision . . . . . . . . . . . .
3.16. Ejemplo de funcionamiento de WiT . . . . . . . . . . . . . . . . . . . . . .
4.1. Fases de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Vista funcional de la aplicación . . . . . . . . . . . . . . . . . . . . . . .
4.3. Diagrama de análisis del caso de uso Capturar la señal RTP/RTSP . . . .
4.4. Diagrama de análisis del caso de uso Dividir la señal en frames . . . . . .
4.5. Diagrama de análisis del caso de uso Filtrado de cada frame por separado
4.6. Diagrama de análisis del caso de uso Rehacer la señal . . . . . . . . . . .
4.7. Diagrama de análisis del caso de uso Enviar la señal . . . . . . . . . . . .
4.8. Diagrama de análisis del caso de uso Mostrar el vı́deo . . . . . . . . . . .
4.9. Captura de la señal de vı́deo a través de VLC . . . . . . . . . . . . . . .
4.10. Diagrama de secuencia del caso de uso Capturar la señal RTP/RTSP . . .
4.11. De picture t a IplImage . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12. Diagrama de secuencia del caso de uso dividir la señal en frames . . . . .
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
16
19
26
30
32
33
34
36
37
39
48
49
49
52
55
58
59
65
67
69
71
72
74
76
77
78
79
ÍNDICE DE FIGURAS
IV
4.13. Proceso del filtro de detección de gestos . . . . . . . . . . . . . . . . . . . . 80
4.14. Diagrama de secuencia del caso de uso filtrado de cada frame por separado . 80
4.15. Diagrama de secuencia del caso de uso rehacer la señal . . . . . . . . . . . . 82
4.16. Diagrama de secuencia del caso de uso enviar la señal . . . . . . . . . . . . . 83
4.17. Diagrama de secuencia del caso de uso mostrar vı́deo . . . . . . . . . . . . . 84
4.18. Diseño general de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.19. Arquitectura general de la aplicación . . . . . . . . . . . . . . . . . . . . . . 87
4.20. Plano de una picture t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.21. Etapas para realizar el clasificador de manos . . . . . . . . . . . . . . . . . . 100
4.22. Ejemplo de la muestra de imágenes negativas utilizadas . . . . . . . . . . . . 101
4.23. Ejemplo de las imágenes positivas utilizadas . . . . . . . . . . . . . . . . . . 102
4.24. Ejemplo de la muestra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.25. Ejemplo de posibles gestos . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.26. Proceso de cambios de color si no hay cambios en la imagen . . . . . . . . . 106
4.27. Proceso de gesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.28. Ejemplo de imagen patrón que representa cerrar el puño y mover el dedo ı́ndice108
5.1. Tiempo obtenidos en la medidas realizando la conversión(azul) y sin realizar
la conversión (rojo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Arquitectura distribuida: unión de flujos de vı́deo . . . . . . . . . . . . . . .
5.3. Imagen panorámica a partir de las fuentes de 3 cámaras . . . . . . . . . . . .
5.4. Arquitectura distribuida: Filtrado por separado . . . . . . . . . . . . . . . . .
5.5. Arquitectura distribuida: Filtrado por separado con la misma señal de vı́deo .
5.6. Imágenes resultado del test del clasificador . . . . . . . . . . . . . . . . . . .
5.7. Imágenes resultado del test del clasificador con falsos positivos . . . . . . . .
5.8. Gesto 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9. Gesto 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
114
115
116
117
118
121
122
123
123
6.1. Lenguaje de signos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.1. Interfaz de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.2. Interfaz de la aplicación cuando se reproduce un flujo de vı́deo . . . . . . . . 133
Índice de cuadros
3.1. Descripción de los componentes principales de IplImage . . . . . . . . . . .
44
4.1. Comparativa de las librerı́as RTP . . . . . . . . . . . . . . . . . . . . .
4.2. Comparativa de las herramientas de codificación y decodificación . . .
4.3. Comparativa de las librerı́as de visión por computador . . . . . . . . . .
4.4. Comparativa de las librerı́as de visión por computador (II) . . . . . . .
4.5. Descripción textual del caso de uso Capturar la señal RTSP/RTP . . . .
4.6. Descripción textual del caso de uso Dividir la señal en frames . . . . . .
4.7. Descripción textual del caso de uso Filtrado de cada frame por separado
4.8. Descripción textual del caso de uso Rehacer la señal . . . . . . . . . . .
4.9. Descripción textual del caso de uso Enviar la señal . . . . . . . . . . .
4.10. Descripción textual del caso de uso Mostrar el vı́deo . . . . . . . . . .
4.11. Elementos más importantes de la estructura picture t . . . . . . . . . .
4.12. Elementos más importantes de la estructura IplImage . . . . . . . . . .
4.13. Elementos más importantes de la estructura plane t . . . . . . . . . . .
4.14. Campos del array ImageData . . . . . . . . . . . . . . . . . . . . . . .
61
62
64
64
66
68
70
72
73
75
94
94
95
97
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.1. Tiempos en us de los 20 primeros frames . . . . . . . . . . . . . . . . . . . . 113
5.2. Resultados de las pruebas del clasificador . . . . . . . . . . . . . . . . . . . 120
5.3. Resultados de las pruebas realizadas al detector de gestos . . . . . . . . . . . 123
V
Listings
3.1.
3.2.
3.3.
3.4.
3.5.
4.1.
4.2.
4.3.
4.4.
4.5.
Ejemplo de envı́o de datos con ccRTP . . . . . . .
Ejemplo de recepción de datos con ccRTP . . . . .
Ejemplo de envı́o de datos con oRTP . . . . . . . .
Ejemplo de recepción de datos con oRTP . . . . .
Ejemplo de envı́o de paquetes con Java.Net.RTP . .
Descripción del Plugin . . . . . . . . . . . . . . .
Descripción de la estructura vout sys t . . . . . . .
Extraer imágenes del hilo de vı́deo . . . . . . . . .
Algoritmo de tranformación de picture t a IplImage
Algoritmo de detección de gestos . . . . . . . . . .
VI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 22
. 22
. 24
. 24
. 27
. 89
. 91
. 93
. 98
. 107
Capı́tulo 1
Introducción
1.1. Motivación
1.2. Proyecto Hesperia
1.3. Justificación del trabajo
1.4. Estructura del documento
1.1.
Motivación
En los últimos años los sistemas de vı́deo han sufrido un gran avance. Se han introducido
grandes cambios en el ámbito del vı́deo para cubrir las necesidades demandadas por los usuarios. Entre estos cambios se pueden destacar: el aumento de la calidad, los nuevos formatos o
las nuevas resoluciones. Además, debido a la mejora de las lı́neas y redes de telecomunicación
han surgido nuevas formas de visualización de vı́deo y audio como pueden ser:
Vı́deo bajo Demanda (VOD): En el que se permite al usuario el acceso a contenidos
multimedia a través de la red.
Videoconferencia: Comunicación simultánea bidireccional de audio y vı́deo entre varios usuarios.
Intercambio de vı́deos: Varios usuarios pueden compartir vı́deos a través de la red.
1
1.2. Proyecto Hesperia
2
Por otro lado, una imagen puede aportar mucha más información de la que es visible por
el ojo humano, por lo que existen cada vez mejores sistemas basados en la visión por computador aplicados a númerosos campos como pueden ser: medicina, seguridad, robótica, trafico,
etc. Se aplican técnicas complejas que permiten al usuario la extracción de información a
partir de una imágen.
Serı́a muy interesante poder unir estos dos aspectos, es decir, aplicar técnicas de tratamiento de imágenes y visión por computador sobre el elevado número de contenidos multimedia
en la red. Este proyecto viene motivado por esta idea, para poder crear un marco de trabajo
que permita el filtrado y extracción de información de los flujos de vı́deo a través de la red.
Una de las posibles aplicaciones de este proyecto es contribuir en el proyecto Hesperia [17]
que se comentará en la siguiente sección.
1.2.
Proyecto Hesperia
El proyecto Hesperia [17] tiene por objeto el desarrollo de tecnologı́as que permitan la
creación de sistemas punteros de seguridad, vı́deo vigilancia y control de operaciones de
infraestructuras y espacios públicos. El proyecto surge para dar respuesta a una demanda
sostenida a medio y largo plazo, en particular, en paı́ses de la Unión Europea y en Estados
Unidos. La gestión integrada de seguridad y control de operaciones permitirá la implantación
de sistemas rentables que, en este momento, no existen en el mercado.
Las tecnologı́as del proyecto resolverán la seguridad en dos tipos de escenarios:
Permitirán gestionar la seguridad y las operaciones de infraestructuras públicas especialmente sensibles, como subestaciones eléctricas, en gas, depósitos de agua o estaciones de telecomunicaciones.
Incrementarán de forma sustancial los niveles de seguridad de grandes espacios públicos, como aeropuertos, estaciones de ferrocarril, puertos, centros de ciudades especialmente en zonas peatonales, centros comerciales, etc.
Las caracterı́sticas a resolver más importantes en este proyecto son las siguientes:
Detectar amenazas a ciudadanos e instalaciones.
1.2. Proyecto Hesperia
3
Presentar la información del entorno de forma adecuada y fácil de entender por las
personas.
Garantizar la seguridad en el acceso a la información del sistema.
Garantizar la privacidad de las personas.
Investigar hechos e incidentes que permitan prevenir futuras amenazas.
Proporcionar información sı́ncrona de las operaciones del sistema que permita incrementar el control y mejorar futuras actuaciones.
Se utilizarán las siguientes tecnologı́as para poder resolver los aspectos mencionados anteriormente:
Tecnologı́as de Arquitectura y Sistema: El sistema propuesto es un sistema complejo y
distribuido, capaz de analizar la información audiovisual para aumentar la seguridad de
las personas y las instalaciones y de operar éstas de forma óptima y fiable.
Tecnologı́as de Visión y Audio cognitivo y de Sistemas Basados en Conocimiento: Dotarán al sistema de la capacidad de poder detectar de forma automática eventos audiovisuales diferentes de “lo normal” y la indexación automática de secuencias grabadas.
Tecnologı́as de Representación de Contenidos e Interfaz de Usuario: Incluye la presentación de los contenidos audiovisuales y del conocimiento en entornos de alto valor
visual y la interacción del usuario con la información en tiempo real.
Este proyecto está parcialmente financiado por el CDTI, organismo adscrito al Ministerio de Industria Turismo y Comercio, invirtiendo un 45 % del presupuesto , proviniendo el
restante del sector privado.
En este proyecto participan las siguientes empresas: Indra Software Labs, Unión Fenosa,
Tecnobit, SAC Control, Technosafe, Visual Tools y Brainstorm Multimedia. Por otro lado,
están también presentes las siguientes Universidades e instituciones públicas: Universidad
de Castilla La Mancha, Universidad de Granada, Universidad de Extremadura, Universidad
1.3. Justificación del trabajo
4
Politécnica de Madrid, Universidad de las Palmas, Universidad Politécnica de Valencia, Universidad Politécnica de Cataluña, Centro Superior de Investigaciones Cientı́ficas(CSIC) y el
Centro Tecnológico del Paı́s Vasco (Ikerlan).
1.3.
Justificación del trabajo
En este proyecto se pretende realizar un marco de trabajo que permita la utilización de
diferentes tipos de filtros de forma sencilla en flujos de vı́deos RTSP/RTP [28]. Es decir, realizar una aplicación que capture flujos de video RTSP/RTP que separe y filtre cada imagen por
separado, para poder posteriormente recomponer el flujo RTSP/RTP y vuelva a ser enviado a
través de la red. Este trabajo está justificado por los siguientes aspectos:
Los sistemas desarrollados para la captura y filtrado de vı́deo RTSP/RTP no son totalmente eficientes, podemos destacar los siguientes:
• OpenCV [15]: Librerı́as para visión por computador desarrolladas por Intel, estas
librerı́as ya poseen un sistema para la captura de vı́deo RTSP, pero no es muy
eficiente ya que la calidad de la captura de las imágenes es bastante pobre, la
recepción del flujo es lento por lo que dificulta el tratamiento de las imágenes en
tiempo real y no tiene soporte para el estandar MPEG-4, requisito fundamental
para las cámaras del proyecto Hesperia.
• Existen gran variedad de reproductores que capturan flujos RTSP pero no permiten el tratamiento y filtrado de la señal. Entre estos se pueden destacar Windows
Media Player, Real One Player, Winamp, etc.
Poder convertir un simple módulo de captura y filtrado de RTSP en una cámara virtual sin modificar el programa. Ya que un usuario puede recibir directamente el flujo
RTSP procedente de nuestra aplicación, que es una transformación del flujo original
que produce la cámara real.
1.4. Estructura del documento
5
Figura 1.1: Uso de la aplicación como cámara virtual
Implementación en una arquitectura escalable.
En este tipo de servicios se requiere un flujo continuo y sostenido de datos, por lo que
el transporte y el tratamiento de los datos se producen de forma simultánea.
1.4.
Estructura del documento
En el siguiente capı́tulo del documento se analizará con más precisión la descripción del
problema, ası́ como los objetivos perseguidos en este proyecto. En el capı́tulo 3, se tratarán
los trabajos relacionados con este proyecto, ası́ como el estado de la cuestión donde se propondrán las diferentes alternativas encontradas para realizar el proyecto. Posteriormente en el
capı́tulo 4 se explicará tanto el análisis como el diseño del sistema. En el capı́tulo 5, se muestran los resultados obtenidos en las distintas pruebas que se han realizado sobre el sistema.
Finalmente, en el último capı́tulo se resumirán las conclusiones obtenidas tras la realización
del proyecto, incluyendo las posibles mejoras y trabajos futuros que podrı́an realizarse.
Capı́tulo 2
Objetivos del proyecto
2.1. Objetivo principal
2.2. Objetivos secundarios
2.1.
Objetivo principal
Como se ha explicado en el capı́tulo anterior, el objetivo principal de este proyecto es el de
realizar un marco de trabajo para capturar flujos de video RTSP/RTP que permita añadir todo
tipo de filtros y mecanismos de procesamiento de imágenes. Es decir, realizar una aplicación
que permita la captura de un flujo de vı́deo procedente de una fuente RTP/RTSP, procesar y
tratar cada imagen por separado, para posteriormente rehacer el flujo RTP/RTSP, bien para
mostrarlo por pantalla o para ser enviado a otros dispositivos a través de la red.
6
2.2. Objetivos secundarios
7
Figura 2.1: Visión global de la aplicación
En la Figura 2.1 se puede ver una visión más detallada del proceso de captura que realizará la aplicación, se ha dividido este proceso en 5 etapas que se describen a continuación:
1. La aplicación recibe una señal de vı́deo RTSP.
2. La señal es capturada y fragmentada en frames.
3. Los frames son mandados al filtro.
4. Se filtran cada uno de los frames.
5. Se recompone la señal RTSP para ser visualizada o enviada a través de la red.
Por lo que a partir de un flujo de vı́deo RTSP, se obtendrá otro flujo tras procesar el primero,
que nos permitira su visualización y recoger los datos más relevantes en la etapa de filtrado.
2.2.
Objetivos secundarios
A continuación se describirán con más detalle otros objetivos que se pretenden alcanzar
en este proyecto:
Detección de caras: Desarrollar algoritmos de filtrado que nos permitan detectar cuando
en una cierta imagen existe un rostro humano. Es muy útil la realización de este tipo
2.2. Objetivos secundarios
8
de filtrados, ya que nos puede permitir almacenar en una base de datos el rostro de las
personas que han pasado por una cierta cámara, incluso se puede procesar la imagen
de la cara para compararla en tiempo real con otras imágenes faciales, lo que puede
permitir la identificación de personas.
Detección de gestos realizados con las manos: Desarrollar algoritmos de filtrado que
nos permitan primero detectar si en una imagen hay una mano y si es ası́ diferenciar si
está mano esta realizando algun gesto que tenga significado para el sistema.
Compatibilidad con MPEG-4: Es un grupo de estándares de codificación de audio y
vı́deo, ası́ como su tecnologı́a relacionada normalizada por el grupo MPEG (Moving
Picture Experts Group) de ISO/IEC. Los usos principales del estándar MPEG-4 son los
flujos de medios audiovisuales, la distribución en CD y emisión de televisión. Es un
requisito fundamental para el proyecto Hesperia ya que las cámaras desarrolladas para
este proyecto utilizan dicho estándar.
Tiempo real: La captura y filtrado de vı́deo se realizará en tiempo real por lo que este
ciclo que se ha explicado en la sección anterior no se realizará para todo el conjunto de
la señal, sino que se hará para cada frame del flujo. Es decir, antes de que el frame n de
un flujo sea capturado, el frame n-1 ha tenido que ser procesado.
Eficiencia: Al ser un sistema en tiempo real, la eficiencia es muy importante ya que se
requiere una gran velocidad en la captura y el filtrado de las imágenes para que no exista
un gran desfase respecto a la imagen original. Por lo que se va a poner un gran esfuerzo
en que el sistema sea lo más eficiente posible, ya que si este tipo de sistemas se quiere
integrar en el ámbito de la seguridad se debe poder actuar a tiempo para poder prevenir
acciones, no valdrı́a de nada que la aplicación detectara a una persona “peligrosa” si
cuando esto ocurre la persona ya ha cometido el delito.
Dar una gestión dinámica de los recursos. Por ejemplo, la memoria, ya que al ser un
sistema en tiempo real el buen tratamiento de la memoria es muy importante, porque
si se nos van almacenando los frames desperdiciarı́amos la memoria y el sistema se
colapsarı́a.
2.2. Objetivos secundarios
9
Proporcionar una sencilla instalación del software.
Proporcionar un sistema multiplataforma. El sistema debe desarrollarse de tal forma
que se permita su ejecución en distintos sistemas operativos y distinto hardware.
Proporcionar un sistema basado en estándares abiertos. Ası́ se asegura la portabilidad
entre las distintas arquitecturas y sistemas operativos.
Desarrollar el sistema utilizando tecnologı́as libres. Las partes principales de este proyecto se desarrollarán utilizando herramientas de código abierto para garantizar la continuidad del proyecto por la comunidad de usuarios y desarrolladores, el proyecto empleará tecnologı́as con licencia GPL y su distribución se realizará bajo licencia GNU
Public License.
Capı́tulo 3
Antecedentes, Estado de la Cuestión
3.1. Introducción
3.2. Conceptos de los protocolos de transmisión de vı́deo
3.2.1. RTSP
3.2.2. RTP
3.3. Herramientas de captura de vı́deo RTSP/RTP
3.3.1. Introducción
3.3.2. Librerı́as RTP
3.3.3. Codecs de audio y vı́deo
3.4. Visión por computador y procesamiento de imágenes
3.4.1. Introducción
3.4.2. Aplicaciones
3.4.3. Etapas de un sistema de visión por computador
3.4.4. OpenCV
3.4.5. Bazar
3.4.6. Gandalf
3.4.7. ARToolKit
3.4.8. VXL
3.4.9. NeatVision
3.4.10. Herramientas comerciales
10
3.1. Introducción
3.1.
11
Introducción
Como se explicó en el capı́tulo anterior, el objetivo principal de este proyecto es realizar
un framework que permita capturar un flujo de vı́deo RTSP/RTP permitiendo el tratamiento de
la señal; es decir que permita realizar cambios en el vı́deo y extraer algunos datos necesarios
de las imágenes. Para realizar estas operaciones se necesitan 2 tipos de herramientas:
Herramientas que permitan el tratamiento de flujos RTSP/RTP.
Herramientas que permitan el tratamiento de las imágenes y la extracción de datos como
pueden ser herramientas basadas en la visión por computador. Que además permitan
conseguir los objetivos de detección de caras, manos y gestos.
Hay una herramienta que ya posee ambas funcionalidades, ésta es OpenCV y este proyecto
no serı́a necesario, ya que esta herramienta permite capturar y filtrar flujos RTSP/RTP, pero
como se ha explicado en el capı́tulo 1, esta herramienta aunque es muy eficiente con respecto
al tratamiento de imágenes y la visión por computador tiene muchas deficiencias con respecto
a la captura de flujos RTP/RTSP porque la calidad de la captura de las imágenes es bastante
pobre, la recepción del flujo es lento por lo que dificulta el tratamiento de las imágenes en
tiempo real y no tiene soporte para el estándar MPEG-4.
En este capı́tulo se estudiarán estos dos conceptos ası́ como las diferentes aplicaciones
que permiten realizar estas operaciones.
3.2.
Conceptos de los protocolos de transmisión de vı́deo
3.2.1.
RTSP
El protocolo de streaming en tiempo real (RTSP) [28], cuyas siglas vienen de su definición
inglesa Real-Time Streaming Protocol, establece y controla uno o varios flujos sincronizados
tanto de vı́deo como de audio. RTSP actúa como un control de red remoto para servicios
multimedia.
Según el grupo de Internet Engineering task Force, no hay noción de conexión RTSP. En
cambio el servidor mantiene la sesión etiquetada por un identificador. En la mayorı́a de los
3.2. Conceptos de los protocolos de transmisión de vı́deo
12
casos RTSP usa TCP para datos de control del reproductor y UDP para los datos de audio y
vı́deo aunque también puede usar TCP en caso de que sea necesario. Durante la sesión RTSP,
el cliente puede abrir otras conexiones de transporte con el servidor para afrontar la conexión
RTSP. En una conexión RTSP, el servidor mantiene una sesión contı́nua. Durante la sessión
el cliente envı́a y recibe múltiples peticiones RTSP al servidor.
Figura 3.1: Uso de RTSP de los protocolos TCP y UDP
El mecanismo de transporte que suele usar RTSP es RTP [29] (Real-time Transport Protocol), que será explicado posteriormente, aunque las operaciones en RTSP no dependen del
protocolo de transporte usado.
La sintaxis y operaciones de RTSP son similares a las de HTTP por lo que una gran
parte de las funcionalidades y extensiones de HTTP pueden ser añadidos a este protocolo.
Sin embargo, posee algunas diferencias notables con HTTP:
RTSP tiene un protocolo de identificación diferente e introduce un gran número de
nuevos métodos.
Un servidor RTSP necesita mantener su estado, lo que es totalmente opuesto a HTTP
que no tiene estado.
Un cliente y un servidor RTSP pueden realizar peticiones.
RTSP está definido para usar la ISO 10646.
Los datos son transportados con un protocolo diferente.
Este protocolo soporta las siguientes operaciones:
3.2. Conceptos de los protocolos de transmisión de vı́deo
13
Recuperación de datos multimedia de un servidor. El cliente puede realizar una petición de la descripción de una transmisión vı́a HTTP o con algún otro método. Si la
transmisión es realizada vı́a multicast, la descripción contendrá la dirección multicast
y puertos que deben ser utilizados por el flujo contı́nuo. Si la transmisión se va a realizar a un único cliente vı́a unicast por razones de seguridad, el cliente proporcionará el
destino.
Invitación de un servidor de datos multimedia para realizar una conferencia: Un servidor media puede invitar a un cliente a unirse a una conferencia existente, tanto para
reproducir o grabar un conjunto de la transmisión. Esto es muy usado en aplicaciones
de enseñanza distribuida.
Añadir datos multimedia a una transmisión existente: Particularmente para transmisiones en vivo, es muy usual que el servidor pueda proporcionar a lo clientes información
adicional disponible.
Las propiedades más importantes de este protocolo son las siguientes:
Extensible: Nuevos métodos y parámetros pueden ser añadidos muy fácilmente.
Seguro: RTSP usa los mecanismos de seguridad web, tanto en nivel de transporte como
en el protocolo mismo. Todas los mecanismos de autentificación de HTTP pueden ser
usados directamente.
Independiente del transporte: Puede usar tanto un protocolo de datos (UDP) como
un protocolo de stream tal que TCP.
Capacidad de utilizar múltiples servidores: Cada flujo de transmisión media puede
ser realizado en un servidor diferente. El cliente automáticamente establecerá varias
sesiones concurrentes con los diferentes servidores. La sincronización es realizada en
el nivel de transporte.
Control de dispositivos de grabación: El protocolo puede controlar tanto dispositivos
de reporducción y grabación como dispositivos que combinen los dos modos.
3.2. Conceptos de los protocolos de transmisión de vı́deo
14
Separación del control del flujo y la inicialización de una conferencia: El control
del flujo está separado de invitar a un servidor media a una conferencia. El único requisito es que la inicialización de la conferencia se realice con un único identificador de
conferencia.
Idóneo para aplicaciones profesionales: RTSP soporta edición digital remota.
Descripción de la transmisión neutral: El protocolo no impone un tipo particular de
descripción de la transmisión. Sin embargo, la descripción debe contener al menos un
RTSP URI.
Compatible con Proxy y Firewall: Puede ser usado junto con estos dos tipos de aplicaciones.
Similar a HTTP: Como se ha explicado, RTSP utiliza algunos conceptos de HTTP
por lo que las infraestructuras existentes pueden ser reutilizadas. Esta infraestructura
incluye PICS ( Plataforma para la selección del contenido) .
Control de servidor: Si un cliente puede iniciar un flujo, también tiene que ser capaz
de poder detenerlo.
Independiente del protocolo: El cliente puede negociar el método de transporte antes
de necesitar el flujo multimedia .
Cada media stream debe estar representado por un identificador URL RTSP. Las propiedades de la transferencia son definidas en un archivo de descripción. Este archivo puede ser
obtenido por el cliente usando HTTP u otros métodos; es decir, no está necesariamente almacenado en el servidor. Se pueden distinguir varios modos de operaciones, entre los más
importantes se pueden destacar:
Unicast: El flujo es transmitido con el número de puerto elegido por el cliente.
Multicast, el servidor elige la dirección: El servidor media elige la dirección y el puerto.
Este es el caso tı́pico de transmisiones de vı́deo on demand.
3.2. Conceptos de los protocolos de transmisión de vı́deo
15
Multicast, el cliente elige la dirección: Se da cuando el servidor está participando en
una conferencia multicast y por lo tanto la dirección es proporcionada por el cliente en
la descripción de la conferencia.
El servidor necesita mantener un estado de la sesión para ser capaz de relacionar la respuesta que deber dar. Las peticiones más importantes son:
SETUP: Especifica como será transportado el flujo de datos, la petición contiene la url
del flujo multimedia y una especificación de transporte, esta especificación tı́picamente
incluye un puerto para recibir los datos (audio o vı́deo), y otro para los datos RTCP
(meta-datos). El servidor responde confirmando los parámetros escogidos y selecciona
las partes restantes, como los puertos escogidos por el servidor. Cada flujo de datos
debe ser configurado con SETUP antes de enviar una petición de PLAY.
PLAY y RECORD: Una petición de PLAY provocará que el servidor comience a enviar
datos de los flujos especificados utilizando los puertos configurados con SETUP.
PAUSE: Detiene temporalmente uno o todos los flujos, de manera que puedan ser recuperados con un PLAY posteriormente.
TEARDOWN: Detiene la entrega de datos para la URL indicada. Libera los recursos
asociados con el flujo. La sesión RTSP debe exitir en el servidor.
Otras peticiones menos importantes son: OPTIONS, ANNOUNCE, DESCRIBE, REDIRECT y SET PARAMETER.
En la figura 3.2 se puede observar el proceso que se lleva a cabo cuando un cliente hace
una petición de un flujo multimedia a un servidor. En primer lugar el cliente accede a la url
y hace una petición DESCRIBE a un servidor web para que éste le devuelva la descripción
de la presentación y el servidor devuelve información que puede incluir la versión de RTSP,
la fecha, el número de sesión, el nombre del servidor y los métodos soportados. A continuación el cliente realiza una petición de SETUP al servidor media por lo que se especifican los
protocolos aceptados para el transporte de los datos. Si todo es correcto, el cliente podrá hacer una petición de PLAY que informa al servidor que ahora es el momento de comenzar a
3.2. Conceptos de los protocolos de transmisión de vı́deo
16
enviar datos. Por lo que el servidor manda al cliente flujos de vı́deo y audio RTSP. El cliente
puede finalizar en cualquier momento la recepción del flujo mediante la petición al servidor
de TEARDOWN.
Figura 3.2: Proceso RTSP
3.2.2.
RTP
RTP [29] Protocolo de Transporte en tiempo real (Real-time Transport Protocol) define un
paquete estándar para el tranposte de vı́deo y audio a través de la red. Fue desarrollado por el
grupo de transporte de vı́deo y audio de IETF [7] renovando en 2003 la versión publicada en
1996. Es usado conjuntamente con el protoclo RTSP descrito en la sección anterior para flujos
de audio y vı́deo como por ejemplo videoconferencias. Son construidas con el protocolo UDP
(User Datagram Protocol).
Aunque RTP está principalmente diseñado para satisfacer las necesidades de las transferencias multimedia, su uso no está sólo limitado a este campo de aplicaciones.Almacenamiento
3.2. Conceptos de los protocolos de transmisión de vı́deo
17
de datos continuos, simulaciones distribuidas interactivas y control de aplicaciones son funcionalidades que se pueden encontrar también en RTP.
De manera general, este protocolo de transporte permite:
Identificar el tipo de información transmitida.
Agregar marcadores temporales y números de secuencia a la información transmitida.
Controlar la llegada correcta de los paquetes a su destino.
Los paquetes de difusión múltiple pueden utilizar RTP para enrutar conversaciones a
múltiples destinatarios.
RTP no tiene un puerto estándar TCP o UDP con el que se comunica. Las comunicaciones
UDP son realizadas por un puerto constante y el siguiente puerto libre es usado para las
comunicaciones de control (RTCP).El protocolo RTCP se basa en transmisiones periódicas
de paquetes de control que realizan todos los participantes de la sesión RTP y es un protocolo
de control para el flujo RTP, que permite transmitir información básica sobre los participantes
de la sesión y la calidad de servicio. Aunque no hay estándares asignados normalmente es
configurado para usar los puertos del rango 16384-32767. RTP puede transportar todo tipo de
datos con caracterı́sticas de tiempo real como pueden ser el audio y vı́deo. El hecho de que
RTP use un rango de puertos dinámicos hace más difı́cil el uso de firewalls. Para solucionar
este problema suele ser necesario usar un servidor STUN.
Entre los muchos tipos de usos que tiene RTP se pueden destacar los siguientes escenarios:
Conferencias de audio multicast: Es posible usar los servicios de IP multicast para comunicaciones de voz. Para poder realizar este tipo de comunicaciones se usan 2 puertos,
el primero de estos puertos para el envı́o de datos de audio y el segundo es usado para
los paquetes de control (RTCP). La dirección y los puertos son distribuidos a los participantes. Algunas veces por seguridad los datos y los paquetes de control se transportan
de forma encriptada.
Conferencias de audio y vı́deo: Si en una conferencia se usan fuentes de audio y vı́deo
estas son transmitidas por sesiones RTP separadas. Por lo que para enviar los paquetes
3.2. Conceptos de los protocolos de transmisión de vı́deo
18
RTP (datos de audio o vı́deo) y RTCP (paquetes de control) se usan 2 pares de puertos UDP y 2 direcciones multicast. No hay una relación directa entre las sesiones de
audio y vı́deo, excepto que el cliente participa en ambas a la vez y deberá usar el mismo nombre para los paquetes RTCP por lo que las sesiones podrán ser asociadas para
la sincronización de audio y vı́deo usando información de tiempo. Esto permite que
algunos de los participantes en la conferencia sólo reciban el medio que ellos elijan.
Mezclar y traducir: No todos los clientes quieren recibir los datos media en el mismo
formato, ya que en algunas ocasiones estos formatos no son apropiados. Por lo que
se pueden mezclar y traducir señales para que sean apropiadas a las necesidades del
receptor.
Codificación de capas: Las aplicaciones multimedia suelen ser capaces de ajustar la tasa
de transmisión a la capacidad de recepción o a la congestión de la red. En el contexto de
RTP sobre IP multicast se puede producir a través de varias sesiones RTP cada una en
su propio grupo multicast. Los receptores pueden adaptarse uniéndose a uno de estos
grupos multicast según su ancho de banda.
En la figura 3.3 podemos ver la estructura de los encabezados de un paquete RTP. Se puede
definir cada campo del encabezado de la siguiente forma:
V: Campo de versión V de 2 bits de longitud. Indica la versión del protocolo (V=2).
P: Campo de relleno ,1 bit. Si P es igual a 1, el paquete contiene bytes adicionales para
rellenar y finalizar el último paquete.
X: Campo de extensión X, 1 bit. Si X = 1, el encabezado está seguido de un paquete de
extensión.
CC: campo de conteo CRSC,4 bits. Contiene el número de CRSC que le sigue al encabezado.
M: campo de marcador M, 1 bit. Un perfil de aplicación define su interpretación.
Payload Type (PT): Campo de tipo de carga útil, 7 bits. Este campo identifica el tipo de
carga útil (audio, vı́deo, imagen, texto, html, etc.).
3.2. Conceptos de los protocolos de transmisión de vı́deo
19
Número de secuencia: 16 bits. Su valor inicial es aleatorio y aumenta 1 por cada paquete
enviado. Puede utilizarse para detectar paquetes perdidos.
Time Stamp: Marca de tiempo, 32 bits. Refleja el instante de muestreo del primer byte
del paquete RTP. Este instante debe obtenerse a partir de un reloj que aumenta de manera monótona y lineal, para permitir la sincronización y el cálculo de la variación de
retardo en el destino.
SSRC: 32 bits, identifica de manera única la fuente. La aplicación elige su valor de
manera aleatoria. SSRC identifica la fuente de sincronización. Este identificador se
elige de manera aleatoria con la intención de que sea único entre todas las fuentes de la
misma sesión.
CSRC: 32 bits, identifica las fuentes (SSRC) que han ayudado a obtener los datos contenidos en el paquete que contiene estos identificadores.
Figura 3.3: Encabezado de un paquete RTP
3.3. Herramientas de captura de vı́deo RTSP/RTP
3.3.
Herramientas de captura de vı́deo RTSP/RTP
3.3.1.
Introducción
20
La captura de un flujo de vı́deo RTSP/RTP puede ser realizada con dos tipos de herramientas:
Librerı́as que facilitan la implementación RTSP/RTP.
Utilizando aplicaciones de codificador-decodificador de vı́deos que soporten este tipo
de flujos. El gran problema de utilizar una librerı́a que implemente RTP, es que también
será necesario un decodificador/codificador de la señal, ya que con estas librerı́as es
posible capturar una señal RTP pero no decodificarla para que sea mostrada.
En esta sección se dará una descripción de las principales herramientas de cada uno de
estos grupos.
3.3.2.
Librerı́as RTP
Se describirán a continuación las librerı́as más importantes para el envı́o y la recepción de
datos con el protocolo de transporte RTP.
3.3.2.1.
ccRTP
ccRTP [4] es un conjunto de librerı́as de trabajo en C++ para desarrollar aplicaciones
basadas en el Protocolo de Transporte en Tiempo Real (RTP) para transporte de audio y
vı́deo.
ccRTP ha conseguido ser un eficiente y flexible marco de trabajo válido para implementar
gran parte de las aplicaciones que usen RTP. Y está implementado bajo las últimas especificaciones de RTP descritas en las secciones anteriores. ccRTP está basado en GNU Common
C++ , aunque la mayor parte de las librerı́as no son requeridas. C++ proporciona servicios
básicos como hilos, sincronización y sockets lo que hace que sea posible implementar una
solución completa para el uso de RTP. Sin embargo, a pesar de que ccRTP ofrece facilidades
3.3. Herramientas de captura de vı́deo RTSP/RTP
21
y abstracción para componentes y aplicaciones que usen RTP, esas aplicaciones generalmente requieren servicios similares para otras tareas. RTP ha sido definido como un protocolo a
nivel de aplicación y no como un tı́pico protocolo de transporte en Internet como TCP y UDP.
Por esto RTP no suele estar implementado como una capa separada de la aplicación . A consecuencia de esta caracterı́stica, las aplicaciones RTP ofrecen más adaptación a la distribución
de paquetes, procesamiento de reglas, sesiones y otros mecanismos. ccRTP proporciona un
marco de trabajo para RTP no siendo simplemente una librerı́a de manipulación RTP.
ccRTP trata exclusivamente con el protocolo de transporte de datos sobre RTP. Parámetros como la dirección IP de destino, puertos de transporte, identificador (descritos en la sección anterior), son usados por ccRTP para abrir una sesión RTP y enviar y recibir paquetes.
Las aplicaciones multimedia pueden necesitar un protocolo de señales como en nuestro caso
RTSP o SIP. Estas funciones no son provistas por ccRTP.
Algunos de los rasgos más importantes de ccRTP son los siguientes:
Soporte para unicast, multi-unicast y multicast.
Sincronización de flujos y contribución entre flujos.
Tratamiento automático de funciones RTP.
Uso de plantillas para el transporte.
Soporte de hilos.
Proporciona información sobre el estado.
Guarda estadı́sticas.
Tratamiento automático de las colisiones SSRC y detección de bucles.
Números aleatorios basados en /dev/urandom.
Consideraciones de tiempo.
El sistema para enviar y recibir paquetes RTP en ccRTP es muy simple, ya que las aplicaciones no leen directamente los datos de los sockets. Los bloques de datos que quieren ser
3.3. Herramientas de captura de vı́deo RTSP/RTP
22
enviados son puestos en la cola de transmisión y cuando se reciben bloques de datos llegan a
la cola de transmisión.
Listing 3.1: Ejemplo de envı́o de datos con ccRTP
1
RTPSession s ( I n e t H o s t A d d r e s s ( ” 1 2 7 . 0 . 0 . 1 ” ) ,8000) ;
2
c o u t << ” L o c a l SSRC i d e n t i f i e r : ” << s . getLocalSSRC ( ) << e n d l ;
3
s . a d d D e s t i n a t i o n ( ”www. e x a m p l e . com” , 9 0 0 0 ) ; / / d e s t i n o
4
s . s e t P a y l o a d F o r m a t ( s t a t i c P a y l o a d F o r m a t ( sptPCMU ) ) ;
5
s . startRunning () ;
6
/ / Envia l o s datos
7
s . putData (0 , buffer , bufferLen ) ;
En el listing 3.1 se puede observar un pequeño ejemplo de cómo enviar datos usando ccRTP.
Simplemente se inicia una sesión RTP con su dirección y puerto, posteriormente se añade el
destino y se ponen los datos a enviar en la cola de salida (s).
Listing 3.2: Ejemplo de recepción de datos con ccRTP
1
RTPSession s ( I n e t H o s t A d d r e s s ( ” 1 2 7 . 0 . 0 . 1 ” ) ,9000) ;
2
//
3
c o u t << ” L o c a l SSRC i d e n t i f i e r : ” << s . getLocalSSRC ( ) << e n d l ;
4
s . s e t P a y l o a d F o r m a t ( s t a t i c P a y l o a d F o r m a t ( sptPCMU ) ) ;
5
s . startRunning () ;
6
Initialization .
const AppDataUnit ∗ d a t a ;
7
data = s . getData (0 ) ; / / se obtienen los datos
8
i f ( d a t a ! = NULL )
9
/ / datos recibidos correctamente
En el listing 3.2 se puede apreciar un ejemplo de cómo recibir datos, al igual que al enviar
se inicia una sesión y se cogen los datos de la cola de recepción que son guardados en data.
3.3. Herramientas de captura de vı́deo RTSP/RTP
3.3.2.2.
23
oRTP
oRTP [16] es una librerı́a implementada en C para aplicaciones que usen RTP. Soporta
tanto Linux como Windows y tiene licencia GNU Lesser General Public License(LGPL). Su
utilización es muy sencilla y proporciona un organizador para recibir y enviar paquetes. Los
paquetes RTCP o paquetes de control se mandan de forma automática. Entre sus principales
carasterı́sticas se pueden destacar las siguientes:
Incluye soporte para múltiples perfiles, por ejemplo el perfil AV que es por defecto.
Organizador de envı́o y recepción de paquetes acorde con su señal de tiempo. El organizador es opcional ya que las sesiones RTP pueden ser no organizables.
Soporte de multiplexado de IO, por lo que cientos de sesiones RTP pueden ser organizadas por un único hilo.
Algoritmo jitter para adaptar al receptor al rango de reloj del emisor.
Soporte para eventos telefónicos sobre RTP.
API bien documentada.
oRTP fue implementado par ser el marco RTP para linphone , un teléfono para Linux. Ahora
oRTP es usado por otras aplicaciones como por ejemplo Hewlett Packard, OASIS SYSTEMS
y Eloquant. A continuación se mostrará un pequeño ejemplo orientativo de cómo enviar y
recibir datos usando oRTP:
3.3. Herramientas de captura de vı́deo RTSP/RTP
24
Listing 3.3: Ejemplo de envı́o de datos con oRTP
1
ortp init () ;
2
ortp scheduler init () ;
3
s e s s i o n = r t p s e s s i o n n e w ( RTP SESSION SENDONLY ) ;
4
rtp session set scheduling mode ( session ,1) ;
5
r t p s e s s i o n s e t r e m o t e a d d r ( session , ” 0 . 0 . 0 . 0 ” ,555) ;
6
rtp session set payload type ( session ,0) ;
7
s s r c = g e t e n v ( ”SSRC” ) ;
8
w h i l e ( cond )
9
10
/ / se envian los datos
rt p se ssio n se nd wi th ts ( session , buffer , i , u s e r t s ) ;
Vemos que para poder enviar datos primero se inicializa el organizador. Posteriormente
se crea una nueva sesión y se le asocia la dirección y el puerto. Finalmente se envian los datos.
Listing 3.4: Ejemplo de recepción de datos con oRTP
1
ortp init () ;
2
ortp scheduler init () ;
3
s e s s i o n = r t p s e s s i o n n e w ( RTP SESSION RECVONLY ) ;
4
rtp session set scheduling mode ( session ,1) ;
5
r t p s e s s i o n s e t l o c a l a d d r ( session , ” 0 . 0 . 0 . 0 ” ,555) ;
6
w h i l e ( cond ) {
7
while ( have more )
8
/ / se reciben los datos
9
e rr = r t p s e s s i o n r e c v w i t h t s ( session , buffer ,160 , ts
,& h a v e m o r e ) ;
Para poder recibir datos el procedimiento es muy similar al de enviar, primero se crea el
organizador y la sesión y posteriormente se reciben los datos.
3.3. Herramientas de captura de vı́deo RTSP/RTP
3.3.2.3.
25
JRTPLIB
JRTPLIB [9], es una librerı́a orientada a objetos escrita en C++ la cual permite a los
desarrolladores usar RTP. Es portable, ya que es compatible con GNU/Linux, Windows y
Solaris. Esta librerı́a tiene las siguientes funcionalidades:
Enviar y recibir datos usando RTP.
Evitar colisiones SSRC.
Organizar y transmitir RTCP.
El usuario sólo necesita cargar los datos necesarios para que sean enviados y la librerı́a se
encargará de dar al usuario acceso a los datos entrantes RTP y RTCP. La librerı́a proporciona
varias clases las cuales son de gran ayuda para crear aplicaciones RTP , pero la clase más
usada es RTPSession, la cual proporciona las funciones necesarias para enviar y recibir datos
RTP.
3.3.2.4.
UCL common multimedia library
La librerı́a multimedia UCL [18] implementa un gran número de algoritmos y protocolos
necesarios para las aplicaciones multimedia en C++, entre estos protocolos incluye RTP que
es el interesante para este proyecto. Pero no es simplemente una librerı́a para RTP como las
descritas anteriormente UCL multimedia, también incluye soporte para: Base64 encoding/decoding, árboles binarios, números aleatorios, autentificación HMAC, MD5, DES, MBus,
SAP y SDP. Es compatible con varias plataformas como: Unix systems (Solaris, Linux, Irix,
FreeBSD, MacOSX) y Windows 95/98/NT/XP. El uso del protocolo RTP es muy similar a
las aplicaciones descritas anteriormente, es necesario crear una sesión con una dirección y un
puerto. Tiene asociado una estructura de datos que es rtp packet, que es donde se contienen
los datos que van a ser enviados.
3.3.2.5.
Java.net.RTP
Java.net.RTP [8] desarrollado en la Universidad de Columbia es un paquete que proporciona una implementación independiente en Java que permite el acceso a todos los niveles de
3.3. Herramientas de captura de vı́deo RTSP/RTP
26
transporte de RTP. Con esta librerı́a se pueden incorporar fácilmente el uso de este protocolo
a las aplicaciones Java. Es una librerı́a orientada a objetos donde la clase más importante es
la Sesión que encapsula la configuración RTP y RTCP y los procedimientos necesarios. La
sesión interactúa con la red y realiza las siguientes acciones:
Procesos sı́ncronos: Enviar paquetes RTP. Para realizar está acción simplemente se invoca al método Session.SendRTPPacket().
Procesos ası́ncronos: Enviar paquetes RTCP y recibir paquetes RTP y RTCP.
Las aplicaciones tendrán 3 hilos, el primer hilo se encargará del envı́o y recepción de paquetes RTP y el segundo y tercer hilo se encargarán del envı́o y recepción de paquetes RTCP.
Realizando el envı́o de los paquetes en diferentes grupos multicast. En la figrura 3.4 se ilustra
este concepto.
Figura 3.4: Envio y recepción de paquetes con Java.net.RTP
3.3. Herramientas de captura de vı́deo RTSP/RTP
27
Listing 3.5: Ejemplo de envı́o de paquetes con Java.Net.RTP
1
/ / C o n s t r u c t a new S e s s i o n o b j e c t
2
r t p S e s s i o n = new S e s s i o n ( ” 2 3 4 . 5 . 6 . 7 ” , / / M u l t i c a s t G r o u p I P A d d r e s s
3
8000 , / / MulticastGroupPort
4
8 0 0 1 , / / RTCPGroupPort
5
8 0 5 1 , / / RTPSendFromPort
6
8 0 5 2 , / / RTCPSendFromPort
7
10000) ; / / bandwidth
8
/ / Set the session parameters
9
rtpSession . setPayloadType ( 5 ) ;
10
r t p S e s s i o n . setCName ( ” RTPUser ” ) ;
11
r t p S e s s i o n . s e t E M a i l ( ” user@ . com” ) ;
12
rtpSession . Start () ;
13
/ / Send a t e s t p a c k e t .
14
r t p S e s s i o n . SendPacket ( S t r i n g ( ” T e s t S t r i n g ” ) . getBytes ( ) ) ;
En el listing 4.3 se puede apreciar un ejemplo sencillo de como enviar un paquete en java.Net.RTP. Se observa que es un mecanismo muy simple, ya que basta con crear una sesión
utilizando la dirección multicast y los 4 puertos necesarios para enviar el paquete.
3.3.3.
Codecs de audio y vı́deo
En esta sección se describirán las aplicaciones más importantes que permiten la captura
de flujos de vı́deo y audio RTSP/RTP.
3.3.3.1.
MPEG4IP
MPEG4IP [12] es un proyecto que proporciona un sistema estándar para decodificación,
streamming, reproducción de audio,vı́deo y texto. Para conseguir esto se han utilizado numerosos paquetes de código libre y se han creado nuevos para resolver algunos problemas.
MPEG4Ip ha sido probado sobre las siguientes plataformas: Linux, FreeBSD, BSD/OS, Solaris, Mac OS X y Windows. Las caracterı́sticas más importantes de esta aplicación son las
siguientes:
3.3. Herramientas de captura de vı́deo RTSP/RTP
28
Soporta múltiples formatos de archivos: avi, mp4, limited .mov, .mpg , .wav, raw aac,
raw mp3, raw mp4v, raw .h264.
Soporta múltiples vı́deo codecs: mpeg-4 (xvid, xvid-1.0), mpeg1/2 (libmpeg3, mpeg2dec),
H.261, YUV (i420 raw).
Soporta múltiples audio codecs: aac (faad y faad2), mp3, celp, ac3 , raw PCM, AMR
NB, AMR WB.
Soporte para streaming: RTSP, SDP, RTP y mpeg2.
Soporte de grabación.
En lo relativo a la captura de flujos RTSP, que es lo que concierne a este proyecto, es un
proceso bastante sencillo ya que basta con realizar la siguiente operación:
$ gmp4player rtsp://myserver.mydomain.com/mycontent.mp4
Es decir, se puede conseguir la reproducción de flujos RTSP simplemente accediendo a su
dirección RTSP en la red.
3.3.3.2.
MPlayer
MPlayer [13] es un reproductor de vı́deo de código abierto desarrollado en C/C++ con
licencia GPL disponible para la mayorı́a de sistemas operativos. Entre otros se pueden destacar: Linux y otros sistemas Unix, Microsoft Windows y Mac OS X. Reproduce la mayorı́a
de los archivos MPEG, VOB, AVI OGG/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4,
FLI, RM, NuppelVideo, YUV4MPEG, FILM, RoQ, PVA, soportados por algunos codecs nativos, XAnim, y DLL’s Win32. Puede reproducir VideoCD, SVCD, DVD, 3ivx, DivX 3/4/5 e
incluso pelı́culas WMV. Permite salvar el contenido stream en un archivo.
Otra gran caracterı́stica de MPlayer es el amplio rango de controladores de salida soportados. Funciona con X11, Xv, DGA, OpenGL, SVGAlib, fbdev, AAlib, libcaca, DirectFB, y
también puede usar GGI y SDL (y de esta manera todos sus controladores) y algunos controladores de bajo nivel especı́ficos de algunas placas (para Matrox, 3Dfx y Radeon, Mach64,
Permidia3).
3.3. Herramientas de captura de vı́deo RTSP/RTP
29
Es un reproductor muy sólido ya que permite reproducir archivos MPEG dañados y archivos AVI incorrectos. Las caracterı́sticas más importantes de Mplayer son las siguientes:
Codificación desde una amplia variedad de formato de archivos y decodificadores.
Utiliza todos los codecs soportados por ffmpeg libavcodec.
Codificación/Multiplexación de archivos AVI entrelazados con su respectivo ı́ndice.
Creación de archivos desde flujos de audio externos.
Audio MP3 VBR.
Copia de flujos (de audio y vı́deo).
Corrección de cuadros por segundo.
Gran facilidad para añadir plugins.
Subtı́tulos.
En lo relativo a los flujos RTSP puede decodificarlos con gran facilidad. Simplemente se debe
realizar la siguiente operación:
$ mplayer rtsp://direccion rtsp
Para codificar estas acciones MPlayer utiliza la librerı́a LIVE555 Streaming Media [10], que
permite implementar el cliente RTSP. Las funcinalidades RTSP de MPlayer pueden ser usadas
en dos sentidos:
MPlayer puede ser usado para visualizar los flujos MPEG/RTP enviados por las aplicaciones usando su correspondiente archivo .sdp.
MPlayer puede también reproducir otros rtsp streams, incluido MPEG-4 audio y vı́deo.
Al ser una aplicación de código abierto se podrı́a modificar su código para poder obtener la
señal RTSP y modificarla como se pretende en este proyecto.
3.3. Herramientas de captura de vı́deo RTSP/RTP
3.3.3.3.
30
VLC
VLC [19] media player (inicialmente VideoLAN Client) es un reproductor multimedia del
proyecto VideoLAN; es un software de código libre distribuido bajo licencia GPL. Soporta
muchos códecs de audio y vı́deo, ası́ como diferentes tipos de archivos, además soporta los
formatos de DVD, VCD y varios protocolos streaming . También puede ser utilizado como
servidor en unicast o multicast, en IPv4 o IPv6 , en una red de banda ancha. Utiliza la biblioteca códec libavcodec del proyecto FFmpeg para manejar los muchos formatos que soporta, y
emplea la biblioteca de descifrado DVD libdvdcss para poder reproducir los DVDs cifrados.
Además VLC tiene soporte para Vı́deo4Linux.
Figura 3.5: Visión General VLC
Soporta también múltiples sistemas operativos como Linux, Microsoft Windows, Mac OS
X, BeOS, BSD, Pocket PC y Solaris. Para la captura de stream es una gran solución ya que:
Puede ser usado como cliente receptor de stream.
Puede ser usado como servidor para mandar stream. Ya que VLC es capaz de mandar
en forma de flujo todos los formatos que pueda reproducir.
3.4. Visión por computador y procesamiento de imágenes
31
Soporta los siguientes formatos de salida stream: RTP/UDP, RTSP, RTP/DCCP, Raw UDP,
Multicast, HTTP y MMSH. Para poder recibir un flujo RTSP en vlc basta con ejecutar:
$ vlc rtsp://www.example.org/your_stream
Pero las funcionalidades de VLC en cuanto a flujos RTSP no acaban ahı́, ya que a parte de
actuar como cliente también puede actuar de servidor, esto se puede hacer creando Vı́deo On
Demand. Primero habrá que ejecutar VLC en modo telnet con una dirección,un puerto y una
contraseña:
% vlc --ttl 12 -vvv --color -I telnet --telnet-password videolan
--rtsp-host 0.0.0.0:5554
El siguiente paso es conectarse a la vlc telnet y crear un objeto VOD ( Video On Demand):
new Test vod enabled
setup Test input my_video.mpg
Ahora ya es posible acceder a este flujo de vı́deo, simplemente habrá que conectarse al video
on demand que se ha creado y se empezará a reproducir ”my video.mpg”:
vlc rtsp://server:5554/Test
VLC también permite controlar múltiples streaming al mismo tiempo y posee un organizador que permite realizar esta tarea de forma eficiente. VLC permite añadir plugins con total
facilidad, lo que podrı́a ser de gran ayuda para este proyecto.
3.4.
Visión por computador y procesamiento de imágenes
3.4.1.
Introducción
Hace años el término visión por computador podrı́a sonar a ciencia ficción, pero en las
últimas decadas la visión de la computadoras es una realidad. Las máquinas pueden ser construidas para ver. Existen máquinas diseñadas par poder reconocer el ojo humano en escaners
de retina e incluso vehı́culos que son conducidos usando una cámara.
3.4. Visión por computador y procesamiento de imágenes
32
El principal objetivo de la visión por computador es tomar decisiones útiles y eficaces
sobre objetos reales a partir del filtrado de imágenes. Es necesario construir una descripción
del modelo para cada imagen. La visión artificial tiene como finalidad la extracción de información del mundo fı́sico a partir de imágenes, utilizando para ello un computador. Se trata de
un objetivo ambicioso y complejo que actualmente se encuentra en una etapa primitiva.
Gran parte del cerebro humano está dedicado a la visión. Allan Turing creı́a que una
computadora podrı́a conseguir la suficiente inteligencia para poder comprender escenas. Algunos de estos objetivos son todavı́a lejanos, pero, sin embargo, en los últimos años ha habido
un sorprendente crecimiento de algunas de estas lı́neas de investigación.
3.4.2.
Aplicaciones
Son numerosas las aplicaciones de la visión por computador, a continuación se describirán
las más importantes:
Biomedicina: Las aplicaciones médicas de la visión por computador son muy numerosas y podemos destacar el análisis de imágenes tomadas por rayos x, análisis de imágenes tomadas por ultrasonidos y la aplicación en los análisis de sangre.
Figura 3.6: Resonancia magnética (izquierda) e imagen binaria (derecha) resultado de cambiar el valor de los pixels
3.4. Visión por computador y procesamiento de imágenes
33
Identificación: Es un campo importante dentro de la visión por computador ya que nos
permite detección e identificación de caras, objetos, identificación de huellas dactilares,
etc.
Militares: Podemos destacar dentro de este campo la detección y seguimiento de objetos que permite detectar y seguir un objetivo militar, el análisis de imágenes para
reconocer el terreno y la aplicación en armas inteligentes.
Robótica: Para el guiado de robots industriales y la navegación de robots móviles. En
la figura 3.7 se puede observar el diseño de un vehı́culo que utiliza visión por computador y más concretamente OpenCV ganador del campeonato DARPA Urban donde
participan vehı́culos sin conductor.
Figura 3.7: Vehiculo robot ”Stanley”desarrollado en la Univeridad de Stanford
Agricultura: Análisis de imágenes de plantaciones tomadas por satélites para poder
hacer seguimiento de los cultivos y observar posibles enfermedades en las plantas.
Control de Tráfico: Con el uso de la visión por computador se pueden identificar
las matrı́culas de vehı́culos automáticamente. Otra utilidad es el control de tráfico con
semáforos automáticos que según la cantidad de vehı́culos actúan de una forma u otra.
Seguridad: Como ya se ha comentado, ésta es una de las aplicaciones actuales más
importantes de la visión por computador entre sus funciones se puede destacar: la vigilancias de edificios, detección de explosivos, etc.
3.4. Visión por computador y procesamiento de imágenes
34
Controles de Calidad: Es muy útil para realizar controles de calidad a diferentes productos. Entre otros se pueden destacar:
• Inspección de contenedores.
• Inspección de motores.
• Inspección de cristales.
• Control de calidad de alimentos.
• Inspección de soldaduras.
• Inspección de circuitos impresos.
• Inspección madera, tela, fundiciones, papel.
• Verificación de etiquetas.
3.4.3.
Etapas de un sistema de visión por computador
El ser humano captura la luz a través de los ojos, y esta información circula a través del
nervio óptico hasta el cerebro donde se procesa. Existen razones para creer que el primer paso
de este procesado consiste en encontrar elementos más simples en los que descomponer la
imagen (como segmentos y arcos). Después el cerebro interpreta la escena y por último actúa
en consecuencia. La visión por computador , en un intento de reproducir este comportamiento,
se puede definir en varias fases, que se pasarán a describir con más detalle a continuación.
Figura 3.8: Etapas de la visión por computador
3.4. Visión por computador y procesamiento de imágenes
3.4.3.1.
35
Captura de Imágenes
Esta fase, que es puramente sensorial, consiste en la adquisición de imágenes e involucra
el proceso de transformación de los estı́mulos de luz que reflejan los objetos observados y
que inciden en los foto-sensores de una cámara de vı́deo a valores digitales almacenados en
la memoria de una computadora.
Los sensores transforman la intensidad de la luz que incide en ellos a cargas eléctricas,
generando una señal eléctrica de vı́deo similar a la de una videograbadora. Finalmente la
señal de vı́deo es digitalizada por un convertidor Analógico/Digital que genera una imagen
digital interpretable por el ordenador. La imagen digital es esencialmente una transformación
bidimensional de números discretos. Normalmente la resolución de una imagen digitalizada
es superior a los 512x512 pı́xeles, donde cada pı́xel representa un valor binario, del tono de
gris o de color de la imagen.
3.4.3.2.
Preprocesamiento
En este subsistema los procesos buscan modificar y preparar los valores de los pı́xeles
de una imagen digitalizada para producir una forma que sea mucho más adecuada para las
operaciones subsecuentes. El procesamiento de bajo nivel, como también se le conoce a esta
fase, principalmente lleva acabo dos tareas:
Mejora de la imagen: Tiene como objetivo incrementar la calidad de las imágenes o enfatizar aspectos de particular interés de las imágenes. Su objetivo normalmente implica
cierto grado de juicios subjetivos acerca de la calidad de la imagen obtenida y depende
especı́ficamente de la aplicación. Las operaciones más comúnmente realizadas en esta
tarea son el ajuste de contraste y el filtrado para eliminación de ruido
Reconstrucción de imágenes: El objetivo es recuperar la “imagen original” después
de ser degradada por efectos “conocidos”, tales como la distorsión geométrica o el
desenfoque de la cámara causados por la óptica utilizada o el movimiento de los objetos.
Para realizar este preprocesamiento se utilizan filtros, donde un filtro es un mecanismo
de cambio o transformación de una señal de entrada a la que se le aplica una función,
3.4. Visión por computador y procesamiento de imágenes
36
conocida como función de transferencia, para obtener una señal de salida. En este caso
la señal de entrada serı́a la imagen.
Figura 3.9: Funcionamiento de un filtro
Se pueden realizar filtros sobre varios domininios, de los que podemos destacar:
Operaciones básicas entre pı́xeles: Son las operaciones que se realizan directamente
sobre los pı́xeles y se pueden clasificar en operaciones aritmético-lógicas y operaciones
geométricas. Dentro de las operaciones aritmético-lógicas podemos destacar:
• Conjunción: Operación lógica AND entre los bits de dos imágenes. Se usa para
borrar pı́xeles en una imagen.
• Disyunción: Operación lógica OR entre los bits de dos imágenes. Se usa para
añadir pı́xeles a una imagen.
• Negación: Inversión de los bits que forman una imagen. Se usa para obtener el
negativo de una imagen.
• Suma, resta, multiplicación y división: Realiza alguna de estas operaciones para
cambiar el valor de un pı́xel
Entre las operaciones geométricas podemos destacar la traslación, el escalado y la rotación de pı́xeles.
Operaciones sobre el histograma: Se conoce como histograma de los niveles de cuantización de la imagen, o simplemente histograma de la imagen, a un diagrama de barras
en el que cada barra tiene una altura proporcional al número de pı́xeles que hay para un
3.4. Visión por computador y procesamiento de imágenes
37
nivel de cuantización determinado. Dentro de estas operaciones se pueden destacar las
siguientes:
• Aumento y reducción de contraste: Se utiliza para ello funciones de transferencia
del histograma. Estas funciones corresponden a aplicaciones, que para cada punto del dominio sólo tiene un valor de imagen. Con una función de transferencia
que aclare los niveles claros y oscurezca los niveles oscuros, conseguirá sobre el
conjunto de la imagen un efecto visual de aumento de contraste.
• Ecualizado del histograma: Tiene por objetivo obtener un nuevo histograma, a
partir del histograma original, con una distribución uniforme de los diferentes
niveles de intensidad.
Figura 3.10: Ecualizado del histograma sobre una imagen: (arriba) imagen original con su
correspondiente histograma; (abajo) ecualizado del histograma.
3.4. Visión por computador y procesamiento de imágenes
38
Filtrado espacial:Los filtros espaciales son filtros que se realizan directamente sobre
la imagen y por tanto en el dominio del espacio. Casi todos los filtros espaciales están
basados en la convolución matemática cuya fórmula es:
Z
f (x) ∗ h(x) = f (x)h(u − x)dx
(3.1)
En teorı́a de filtros, la función f(x) corresponde a la señal de entrada y h(x) corresponde
al filtro que se desea aplicar, denominando a esta última función impulsional. Aunque
hay diferentes tipos de filtros espaciales, los más usados son:
• Filtros de suavizado: El filtrado de suavizado espacial se basa en el promediado
de los pı́xeles adyacentes al pı́xel que se evalúa.
• Filtros de obtención de contornos: El cálculo de la derivada direccional de una
función permite conocer cómo se producen los cambios en una dirección determinada. Tales cambios suelen corresponder a los contornos de los objetos presentes
en las imágenes.
Operaciones en el dominio de la frecuencia: Las representaciones en el dominio de
la frecuencia, detallan con cuánta frecuencia se repiten ciertos patrones en una imagen,
y con ello consiguen representar la información de esa imagen. Esta representación
puede ser especialmente útil, ya que teniendo la frecuencia de repetición de patrones
se pueden detectar y alterar directamente elementos presentes en las imágenes como el
ruido, los contornos o las texturas.
Operaciones morfológicas: Se puede emplear la morfologı́a para construir filtros, algunos filtros que la utilizan pueden ser:
• Eliminación de ruido: Este filtro elimina los objetos de una imagen que tienen un
tamaño menor que un elemento estructurante determinado.
• Extracción de contornos: Este filtro obtiene los contornos de una figura restándole
su interior.
• Relleno de huecos.
3.4. Visión por computador y procesamiento de imágenes
39
• Adelgazamiento: Esta operación adelgaza los elementos de una imagen hasta que
se reducen a un esqueleto interior a la misma.
3.4.3.3.
Segmentación
La segmentación es el estado inicial del proceso de reconocimiento, en donde las imágenes adquiridas son divididas sistemáticamente en regiones o segmentos significativos que
cumplen con cierto predicado. El proceso de segmentación no centra su atención en lo que
representan las regiones, sino únicamente en el proceso de dividir las imágenes en regiones
de cierta uniformidad que corresponden a partes o al objeto completo de la escena analizada.
Figura 3.11: Segmentación de una imagen en color
Existen varias propiedades que se utilizan en el proceso de segmentación, entre otras la
intensidad (los valores de gris), los parámetros de color, los bordes, la textura y el movimiento, de modo que los predicados incluyen cualquiera de estos atributos y son el mecanismo
esencial que controla la partición de las imágenes. Entre las muchas técnicas utilizadas en la
etapa de segmentación se pueden destacar las siguientes:
Segmentación basada en la umbralización: La umbralización es un proceso que permite convertir una imagen de niveles de gris o de color en una imagen binaria, de tal
forma que los objetos de interés se etiqueten con un valor distinto al de los pı́xeles
del fondo. La umbralización es una técnica de segmentación rápida, que tiene un coste
3.4. Visión por computador y procesamiento de imágenes
40
computacional bajo y que puede ser realizada en tiempo real durante la captura de la
imagen usando un ordenador personal de propósito general. Dentro de la umbralización
se puede destacar la umbralización fija y la generalizada.
Técnicas basadas en la detección de contornos: La segmentación basada en detección
de contornos agrupa un gran número de técnicas que usan la información proporcionada por las fronteras de los objetos que aparecen en una imagen. Puesto que se desea
encontrar los objetos individuales presentes en una imagen, parece lógico que si se encuentran las fronteras de tales objetos con el fondo se podrı́a segmentar los objetos de
la escena general. Dentro de este tipo de técnica, hay 2 métodos que se pueden usar
principalmente para detectar contornos:
• Segmentación basada en las componentes conexas: Se puede plantear detectar los
objetos presentes en una imagen sin más que encontrar las componentes conexas
de la misma. Esto ocurre cuando los objetos tienen un color uniforme y distinto
del fondo, lo que permite asegurar que los contornos del objeto se corresponden
con los bordes de la componente conexa.
• Detección de contornos con filtros de gradiente:
Técnicas basadas en el crecimiento de regiones: Determinan zonas dentro de una
imagen basándose en criterios de similaridad y proximidad entre los pı́xeles de la misma. En estas técnicas la homogeneidad (o falta de homogeneidad) entre regiones adyacentes es el criterio utilizado para unir (o dividir) regiones de la imagen. Dicha homogeneidad se puede definir a partir de criterios como: el nivel de gris medio, el color, la
forma, etc. El resultado de la segmentación es una partición de la imagen en regiones
homogéneas. En general, las técnicas basadas en regiones trabajan mejor en imágenes
con ruido. Dentro de estas técnicas se pueden destacar:
• Unión de regiones: Este procedimiento agrupa pı́xeles de la imagen formando regiones de similares caracterı́sticas. Inicialmente se elige una colección de pı́xeles
de manera aleatoria que actúan como “semillas” para comenzar el crecimiento. A
estos puntos de la imagen se les agrega los adyacentes cuando tienen valores que
3.4. Visión por computador y procesamiento de imágenes
41
cumplen algún criterio de homogeneidad con los puntos semilla. Si ocurre esto,
pertenecen a la misma región y pasan a tener los mismos valores que los puntos
semilla.
• División de regiones: Es un proceso en cierta forma opuesto al de unión de regiones. Se parte una única región que representa a toda la imagen, y si dicha región
no satisface el criterio de homogeneidad establecido, la región inicial se divide,
de manera secuencial, en subregiones de las que se estudia su homogeneidad.
Otros enfoques para la segmentación: Existen numerosas técnicas de segmentación,
aparte de las explicadas hasta ahora, que no pueden ser englobadas estrictamente en
ninguno de los tres grupos descritos:
• Segmentación basada en el color.
• Segmentación basada en la textura.
• Segmentación basada en el movimiento.
3.4.3.4.
Reconocimiento de Caracterı́sticas y clasificación
Donde se identifican las caracterı́sticas que distinguen a cada uno de los objetos que pueden aparecer en una imagen. El resultado de esta etapa es la descripción de los objetos por un
vector de sus caracterı́sticas inherentes.
Las caracterı́sticas que normalmente se utilizan para la descripción de los objetos tienen
que ver con la forma, ya sea interna o externa de las regiones, su color, textura o incluso su
estructura geométrica. Además, la descripción debe ser invariante a la posición, orientación,
e idealmente con respecto a la escala de los objetos. Finalmente se determina a qué grupo o
clase dentro de un grupo de posibles clases pertenece cada uno de los objetos que aparecen en
una imagen. En esencia se utilizan algunas o todas las caracterı́sticas de los objetos que se han
extraı́do de las imágenes para tomar una decisión correcta acerca de a qué categorı́a pertenece
el objeto. Los métodos de clasificación más empleados son los estadı́sticos y sintácticos. Los
estadı́sticos agrupan los objetos mediante discriminantes. Comúnmente se utilizan métodos
paramétricos como la Regla de Bayes y no paramétricos como los Discriminantes lineales,
3.4. Visión por computador y procesamiento de imágenes
42
Distancia mı́nima, Aproximación lineal a pedazos (k vecinos más cercanos), etc. Los modelos sintácticos realizan un reconocimiento utilizando gramáticas de formas. Cada patrón se
describe totalmente en términos de un conjunto de sub-patrones, los cuales, a su vez, pueden
describirse con patrones más simples. Se establece una analogı́a jerarquizada (como un árbol)
entre la estructura de los patrones y la sintaxis de un lenguaje, cuya gramática y métodos de
análisis sintáctico se utilizan para clasificar los objetos.
3.4.4.
OpenCV
OpenCV [15] (Open Source Computer Vision) es un conjunto de librerı́as de funciones
de programación cuyo uso principal es la visión por computador en tiempo real. Son librerı́as
de código abierto desarrolladas en C/C++ originalmente por Intel. Es multiplataforma y se
puede ejecutar bajo Max OS X, Windows y Linux. Está diseñado para poder ser usado conjuntamente con la librerı́a de Procesamiento de Imágenes de Intel (IPL), pero ha extendido
posteriormente sus funcionalidades aunque sigue compartiendo el mismo formato de imágenes (IplImage) con IPL.
3.4.4.1.
Recursos
Entre las principales recursos de OpenCV se pueden destacar las siguientes:
Manipulación de imágenes como por ejemplo conversión de formatos y copia de imágenes.
Entrada de vı́deo con cámaras y salida en ficheros de imágenes.
Manipulación de vectores, matrices y funciones de álgebra lineal.
Estructuras de datos dinámicas como listas, colas y árboles.
Procesamiento básico de imágenes entre los que se pueden destacar: filtros, detección
de bordes, conversiones de color, operaciones basadas en morfologı́as, histogramas y
pirámide de imágenes.
3.4. Visión por computador y procesamiento de imágenes
43
Análisis estructural como por ejemplo : análisis de contornos, transformación de distancias, tranformada de Hough, aproximaciones poligonales.
Calibración de cámaras.
Reconocimiento de objetos.
Etiquetado de imágenes.
3.4.4.2.
Módulos
Dentro de las librerı́as de OpenCV podemos encontrar 4 módulos bien diferenciados:
Módulo cv: Contiene las funciones principales.
Módulo cvaux: Funciones auxiliares de OpenCV, también contiene funciones que se
encuentran en grado de experimentación.
Módulo cxcore: Contiene las estructuras de datos y el soporte para funciones de álgebra
lineal.
Módulo highgui: Contiene las funciones para programación de interfaces gráficas de
usuario.
3.4.4.3.
Tipos de datos en OpenCV
Opencv proporciona tipos de datos básicos para su utilización. A continuación se describirán brevemente los tipos de datos más importantes:
IplImage: Es el tipo de datos básico en Opencv. Con este tipo de datos se representan
todos los tipos de imágenes con sus componentes y caracterı́sticas. En el cuadro 3.1
podemos ver los componentes principales que forman esta estructura.
3.4. Visión por computador y procesamiento de imágenes
Componente
Descripción
widthStep
número de bytes entre puntos de la misma columna y filas sucesivas
nChannels
indica el número de canales de color de la imagen
TimageData
puntero a la primera columna de los datos de la imagen
width y height
anchura y altura de la imagen expresadas en pı́xeles
depth
información sobre el tipo de valor de los pı́xeles
44
Cuadro 3.1: Descripción de los componentes principales de IplImage
CvArr: Es lo que se denomina un “metatype”, es decir, un tipo de dato ficticio que se
utiliza de forma genérica a la hora de describir los parámetros de las funciones. CvArr*
se utiliza para indicar que la función acepta “arrays” de más de un tipo.
CvMat: Estructura empleada para operar con imágenes. Es una estructura de datos que
se caracteriza porque aparte de almacenar los elementos como cualquier matriz, ofrece
la posibilidad de acceder a información adicional que puede resultar de gran utilidad.
CvScalar: La estructura CvScalar es simplemente un vector de cuatro elementos, es
muy útil a la hora de acceder a los pı́xeles de una imagen, sobre todo si es una imagen
en color.
CvPoint: Define las coordenadas de un punto usando números enteros.
CvPoint2D32f: Define las coordenadas de un punto usando punto flotante.
CvSize: Estructura utilizada para definir las dimensiones de un rectángulo en pı́xeles.
3.4.5.
Bazar
Bazar [3] es una librerı́a para la visión por computador basada en detección de puntos. En
particular puede detectar y registrar conocidos objetos planos e imágenes. Contiene también
un potente sistema geométrico y fotométrico de calibración de cámaras.
3.4. Visión por computador y procesamiento de imágenes
3.4.5.1.
45
Módulos
Bazar está compuesto por varios módulos implementados en 2 librerı́as:
Starter: Contiene las estructuras básicas y herramientas matemáticas.
Garfeild: Sus funcionalidades principales son detección de puntos clave y unión de puntos. Está diseñado para realizar una rápida detección de objetos planos en una imagen.
Realizando esto en un proceso de 2 fases: fase de entrenamiento y fase on-line. Durante
la fase de entrenamiento, rasgos de puntos en un modelo de imagen. Y durante la segunda fase se llama a los reconocedores de objetos planos y se establecen las uniones
con el modelo de puntos establecido en la fase anterior.
3.4.6.
Gandalf
Gandalf [5] es una librerı́a para la visión por computador y algoritmos numéricos escrita
en C, lo cual permite desarrollar aplicaciones con una gran portabilidad y que tengan una gran
eficiencia cuando se ejecutan. Gandalf ha sido utilizado para desarrollar “mokey” software
para reconocimiento de movimientos desarrollado por Imagineer Systems Ltd en Amsterdam,
“mokey” realiza seguimiento de objetos en movimiento en una secuencia de imágenes.
Las caracterı́sticas más destacadas del diseño de Gandalf son las siguientes:
Uso eficiente de la memoria utilizando estructuras de datos dinamicamente reconfigurables.
Enfasis en el soporte de algoritmos numéricos.
Representación de imágenes muy flexible y eficiente.
Conjunto de operaciones de matrices como trasposición e inversión.
Explota las ventajas computacionales y de compilación de los lenguajes C y C++. Se reducen los niveles de abstracción, lo que es apropiado para objetos simples como imágenes y matrices.
3.4. Visión por computador y procesamiento de imágenes
3.4.6.1.
46
Módulos
Gandalf está dividido en los siguientes paquetes o módulos:
Common: Contiene herramientas de propósito general que son usadas por otros módulos. Incluye rutinas para almacenamiento en memoria, listas, funciones numéricas y
manipulación de arrays.
Linear algebra: Incluye funciones de manipulación de vectores y matrices.
Image: Contiene funciones de bajo nivel para creación y manipulación de imágenes que
soportan escala de grises, imágenes en color RGB con o sin canales alpha y con varios
niveles de profundidad para pı́xeles. Soporta también vectores en 2 y 3 dimensiones de
imágenes.
Vision: Contiene funciones muy útiles de visión por computador como pueden ser detección de arcos, lı́neas y esquinas.
3.4.7.
ARToolKit
ARToolKit [2] es una librerı́a software para desarrollar aplicaciones de realidad aumentada. Éstas son aplicaciones que añaden información virtual a la información existente en
el mundo real. Una de las dificultades de este tipo de aplicaciones es conocer exactamente
dónde está mirando en cada momento el usuario. Para resolver este tipo de problemas ARToolKit usa algoritmos de visión por computador que calculan la posición real de la cámara
y la orientación relativa de las marcas en tiempo real.
Algunas de las principales caracterı́sticas de esta herramienta son:
Está implementado en C y C++.
Es multiplataforma ya que soporta Linux, Windows, Mac OS X y SGI.
Una librerı́a multiplataforma de vı́deo que incluye: múltiples tipos de entradas, múltiples formatos soportados (RGB/YUV420P, YUV), seguimiento de múltiples cámaras e
interfaz de usuario.
3.4. Visión por computador y procesamiento de imágenes
47
Detección plana en tiempo real.
Funciones de calibrado sencillas y eficientes.
Librerı́a sencilla pra graficos basada en GLUT.
Renderizado de gran velocidad basado en OpenGL.
Soporte de 3 dimensiones para VRML.
Soporta otros lenguajes como Java y Matlab.
Completo conjunto de ejemplos y documentación.
Código abierto con licencia GPL para uso no comercial.
3.4.7.1.
Módulos
ARToolKit es un software ToolKit que aporta funciones predefinidas que pueden ser necesarias para desarrollar un aplicación de realidad aumentada. Pero sus partes pueden ser usadas
también por separado para realizar otro tipo de tareas de visión por computador. ARToolKit
depende de otras librerı́as lo que podemos ilustrar en la figura 3.12
3.4. Visión por computador y procesamiento de imágenes
48
Figura 3.12: Dependencias de una aplicación desarrollada con ARToolkit y otras librerı́as.
ARToolKit está compuesta por cuatro módulos que se describen a continuación:
Módulo AR: funciones de seguimiento de marcas, calibración y colección de parámetros.
Módulo Vı́deo: Colección de funciones para captura de entradas de vı́deo frames. Contiene las funciones de la plataforma de captura SDK.
Módulo Gsub: Colección de funciones gráficas basadas en OpenGL y librerı́as GLUT.
Módulo Gsub Lite: Funciones que reemplazan las de la librerı́a anterior por una colección más eficiente de funciones gráficas independientes de otras librerı́as.
En la figura 3.13, se muestra el paso por los diferentes módulos de una aplicación.
3.4. Visión por computador y procesamiento de imágenes
49
Figura 3.13: Proceso de ARToolKit.
3.4.7.2.
Tipos de datos en ArToolKit
ARToolKit manipula diferentes tipos de variables. Internamente utiliza variables globales.
Se usan diferentes tipos de formatos de imágenes entre sus diferentes módulos. En la Figura 3.14 se muestran todos los diferentes formatos soportados. Algunos formatos sólo están
disponibles para algunas plataformas y algunos Hardware.
Figura 3.14: Distintos tipos de formatos para representar una imagen en ARToolKit
3.4.8.
VXL
VXL [20] (Vision-something-Libraries) es una colección de C++ librerı́as diseñadas para
el desarrollo e implementación de aplicaciones con visión por computador. Está diseñado por
TargerJr y el ”Image Understanding Environment”(IUE) con la intención de crear un sistema
rápido y eficiente. Está escrito en ANSI/ISO C++ y está diseñado para ser portable sobre
múltiples plataformas.
3.4. Visión por computador y procesamiento de imágenes
3.4.8.1.
50
Módulos
VXl contiene los siguientes módulos:
Vnl: Contiene funciones numéricas y algoritmos. Las caracterı́sticas más destacadas de
esta librerı́a son las siguientes:
• Operaciones esenciales de matrices y vectores.
• Clases especializadas para matrices y vectores con propiedades particulares. Por
ejemplo la clase vnl diagonal matrix da una eficiente matriz diagonal con tamaño
fijo.
• Descomposición de matrices.
• Polinomios reales.
• Optimización.
• Estandarización para funciones comunes y constantes.
Vil: Contiene las funciones para cargar, salvar y manipular imágenes con soporte para
gran variedad de formatos incluyendo soporte para imágenes de gran tamaño. El principal objetivo es dar acceso flexible a todas las imágenes en 2 dimensiones. Permite:
• Fácil acceso a todo tipo de imágenes.
• Rápido acceso para las imágenes en disco con una penalización de un 10 % de
velocidad con respecto a la imágenes en memoria.
• Carga de gran velocidad para subconjuntos de una imagen. No es necesario cargar
toda la imagen para acceder sólo a una porción.
• Eficiente control de memoria.
Vgl: Funciones para primitivas de geometrı́a con representación para 2 y 3 dimensiones.
Se pueden destacar:
• Representación de puntos, lı́neas y planos.
• Figuras cónicas en 2 dimensiones.
3.4. Visión por computador y procesamiento de imágenes
51
• Rectángulos.
• Polı́gonos.
• Vectores dirigidos.
Vsl, vbl y vul: Conjunto de plataformas independientes y funcionales.
3.4.9.
NeatVision
NeatVision [14] es un un entorno de desarrollo software para análisis de imágenes para
Java. Fue desarrollado por el grupo Vision Systems Group, de la universidad de Dublı́n.
Los desarrolladores pueden crear soluciones a sus problemas de visión por computador
usando la librerı́a de algoritmos predefinidos. Estos algoritmos los cuales están presentes en
forma de componentes gráficos pueden ser combinados en el espacio de trabajo para crear
soluciones más complejas. Contiene alrededor de 290 algoritmos de manipulación y procesado de imágenes. Esta herramienta actualmente permite utilizar su código en aplicaciones
propias del usuario de Java. Una de las condiciones que pone NeatVision a sus usuarios, es
que las clases modificadas o mejoradas que vienen en el paquete, sean notificadas y enviadas
a NeatVision para su examinación y posible incorporación a las nuevas versiones de NeatVision. Una de la grandes ventajas de NeatVision, como puede observarse en la figura 3.15, es
que utiliza iconos para identificar sus filtros y algoritmos. Por lo que va formando diagramas
para representar las etapas que se han ido siguiendo.
3.4. Visión por computador y procesamiento de imágenes
52
Figura 3.15: Diagrama de bloques desarrollado dentro de NeatVision
3.4.10.
Herramientas comerciales
A parte de las herramientas descritas anteriormente, existen muchas otras herramientas
comerciales que no son de código abierto. Estas herramientas, aunque destacan por su gran
potencia, tienen el inconveniente de tener un precio elevado y que tienen un ciclo de actualizaciones relativamente largo. Muchos de ellos están ligados a alguna plataforma en particular, lo
que impide el uso de la aplicación bajo otros sistemas. Todos ellos proporcionan funciones de
procesamiento y análisis de imágenes, reconocimiento de patrones, estadı́sticas y calibración
de la cámara a través del propio entorno o a través de librerı́as de funciones, desarrollados en
la mayorı́a de las ocasiones en C/C++. Sin embargo,no suelen poner a disposición del usuario su código fuente, y en la mayorı́a de los casos hablamos de librerı́as monolı́ticas, muy
pesadas y no demasiado rápidas. A continuación se dará una breve descripción de las más
importantes.
3.4.10.1.
Aphelion
El sistema Aphelion [1] es un software de desarrollo muy completo para el procesamiento y análisis de imágenes, disponible para Windows, y que propone funciones de tratamiento
3.4. Visión por computador y procesamiento de imágenes
53
muy avanzadas. Es utilizado por investigadores y desarrolladores de aplicaciones en los campos médico, militar, de ciencia de materiales, geologı́a, control de calidad e inspección. Sus
principales ventajas son que es un entorno de desarrollo, procesamiento de imágenes, librerı́as
de reconocimiento de objetos y un tutorial de uso muy sencillo. Posee los últimos avances en
morfologı́a matemática y representación simbólica, ası́ como eficientes herramientas de análisis, reconocimiento de patrones y clasificación.
Uno de los principales módulos de Aphelion es “Recognition Toolkit”, desarrollado por
la compañı́a Recognition Science, Inc., que pone a disposición de los usuarios , un conjunto muy completo de herramientas de reconocimiento y clasificación de objetos basadas en
el análisis por componentes principales y el cálculo de atributos. Los clasificadores pueden
ser generados automáticamente liberando al usuario de tener que especificar complejas reglas
para el reconocimiento de objetos. Suministra herramientas de reconocimiento de formas capaces de procesar datos continuos, discretos e incluso simbólicos. El módulo contiene una
serie de operadores para la clasificación, el aprendizaje, la evaluación de atributos, la codificación y extracción de nubes de puntos (clusters). El núcleo del módulo incluye el conjunto
de clasificadores, los operadores de aprendizaje, una rutina de reagrupamiento (clustering)
estándar, operadores de evaluación y análisis de atributos, ası́ como funciones utilitarias para
el pre-procesamiento y constitución de bases de aprendizaje y la generación de clasificadores
definidos por el usuario.
Otros módulos importantes de Aphelion son:
Módulo 3D: Procesar y visualizar imágenes tridimensionales que poseen la misma funcionalidad y capacidad de cálculo que sus equivalentes en 2D.
Módulo Color: Permite al usuario manipular imágenes a color gracias a herramientas
avanzadas de segmentación y de extracción de objetos, en función de la intensidad de
sus colores. Incluye cuatro métodos semiautomáticos de segmentación: umbral de color
interactivo, distancia entre colores, crecimiento de regiones y partición morfológica.
Módulo Image Montage: Permite reconstruir una imagen a partir de imágenes más
pequeñas.
3.4. Visión por computador y procesamiento de imágenes
54
Módulo Kriging:Este módulo permite eliminar el ruido generado durante la adquisición de una imagen empleando técnicas de filtrado basadas en el análisis ”Kriging la
2
geoestadı́stica.
Módulo Multifocus: Generación de una imagen nı́tida a partir de múltiples imágenes
desenfocadas.
3.4.10.2.
MIL
Matrox Imaging Library [11] (MIL) es un kit de desarrollo para la visión por computador,
tratamiento de imágenes médicas y análisis de imágenes. Contiene ActiveMil que es una
colección de controles ActiveX para manejar captura, transferencia, análisis y visualización
de imágenes. Incluye también otra aplicación llamada Matrox Inspector, una herramienta
interactiva para Microsoft Windows y una interfaz para utilidades de cámaras.
3.4.10.3.
HIPS
HIPS [6] es un conjunto de módulos para el procesamiento de imágenes que contiene un
entorno de herramientas muy potente. Fue desarrollado en la Universidad de Nueva York y
ahora es mantenido por uno de sus desarrolladores originales Michael Landy. Está desarrollado para UNIX. Está dividido de forma modular y flexible, contiene una gran documentación.
Con HIPS se pueden tratar secuencias de imágenes de la misma manera que si fueran simples
frames. Ha sido desarrollado para transformaciones simples de imágenes , filtros, convoluciones, procesos de transformación como por ejemplo el de Fourier, detección de arcos, comprensión digital de imágenes y computación de estadı́sticas de imágenes. Cualquier proceso
de tratamiento de imágenes puede ser realizado eficientemente.
Una de las ventajas de HIPS es que cada imagen que se guarda en el sistema contiene su
propio historial de transformaciones que han sido aplicadas a esa imagen. Se incluyen también
un conjunto de subrutinas las cuales permiten tratar con una secuencia estándar de imágenes y
una gran librerı́a con funciones para el procesamiento de imágenes. Es compatible con varios
tipos de máquinas entre ellos:Vax y Microvax, Sun, Apollo, Masscomp, NCR Tower, Iris e
IBM AT. La diferencia respecto a las otras aplicaciones comerciales descritas, es que HIPS es
3.4. Visión por computador y procesamiento de imágenes
55
la única que pone a disposición del cliente su código fuente.
3.4.10.4.
Wit
Wit [21] es una herramienta gráfica, desarrollada por la empresa Canadiense Coreco Imagin Inc., la cual se basa en desarrollos de subgrafos para hacer un procesamiento de imágenes.
Con esta herramienta se pueden hacer procesos de visión pasiva y visión activa, ya que genera
código que puede ser utilizado en C/C++. Al igual que con NeatVision, las aplicaciones son
realizadas con diagramas de bloques, como se puede ver en la figura 3.16, donde podemos
apreciar el diseño de un proceso de captura en wit por bloques en el que se adquiere un frame
y después se muestra.
Figura 3.16: Ejemplo de funcionamiento de WiT
Algunas de las caracterı́sticas y utilidades más importantes de Wit son:
Librerı́as para el procesamiento de imágenes: Contiene alrededor de 400 funciones que
pueden ser usadas en Wit o directamente desde aplicaciones C/C++.
Una interfaz flexible para cámaras que es compatible para gran variedad de dispositivos.
Motor Wit: Un potente motor de ejecución con componentes DDL y ActiveX.
Ejecución en multiples CPUs: Pueden utilizar múltiples CPU dentro de un PC.
Generador de código C: Puede convertir aplicaciones gráficas en código C.
Capı́tulo 4
Método de trabajo
4.1. Introducción
4.2. Fase de análisis y requisitos
4.2.1. Análisis de Herramientas
4.2.2. Herramientas de tratamiento de imágenes y visión por computador
4.2.3. Descripción de cada caso de uso
4.3. Fase de diseño
4.3.1. Capturar la señal RTP/RTSP
4.3.2. Dividir la señal en frames
4.3.3. Filtrado de cada frame por separado
4.3.4. Rehacer la señal
4.3.5. Enviar la señal
4.3.6. Mostrar el vı́deo
4.3.7. Visión general del sistema
4.4. Fase de implementación
4.4.1. Capturar la señal RTP/RTSP
4.4.2. Dividir la señal en frames
4.4.3. Filtrado de cada frame por separado
4.4.4. Rehacer la señal
4.4.5. Enviar la señal
4.4.6. Mostrar el vı́deo
56
4.1. Introducción
4.1.
57
Introducción
Para el desarrollo de este proyecto se ha seguido un método de desarrollo en cascada
ascendente y descendente. Es decir, se permite la posibilidad de, cuando se han encontrado
problemas en una fase, volver a la fase anterior para realizar cambios. El proceso de desarrollo
ha utilizado también algunas partes del proceso unificado como por ejemplo la notación UML
y que ha sido dirigido por casos de uso.
Para implementar este proceso se han seguido las siguientes fases:
Fase de análisis y requisitos: Se estudiarán los requisitos y objetivos generales del sistema propuestos en el capı́tulo 2 para proceder a la construcción de la vista funcional del
sistema, que será implementada en forma de diagrama de casos de uso. Según esta vista
del sistema, se tomarán decisiones respecto a los medios y herramientas que se van a
utilizar después de analizar cada una de las herramientas comentadas en el capı́tulo 3.
Fase de diseño: Se realizará el diseño general del sistema y para mayor claridad y
concisión se aportarán diagramas en notación UML para que sea más claro y conciso
como por ejemplo diagramas de clases y de secuencias.
Fase de implementación: Se explicarán las partes más importantes de la codificación de
la aplicación, ası́ como los principales problemas que se han encontrado y cómo se han
solventado.
Fase de pruebas: Se desarrollarán diferentes pruebas para comprobar la robustez del
sistema y verificar que cumple con los objetivos requeridos. Los resultados de estas
pruebas serán explicados en el capı́tulo 5.
4.2. Fase de análisis y requisitos
58
Figura 4.1: Fases de desarrollo
4.2.
Fase de análisis y requisitos
Como se explicó en el capı́tulo 2, el requisito principal de este proyecto es realizar un
marco de trabajo para capturar flujos de vı́deo RTSP/RTP que permita añadir todo tipo de
filtros y mecanismos de procesamiento de imágenes. Es decir, realizar una aplicación que
permita la captura de un flujo de vı́deo procedente de una fuente RTSP/RTP, procesar y tratar
cada imagen por separado para posteriormente rehacer el flujo RTSP/RTP, bien para mostrarlo
por pantalla o para ser enviado a otros dispositivos a través de la red. Analizando este requisito
principal vemos que puede ser dividido en las siguientes funcionalidades de la aplicación o
casos de uso:
Capturar la señal RTSP/RTP.
Dividir la señal en frames.
Filtrado de cada frame por separado.
Rehacer la señal.
4.2. Fase de análisis y requisitos
59
Enviar la señal.
Mostrar la señal.
Con estas funcionalidades se ha obtenido el diagrama de casos de uso o vista funcional de la
aplicación de la figura 4.2
Figura 4.2: Vista funcional de la aplicación
A continuación se han ordenado los casos de uso según el orden en que se irán implementando. Para establecer este orden, se ha realizado una priorización de casos de uso atendiendo
4.2. Fase de análisis y requisitos
60
a criterios de dependencia entre ellos.
1. Capturar la señal RTSP/RTP.
2. Dividir la señal en frames.
3. Rehacer la señal.
4. Enviar la señal.
5. Mostrar la señal.
6. Filtrado de cada frame por separado.
4.2.1.
Análisis de Herramientas
Se ha analizado cada una de las herramientas propuestas en el capı́tulo anterior estudiando
en qué grado cumplen cada uno de los requisitos del proyecto y se han escogido las que
satisfacen en mayor medida estos requerimientos. A continuación veremos la elección en
cada uno de los dos campos de herramientas: Herramientas que permitan el tratamiento de
flujos RTSP/RTP y herramientas que permitan el tratamiento de las imágenes y la extracción
de datos como pueden ser herramientas basadas en la visión por computador.
4.2.1.1.
Herramientas RTSP/RTP
Con respecto a estas herramientas los requisitos que se deben cumplir son los siguientes:
Compatibilidad con varios sistemas operativos.
Permitir la captura flujos RTSP/RTP.
Permitir enviar flujos RTSP/RTP.
Compatibilidad con MPEG-4.
Posibilidad de decodificar flujos de vı́deo.
Posibilidad de codificar flujos de vı́deo.
4.2. Fase de análisis y requisitos
61
Código abierto que permita su modificación.
Eficiencia para poder ser utilizado en tiempo real.
En la tabla 4.1 se pueden observar la comparativa de las diferentes librerı́as RTP estudiadas en el capı́tulo anterior. Según estos datos se puede apreciar la similitud de estas librerı́as.
A pesar de que son librerı́as muy robustas, no se adaptan totalmente a la utilidad que
se requiere en este proyecto. El principal problema de este tipo de herramientas es que no
son herramientas de codificación y decodificación de vı́deo. Por lo que con ellas se podrı́an
enviar y recibir paquetes RTP, pero no se podrı́a codificar y decodificar esta señal en forma de
vı́deo. Por este aspecto se ha decidido que no es conveniente utilizar para este proyecto estas
librerı́as, ya que la complejidad de implementar la codificación y decodificación de vı́deo es
muy grande.
PP
PP
PP
Herramienta
ccRTP
oRTP
JRTPLIB
UCL
Java.net.RTP
Multiplataforma
Sı́
Sı́
Sı́
Sı́
Sı́
Captura de paquetes RTP
Sı́
Sı́
Sı́
Sı́
Sı́
Enviar paquetes RTP
Sı́
Sı́
Sı́
Sı́
Sı́
Compatibilidad con MPEG-4
Indirecto
Indirecto
Indirecto
Indirecto
Indirecto
Codificar flujos de vı́deo
No
No
NO
No
No
Decodificar flujos de vı́deo
No
No
No
No
No
Codigo abierto
Sı́
Sı́
Sı́
No
No
Lenguaje de Programación
C++
C
C++
C++
Java
Facilidad de uso
Buena
Buena
Mala
Mala
Buena
Flujos RTSP
Indirecto
Indirecto
Indirecto
Indirecto
Indirecto
Requisito
PP
P
PP
P
P
Cuadro 4.1: Comparativa de las librerı́as RTP
El siguiente tipo de herramientas que se estudiaron en el capı́tulo anterior son los codificadores y decodificadores de audio y vı́deo. En la tabla 4.2 podemos observar una comparativa
de estas 3 aplicaciones.
4.2. Fase de análisis y requisitos
PP
PP
PP Herramienta
PP
PP
PP
Requisito
P
62
MPEG4IP
MPlayer
VLC
Multiplataforma
Sı́
Sı́
Sı́
Compatibilidad con MPEG-4
Sı́
Sı́
Sı́
Codificar flujos de vı́deo
Sı́
Sı́
Sı́
Decodificar flujos de vı́deo
Sı́
Sı́
Sı́
Codigo abierto
Sı́
Sı́
Sı́
Lenguaje de Programación
C++
C
C++
Facilidad de su código
Mala
Mala
Buena
Capturar flujos RTSP
Sı́
Sı́
Sı́
Enviar flujos RTSP
No
No
Sı́
Cuadro 4.2: Comparativa de las herramientas de codificación y decodificación
Este tipo de herramientas tienen varias ventajas con respecto a las librerı́as de captura
RTP:
La captura de los flujos RTSP se realiza de forma directa.
Pueden codificar y decodificar flujos de vı́deo. Lo que nos permitirá abstraernos de
estos aspectos.
Estas ventajas nos han hecho inclinarnos por usar una de estas herramientas. Como se
puede observar en la tabla 4.2, las 3 herramientas estudiadas son muy similares, pero para
realizar este proyecto se ha optado por usar VLC por los siguientes motivos:
Es la única que permite enviar flujos RTSP. Esto es un requisito fundamental para este
proyecto, ya que como se explicó en capı́tulos anteriores es necesario que la aplicación
pueda actuar de cámara virtual; es decir, pueda modificar la señal y volver a enviarla a
la red.
Tiene un código fácilmente entendible y una buena documentación.
Se pueden insertar nuevas funcionalidades fácilmente en forma de plugin.
4.2. Fase de análisis y requisitos
63
Por lo tanto se utilizará VLC, que nos va a permitir capturar flujos de vı́deo RTSP/RTP.
Estudiando las diferentes aplicaciones de esta herramienta se observa que no posee una forma
directa para poder modificar los flujos de vı́deo.
4.2.2.
Herramientas de tratamiento de imágenes y visión por computador
Estas herramientas nos permitirán modificar las imágenes. Los requerimientos que se exigen son:
Que se pueda utilizar bajo varias plataformas.
Sean de código abierto.
Que permita el procesamiento de imágenes.
Posea funciones para el análisis de estructuras.
Tenga funciones para reconocimiento de objetos.
Tenga un número suficiente de filtros.
Sea una librerı́a muy amplia.
La comparativa según estos requerimientos de las librerı́as descritas en el capı́tulo anterior se
pueden ver en las tablas 4.3 y 4.4.
4.2. Fase de análisis y requisitos
PP
PP
PP
Herramienta
64
OpenCV
Bazar
Gandalf
ARToolKit
VXL
Multiplataforma
Sı́
Sı́
Sı́
Sı́
Sı́
Procesamiento de imágenes
Sı́
No
Sı́
No
Sı́
Análisis de estructuras
Sı́
No
Sı́
Sı́
Sı́
Reconocimiento de objetos
Sı́
Sı́
Sı́
Sı́
No
Amplitud de la librerı́a
Muy Grande
Pequeña
Normal
Grande
Normal
Cantidad de filtros
Muy Grande
Normal
Grande
Normal
Normal
Codigo abierto
Sı́
Sı́
Sı́
Si
Si
Lenguaje de Programación
C++
C
C++
C++,Java y Matlab
C++
Facilidad de uso
Buena
Normal
Normal
Mala
Buena
Requisito
PP
P
PP
P
P
Cuadro 4.3: Comparativa de las librerı́as de visión por computador
PP
PP
PP
Herramienta
Neatvision
Aphelion
MIL
HIPS
Wit
Multiplataforma
Sı́
No
No
No
No
Procesamiento de imágenes
Sı́
Sı́
Sı́
Sı́
Sı́
Análisis de estructuras
No
Sı́
Sı́
Sı́
Sı́
Reconocimiento de objetos
Indirecto
Sı́
No
No
No
Amplitud de la librerı́a
Normal
Grande
Normal
Normal
Grande
Cantidad de filtros
Normal
Grande
Normal
Normal
Grande
Codigo abierto
Sı́
No
Sı́
No
No
Lenguaje de Programación
Java
C
Java
C++
C++
Facilidad de uso
Muy Buena
Buena
Mala
Buena
Muy Buena
Requisito
PP
P
PP
P
P
Cuadro 4.4: Comparativa de las librerı́as de visión por computador (II)
Tras la comparativa realizada en las tablas anteriores se ha elegido OpenCV como herramienta ya que es la que más se adecúa a los requisitos del proyecto. Es una librerı́a muy amplia
4.2. Fase de análisis y requisitos
65
a la que cada vez se le están añadiendo más funcionalidades y como el objetivo del proyecto
es realizar un marco de trabajo que nos permita añadir filtros fácilmente se ha pensado que al
ser esta herramienta la más utilizada, el aprovechamiento del proyecto será mayor.Un usuario
podrá crear filtros en OpenCV y los podrá utilizar con señales de vı́deo RTSP estándar.
4.2.3.
Descripción de cada caso de uso
En esta sección se dará una primera aproximación de cada caso de uso, intentando dar una
descripción textual, usando tablas de descripción y proponiendo posibles diagramas de análisis que permitan entender mejor el caso de uso que se va a implementar en fases siguientes.
4.2.3.1.
Capturar la señal RTP/RTSP
Figura 4.3: Diagrama de análisis del caso de uso Capturar la señal RTP/RTSP
Como se ha decidido que la herramienta que se va a utilizar es VLC, se tendrá que buscar
un mecanismo que permita a la aplicación coger la señal de vı́deo de VLC; es decir, VLC
capturará una señal RTSP y nuestra aplicación cogerá ese vı́deo de VLC. En la figura 4.3
4.2. Fase de análisis y requisitos
66
se pueden ver los componentes implicados en este caso de uso. Se tendrán 2 actores, uno el
usuario que interactúa con la interfaz para establecer la dirección rtsp de la que quiere recibir
la señal de vı́deo, y el otro la propia señal de vı́deo que al ser un elemento externo es tratada
como actor. También están implicados los controladores de VLC y el controlador propio de
la aplicación (controller). En la tabla 4.6 se da una descripción con más detalle de la forma
de interactuar que tienen los distintos componentes.
Nombre: Capturar la señal RTP/RTSP
Abstracto: No
Postcondiciones El flujo RTSP es capturado
Rango 1
Flujo Normal:
1.El usuario introduce la dirección RTSP.
2.La interfaz manda esta dirección a VLC.
3.El controlador de VLC conecta con la dirección RTSP.
4.VLC recibe el flujo RTSP.
5.VLC manda el flujo al controlador de la aplicación.
Descripción:
Un usuario introduce la dirección RTSP sobre la que se quiere realizar la captura,
la interfaz del programa mandará esta aplicación a VLC que se conectará con
la dirección y comenzará a recibir el flujo; mientras esto ocurre el controlador
de nuestra aplicación se comunicará con VLC para recibir el flujo de vı́deo.
Cuadro 4.5: Descripción textual del caso de uso Capturar la señal RTSP/RTP
4.2. Fase de análisis y requisitos
4.2.3.2.
67
Dividir la señal en frames
Figura 4.4: Diagrama de análisis del caso de uso Dividir la señal en frames
Para poder hacer filtrado de imágenes se necesita tratar por separado cada uno de los frames de los que está compuesta la señal de vı́deo. Como se ha decidido que se va a utilizar
OpenCV, estos frames deberán estar en el formato adecuado que permitan a OpenCV acceder
a estas imágenes, por lo que como las imágenes son capturadas por VLC será necesario transformar estas imágenes a un formato válido para OpenCV. En la figura 4.4 se pueden observar
una primera aproximación de los diferentes componentes que realizarán estas acciones. Se
utilizarán 2 controladores, uno de ellos el controlador de la aplicación y el otro un controlador encargado de realizar la conversión del formato de la imagen. Podemos ver que también
participan las 2 entidades de los dos formatos de imágenes. En la tabla 4.6 se describen con
más detalles las distintas funcionalidades de este caso de uso y de cada componente.
4.2. Fase de análisis y requisitos
68
Nombre: Dividir la señal en frames
Abstracto: No
Postcondiciones Podemos tratar la señal en imágenes independientes
Rango 2
Flujo Normal:
1.El controlador (controller) de la aplicación recibe la señal RTSP.
2.Se van extayendo de la señal imágenes en formato de VLC.
3.Se manda la imágen en formato VLC al conversor.
4.El conversor convierte la imágen VLC a una imágen formato OpenCV.
Descripción:
Este caso de uso es el proceso desde que el controlador recibe la señal y va cogiendo
de esta señal cada imagen por separado, estas imágenes estarán en formato VLC por lo
que para que puedan ser tratadas con OpenCV serán mandadas a un conversor que transformará
este tipo de imágenes al formato de OpenCV.
Cuadro 4.6: Descripción textual del caso de uso Dividir la señal en frames
4.2. Fase de análisis y requisitos
4.2.3.3.
69
Filtrado de cada frame por separado
Figura 4.5: Diagrama de análisis del caso de uso Filtrado de cada frame por separado
Cuando se obtenga la imagen en el formato adecuado a OpenCV se le podrán aplicar
cualquier filtro implementado en esta herramienta. En la figura 4.5 encontramos los diferentes componentes que participarán a simple vista en este caso de uso: Dos controladores, el
conversor y el filtro, y una entidad la imagen que será filtrada ya en formato OpenCV. En la
tabla 4.7 se explicará con más detalle este caso de uso.
4.2. Fase de análisis y requisitos
70
Nombre: Filtrado de cada frame por separado
Abstracto: No
Postcondiciones Se obtendrá una nueva imagen en formato OpenCV
Rango 3
Flujo Normal:
1.El conversor manda la imagen OpenCV al filtro.
2.El filtro realiza una operación sobre la imagen.
3.Se realiza cierta transformación en la imagen.
4.La imagen se manda al conversor.
Descripción:
En este caso de uso, el filtro OpenCV recibirá una imágen en el formato adecuado.
Este filtro realizaŕa una operación sobre la imágen como puede ser por ejemplo
detectar si en la imagen hay una cara y se hará una transformación en la imagen
Por ejemplo, marcar con un cı́rculo la cara encontrada y se devolverá esta nueva
imagen al conversor en el mismo formato que la imagen original
Cuadro 4.7: Descripción textual del caso de uso Filtrado de cada frame por separado
En este proyecto se implementará un filtro que permita la detección de gestos realizados
con las manos. Para ello se deben seguir los siguientes pasos:
1. Detectar en la imagen de entrada la mano.
2. Obetener las coordenadas de la posición de la mano.
3. Reconocer el gesto que realiza la mano.
4.2. Fase de análisis y requisitos
4.2.3.4.
71
Rehacer la señal
Figura 4.6: Diagrama de análisis del caso de uso Rehacer la señal
Cuando la imagen ha sido filtrada por un filtro de OpenCV es necesario devolver la imagen
al formato VLC. Para ello se vuelve a utilizar el conversor que hará el proceso contrario que
realizó en el caso de uso de “División en frames” , es decir, a partir de una imagen en formato
OpenCV devolverá una imagen en formato VLC con las mismas caracterı́sticas. En la figura
4.6 se pueden apreciar los componentes implicados en este caso de uso: El controlador de la
aplicación, el controlador de VLC y las entidades de las respectivas imágenes de entrada y de
salida del conversor. En la tabla 4.8 se dará una descripción más detallada del caso de uso.
4.2. Fase de análisis y requisitos
72
Nombre: Rehacer la señal
Abstracto: No
Postcondiciones Se obtendrá una señal RTSP
Rango 4
Flujo Normal:
1.El conversor recibe una imagen OpenCV.
2.El conversor convierte la imagen OpenCV a formato VLC.
3.El conversor manda la imagen al controlador.
4.El controlador manda la imagen al controlador de VLC.
Descripción:
En este caso de uso se obtendrá una nueva señal RTSP a partir de imágenes en formato
OpenCV; para ello el conversor convertirá la imagen al formato VLC y se las irá mandando
al controlador que se las mandará a VLC.
Cuadro 4.8: Descripción textual del caso de uso Rehacer la señal
4.2.3.5.
Enviar la señal
Figura 4.7: Diagrama de análisis del caso de uso Enviar la señal
4.2. Fase de análisis y requisitos
73
Una vez que la imagen está en un formato VLC, si el usuario lo desea podrá volver a
crear el flujo RTSP para que sea enviado a través de la red a otros usuarios (cámara virtual).
A simple vista, en este proceso participarán los componentes del diagrama de análisis de la
figura 4.7, dos actores, uno de ellos representa el nuevo flujo RTSP y el otro representa al
propio usuario. También intervendrá el controlador de VLC. En la siguiente tabla podemos
ver una descripción más detallada del caso de uso.
Nombre: Enviar la señal
Abstracto: No
Postcondiciones Se enviará la señal RTSP a través de la red
Rango 4
Flujo Normal:
1.El controlador VLC recibirá la nueva señal.
2.Si el usuario a marcado esta opción.
3.Se creará un nuevo flujo RTSP que será enviado por la red.
Descripción:
En este caso de uso se volverá a crear una señal RTSP que será enviada por la red
y otros usuarios podrán recibir esta señal que es una modificación de la original.
Cuadro 4.9: Descripción textual del caso de uso Enviar la señal
4.2. Fase de análisis y requisitos
4.2.3.6.
74
Mostrar el vı́deo
Figura 4.8: Diagrama de análisis del caso de uso Mostrar el vı́deo
El usuario puede tener la opción de en vez de rehacer el flujo para ser enviado por la
red, como veı́amos en el caso de uso anterior, simplemente visualizar el vı́deo en su propia
máquina. En este caso de uso intervendrán : El controlador VLC que mandará a visualizar las
imágenes, una interfaz por la que se visualizará el vı́deo y un actor, el propio usuario.
4.3. Fase de diseño
75
Nombre: Mostrar el vı́deo
Abstracto: No
Postcondiciones
Rango 4
Flujo Normal:
1.El controlador VLC recibirá la nueva señal.
2.Si el usuario a marcado esta opción.
3. VLC reproducirá la señal
Descripción:
El usuario podrá ver la reproducción del vı́deo que se ha modificado
Cuadro 4.10: Descripción textual del caso de uso Mostrar el vı́deo
4.3.
Fase de diseño
En esta sección se dará una visión más detallada del sistema. Se empezará diseñando cada
caso de uso analizado en la sección anterior, hasta llegar a un diseño general del sistema. Para
poder dar una descripción más detallada se utilizarán diagramas de secuencia y de clases.
4.3.1.
Capturar la señal RTSP/RTP
Como se ha visto en la fase de análisis este caso de uso tiene la función de recibir una
señal de vı́deo RTSP para posteriormente pasar a su procesamiento. Esto se hará a través del
programa VLC que ya permite la captura de vı́deos RTSP y otro tipos de streamming. Es
decir, VLC capturará y decodificará la señal, y la aplicación de nuestro proyecto tendrá que
obtener esta señal de VLC para su procesamiento. En la figura 4.9 se puede apreciar una
ilustración de esta idea.
4.3. Fase de diseño
76
Figura 4.9: Captura de la señal de vı́deo a través de VLC
Para poder realizar esta operación se ha estudiado con gran profundidad el código de
VLC, para ver como maneja este programa las señales de vı́deo y se ha decidido que la mejor
opción es realizar un plugin dentro del propio VLC que capture la señal de salida de VLC.
Existen varios tipos de plugins que se pueden crear para VLC:
vı́deo output: Este tipo permite obtener la salida de vı́deo de VLC.
vı́deo filter: Este tipo permite obtener la salida de vı́deo y modificarla.
audio output: Este tipo permite obtener la salida de audio de VLC.
audio filter: Este tipo permite obtener la salida de audio y modificarla.
El tipo de plugin más adecuado para este proyecto es el vı́deo filter, ya que se quiere
capturar la señal pero no sólo para visualizarla, sino que se quiere tratar con filtros. Por lo que
se realizará un plugin de tipo vı́deo filter que obtenga la señal de reproducción de vı́deo de
VLC.
En la figura 4.10 se muestra el diagrama de secuencia de este caso de uso, dando ya
más detalles que los que se daban en la fase de análisis. El controlador de la aplicación que
mostrábamos en la fase anterior ha sido sustituido por la clase plugin que realizará las funciones que se habı́an impuesto a ese controlador (controller). Como se observa en el diagrama,
el usuario introducirá la dirección rtsp que desea filtrar por medio de una interfaz de usuario,
esta interfaz ejecutará vlc pasándole la dirección rtsp. VLC creará un hilo de salida de vı́deo
e inicializará el plugin pasándole este hilo.
4.3. Fase de diseño
77
Figura 4.10: Diagrama de secuencia del caso de uso Capturar la señal RTP/RTSP
De este modo, se consigue capturar una señal de vı́deo abstrayéndonos del modo en el
que se realiza la conexión rtsp y del modo en el que se decodifica el vı́deo, ya que se utilizan
funciones del propio VLC que permiten realizar estas acciones.
4.3.2.
Dividir la señal en frames
Este proceso consistirá en a partir de la señal de vı́deo out, que ha obtenido el plugin en el
caso de uso anterior, ir extrayendo de ésta cada frame por separado. Como ya se ha explicado,
este proceso es en tiempo real por lo que la eficiencia en esta fase es muy importante. El
principal problema al que nos enfrentamos es que los frames extraı́dos de la señal de vı́deo
VLC no son compatibles con OpenCV, por lo que no pueden ser tratados por esta librerı́a.
Por lo que se llevará a cabo un proceso de conversión de cada una de las imágenes VLC en
imágenes de OpenCV. Estos dos formatos de imágenes son estructuras de datos totalmente
independientes:
4.3. Fase de diseño
78
picture t: Estructura que representa una imagen o frame en VLC.
IplImage: Estructura que representa una imagen o frame en OpenCV.
Este proceso se debe llevar a cabo de forma que se mantengan exactamente las mismas
caracterı́sticas que tiene la imagen en el formato original en la nueva imagen. Y el encargado
de realizarlo será la clase conversor.
Figura 4.11: De picture t a IplImage
En la figura 4.12 se muestra el diagrama de diseño de este caso de uso. En este diagrama
se puede apreciar con más detalle el diseño de este caso de uso. El plugin obtiene un picture t
del hilo de vı́deo. Y va pasando cada una de estas picture t al Conversor que crea una nueva
imagen IplImagen con los datos de picture t.
4.3. Fase de diseño
79
Figura 4.12: Diagrama de secuencia del caso de uso dividir la señal en frames
4.3.3.
Filtrado de cada frame por separado
Este caso de uso como ya se explicó, consiste en filtrar la imagen, es decir, filtrar la
IplImage. Al tener la imagen en este formato se podrá aplicar cualquier filtro realizado en
OpenCV. Como se fue dicho en secciones anteriores, el objetivo es implementar un filtro que
permita reconocer una mano humana en una imagen y posteriormente analizar esta mano para
comprobar si realiza alguno de los gestos que tiene almacenados para detectar.
4.3. Fase de diseño
80
Figura 4.13: Proceso del filtro de detección de gestos
A parte de realizar el filtro de reconocimiento de gestos se usarán los clasificadores de
OpenCV para realizar un filtro de detección de caras.
Figura 4.14: Diagrama de secuencia del caso de uso filtrado de cada frame por separado
En la figura 4.14 se puede ver el diagrama de secuencia de este caso de uso. El conversor
4.3. Fase de diseño
81
llamará a la función filtrar del Filtro y éste realizará una de las operaciones del filtrado que
haya escogido el usuario en la interfaz. Se modificará la IplImage y será devuelta al conversor.
4.3.4.
Rehacer la señal
Una vez concluido el proceso de filtrado se obtendrá una nueva IplImage con cierta modificación de la inicial. Para que vlc pueda procesar esta imagen para que sea visualizada,
habrá que seguir el proceso contrario que se siguió en el otro caso de uso; es decir, a partir de
esta IplImage se obtendrá una picture t que sea reconocible para VLC sin perder ninguna de
las caracterı́sticas de la imagen.
4.3. Fase de diseño
82
Figura 4.15: Diagrama de secuencia del caso de uso rehacer la señal
Como se puede apreciar en la figura 4.15 el conversor llamará a una función propia que
al pasarle una IplImage nos cree una nueva picture t. En la fase de implementación se explicará cómo se lleva a cabo este proceso de conversión de imágenes. Posteriormente la picture t
es devuelta al plugin para que proceda con el siguiente caso de uso.
4.3.5.
Enviar la señal
Tras procesar la señal, ésta puede ser mandada a otros equipos a través de la red. Para
ello habrá que devolverle el control a VLC y crear un flujo RTSP. Al igual que en la fase de
4.3. Fase de diseño
83
captura nos abstraemos de cómo VLC realiza estas acciones, lo único que debemos hacer es
hacerlo a través de las funciones propias de VLC.
Figura 4.16: Diagrama de secuencia del caso de uso enviar la señal
En la figura 4.16 se presenta el diagrama de secuencia de este caso de uso que nos da un
diseño más detallado de lo que se va a implementar dentro de la funcionalidad de enviar la
señal. Simplemente se le dirá a VLC que envı́e esta nueva imagen que se ha creado. Y VLC
irá mandando un flujo con las imágenes procesadas que le irá dando el plugin.
4.3.6.
Mostrar el vı́deo
Finalmente se le dice a VLC que reproduzca la señal y el usuario podrá ver el vı́deo en una
interfaz. Como se ve en el diagrama de secuencia 4.17, el Plugin irá dando a VLC una a una
las picture t que debe ir reproduciendo. Nuestra aplicación se abstraerá de la forma en que
4.3. Fase de diseño
84
VLC reproduce esta señal, simplemente le decimos cual es la picture t que debe reproducir
con display(picture t).
Figura 4.17: Diagrama de secuencia del caso de uso mostrar vı́deo
4.3.7.
Visión general del sistema
Después de diseñar cada caso de uso por separado, damos ahora un visión general del
sistema diseñado. Para ello, en la figura 4.18 se muestra el diagrama de clases definidas para
esta aplicación. A este diagrama se le podrán añadir atributos y operaciones, si es necesario,
en la fase de implementación, pero los cambios no variarán la estructura general de este
diseño.
4.3. Fase de diseño
85
Figura 4.18: Diseño general de la aplicación
En este diagrama se puede ver que el diseño se centra principalmente en las siguientes
clases:
Plugin: Es la clase principal de la aplicación que será añadido a la lista de módulos
(plugines) de VLC y se encargará de obtener el hilo de vı́deo de VLC y comunicarse
con el Conversor para realizar las actividades explicadas en los diagramas de secuencia.
Interfaz: Interfaz de usuario en la que el usuario introduce la dirección que desea reproducir y el tipo de filtro que quiere utilizar. Esta será la encargada de ejecutar VLC
pasándole la dirección rtsp.
4.3. Fase de diseño
86
VLCcontroller: Clase de control de vlc que proporcionará al Plugin el hilo de salida
de vı́deo (vou t thread t).
vout thread t: Hilo de salida de vı́deo proporcionado por VLC.
picture t: Imagen de vlc que es extraı́da del hilo vout thread t. Ya que este hilo va
mandando imágenes.
Conversor: Clase encargada de realizar las conversiones de formatos. Tiene una relación de asociación bidireccional con el Plugin, ya que se realiza una comunicación
entre ambas clases y una asociación unidireccional con las clases picture t e IplImage
ya que son utilizadas por esta clase.
Filtro: Es la clase encargada de filtrar las IplImage por lo que tiene una relación de
asociación con esta clase. Al método constructor se le pasará un entero (tipo) que indicará qué tipo de filtro se va a inicializar.
IplImage: Es una clase propia de OpenCV y se relaciona tanto con el Filtro como con
el Conversor.
En la figura 4.19, vemos la arquitectura general de la aplicación, ası́ como el proceso que
llevan a cabo transformando la señal rtsp. Estas fases son:
1. VLC recibe la señal rtsp.
2. VLC decodifica la señal rtsp y crea el hilo de vı́deo vout thread t que es pasado al
Plugin.
3. El plugin va cogiendo una a una las picture t del hilo de vı́deo y se las pasa al Conversor.
4. El Conversor convierte las picture t en IplImage y las manda al filtro.
5. El filtro modifica las IplImage y las devuelve al Conversor.
6. El Conversor convierte las IplImage en picture t y las manda al Plugin.
7. Se van mandando las imágenes a VLC.
4.4. Fase de implementación
87
8. Se recompone la señal rtsp.
Figura 4.19: Arquitectura general de la aplicación
Este proceso es un proceso continuo ya que las imágenes van llegando en tiempo real.
4.4.
Fase de implementación
Después de tener un diseño claro de la aplicación, gracias a los diagramas de secuencia y
de clases, pasamos a la fase de codificación. La implementación del sistema se ha realizado
utilizando el lenguaje de programación C++, debido a su fácil portabilidad entre distintas
plataformas, eficiencia y rapidez. Además, tanto OpenCV como VLC, están implementados
en este lenguaje y como se van a utilizar estas tecnologı́as, es necesario usar también C++.
Además al ser una aplicación en tiempo real, el tiempo y la eficiencia son muy importantes y
este lenguaje tiene muy en cuenta estos aspectos.
4.4. Fase de implementación
88
En esta sección se explicará cómo se han implementado las partes más importantes de los
casos de uso diseñados anteriormente y se explicarán los algoritmos más importantes que se
han implementado.
4.4.1.
Capturar la señal RTP/RTSP
En esta sección se presentarán los detalles más importantes respecto a la implementación
de este caso de uso. Se ha dividido en 3 grandes aspectos importantes:
VLC recibe una señal rtsp.
Añadir Plugin a los módulos de VLC.
Vout thread t.
Estructura vout sys t.
4.4.1.1.
VLC recibe una señal rtsp
Para poder hacer que VLC reciba un flujo de vı́deo rtsp de una determinada dirección rtsp,
obtenemos la dirección que el usuario desea filtrar por medio de la interfaz. Tras obtener esta
dirección la interfaz ejecutará VLC del siguiente modo:
$ vlc rtsp://www.example.org/your_stream
Ejecutando el Plugin dentro de VLC. En la siguiente sección vemos como realizar esta acción.
4.4.1.2.
Añadir Plugin a los módulos de VLC
Para poder acceder a la señal de vı́deo procesada por VLC, debemos añadir nuestra aplicación a su lista de módulos. En particular será añadido a la categorı́a de módulos de vı́deo y
a la subcategorı́a VIDEO VFILTER (para filtros de vı́deo). Para poder realizar esta acción, se
utlizará la sintaxis de descripción de módulos de VLC. Con ella se definirá el nombre que se
quiere dar al módulo, una breve descripción textual de la función del módulo, los parámetros
de entrada que recibe y las categorı́as. A continuación vemos como hemos agregado nuestro
4.4. Fase de implementación
89
Plugin:
Listing 4.1: Descripción del Plugin
1
vlc module begin () ;
2
set shortname (
( ” capture ” ) ) ;
3
s e t c a t e g o r y ( CAT VIDEO ) ;
4
s e t s u b c a t e g o r y ( SUBCAT VIDEO VFILTER ) ;
5
set description (
( ” C a p t u r e and c o n v e r t v d e o t o OpenCV f o r m a t
”) ) ;
6
set capability ( ” v deo
f i l t e r ” , 10 ) ;
7
a d d i n t e g e r ( ” image−w i d t h ” , −1, NULL,
WIDTH TEXT ,
WIDTH LONGTEXT, VLC TRUE ) ;
8
a d d i n t e g e r ( ” image−h e i g h t ” , −1, NULL,
HEIGHT TEXT ,
HEIGHT LONGTEXT , VLC TRUE ) ;
9
10
s e t c a l l b a c k s ( Create , Destroy ) ;
vlc module end ( ) ;
El Plugin ha sido registrado en la lista de módulos con el nombre de capture. Se le han
asignado dos enteros image-width e image-height de parámetros de entrada para que se pueda
introducir las dimensiones de salida de la imagen.
Con la llamada a set callbacks decimos a qué funciones queremos que se llamen automáticamente al crear y destruir el plugin, en este caso llamamos a Create y a Destroy. Este módulo
será basicamente un bucle infinito que realizará las siguientes funciones:
1. Encontrar la siguiente imagen (picture t) que se va a visualizar.
2. Filtrar la imagen.
3. Esperar hasta el tiempo de emisión de esa imagen.
4. Emitir la imagen.
5. Manejar eventos.
4.4. Fase de implementación
4.4.1.3.
90
Hilo de salida de vı́deo: Vout thread t
Cuando se crea un módulo en vlc, al método de creación se le pasa como parámetro
automáticamente un objeto vlc de la clase vlc object t. De este objeto se extraerá el hilo de
salida de vı́deo (Vout thread t). Esta estructura es muy compleja y básicamente maneja una
cola de imágenes(picture t) y subimágenes guardando toda la información necesaria. Por lo
que de este hilo de vı́deo se irán extrayendo las imágenes que van a ser filtradas.
A este hilo de vı́deo, se le deben asignar las funciones que deben ser llamadas periódicamente en nuestro caso se le han asignado las siguientes:
pf init: Esta función es llamada una vez tras crear el plugin y en nuestro caso le hemos
asignado nuestra función Init. Automáticamente se le pasará como parámetro a esta
función el vout thread t. Esta función sólo será llamada una vez por cada ejecución del
programa y servirá para inicializar las estructuras de Vout thread t, ası́ como otras que
se van a utilizar.
pf render: Esta función es llamada cada vez que hay una nueva picture t para procesar.
Le hemos asignado nuestra función Render que será la encargada de ir pasando las
imágenes al conversor.
pf end Esta función es llamada antes de destruir el plugin y nos servirá para eliminar
de memoria alguna de las estructuras creadas. Se le ha asignado la función End.
Otras funciones de Vout thread t, como pf manage y pf control, que no van a ser utilizadas, han sido puestas a NULL. En la función Init se ha inicializado el hilo de vı́deo de salida,
para ello se han definido varios elementos con respecto al formato de salida:
output.i chroma: Color y planos que se le van a asignar a la salida de vı́deo. Ha sido
inicializado para adaptarse al resultado del método Render.
output.i width: Ancho de la imagen de salida. Se le asignará la dimensión que el usuario
haya introducido.
output.i height: Longitud de la imagen de salida. Se le asignará la dimensión que el
usuario haya introducido.
4.4. Fase de implementación
91
output.i aspect: Aspecto de la imagen de salida. Ha sido inicializado para adaptarse al
resultado del método Render.
Tras definir estos elementos con respecto a la salida de vı́deo se creará un nuevo hilo de
salida de vı́deo que respete el formato asignado. Para ello se utilizará la función:
vout_Create( p_vout, &fmt )
Los parámetros de entradas de esta función serán el hilo de vı́deo original y el formato que se
le quiere asignar al nuevo hilo de salida de vı́deo. El resultado de esta operación será un nuevo
hilo de salida de vı́deo con el formato definido previamente, que será el que se usará para
procesar las imágenes.
4.4.1.4.
Estructura vout sys t
El hilo de salida de vı́deo tiene un elemento que es la estructura vout sys t, que es una
estructura que permite almacenar ciertos datos en el hilo de salida de vı́deo. En nuestro caso
se ha implementado esta estructura con los siguientes componentes:
Listing 4.2: Descripción de la estructura vout sys t
1
struct vout sys t {
2
i m a g e h a n d l e r t ∗ p image ;
3
v o u t t h r e a d t ∗ p vout ;
4
int i cv image size ;
5
int i frames ;
6
float f scale ;
7
p i c t u r e t ∗ p proc image ;
8
int i width ;
9
int i height ;
I p l I m a g e ∗ p c v i m a g e [VOUT MAX PLANES ] ;
10
11
};
Como se puede observar en el listing anterior, en esta estructura guardamos los siguientes
elementos:
4.4. Fase de implementación
92
p vout: En este campo guardaremos el nuevo hilo de vı́deo de salida que se creará con
el formato adecuado como se explicaba en la sección anterior.
p proc image: Imagen resultante que quedará tras el proceso de conversión y filtrado.
p cv image: Servirá para guardar la actual imagen tras convertirla a formato OpenCV.
p image: Servirá para poder tratar imágenes.
i cv image size: Tamaño de la imagen en formato OpenCV.
i frames: Número de frames que han sido analizados.
4.4.2.
Dividir la señal en frames
Las partes más importantes con respecto a este caso de uso son las siguientes:
Obtener una picture t de vout thread t.
Convertir de picture t a IplImage.
A continuación se dará una descripción más detallada de cada una de estas partes.
4.4.2.1.
Obtener una picture t de vout thread t
Cuando se ha creado el hilo de salida de vı́deo, el siguiente paso es ir extrayendo una a una
las picture t que van llegando a este hilo. Para implementar esto en primer lugar se ha creado
un buffer directo que contenga en cada momento el máximo número de picture t posibles.
Esto nos permitirá ganar en eficiencia, ya que se irán sacando las imágenes del buffer. Para
crear este buffer se ha usado la siguiente sentencia:
ALLOCATE_DIRECTBUFFERS( VOUT_MAX_PICTURES );
A continuación, en el Plugin, dentro de la función Render, se irán creando una a una
las imágenes (picture t).Seguidamente se muestra el algoritmo que permite ir realizando esta
acción:
4.4. Fase de implementación
93
Listing 4.3: Extraer imágenes del hilo de vı́deo
1
2
p i c t u r e t ∗ p o u t p i c = NULL ;
w h i l e ( ( p o u t p i c = v o u t C r e a t e P i c t u r e ( p v o u t −>p s y s −>p v o u t ,
0 , 0 , 0 ) ) == NULL ) {
i f ( p v o u t −>b d i e | | p v o u t −>b e r r o r ) {
3
p r i n t f ( ”ERRORR\ n ” ) ;
4
return ;
5
6
}
7
m s l e e p ( VOUT OUTMEM SLEEP ) ;
8
}
Vemos que simplemente se espera en un bucle infinito hasta que se pueda crear una nueva
imagen; es decir, hasta que se reciba una nueva imagen. Si no se obtiene la imagen dormimos el bucle hasta que se pueda obtener. Para crear la imagen llamamos a la función
vout CreatePicture pasando como parámetro el hilo de vı́deo. Cuando se obtiene ésta, es
enviada al Conversor para que la convierta a formato OpenCV.
4.4.2.2.
Convertir de picture t a IplImage
Dentro del conversor se ha implementado el método convertirToIplImage que toma una
imagen en formato picture t y devuelve una imagen en formato OpenCV.
Estas dos tipos de imágenes son representadas por dos estructuras totalmente independientes. Por lo que tendremos que ir introduciendo los elementos de la estructura picture t
dentro de los campos de una IplImage. En las siguientes tablas se muestran los elementos
más importantes de cada una de las estructuras.
4.4. Fase de implementación
94
Nombre
Tipo
Descripción
Format
vı́deo frame format t
Propiedades y formato de la imagen
p[ ]
plane t
Contiene los diferentes planos de la imagen
i planes
int
Número de planos de la imagen
i status
int
Estado de la imagen
Date
mtime t
Tiempo previsto para la reproducción de la imagen
b progressive
vlc bool t
Si forma parte de una secuencia progresiva
i nb fields
int
Campos de la imagen que deben ser reproducidos
p data
uint8 t *
Dirección de memoria al buffer de datos
p next
struct picture t *
Referencia a la siguiente imagen
Cuadro 4.11: Elementos más importantes de la estructura picture t
Nombre
Tipo
Descripción
nSize
int
Tamaño entero de la imagen
ID
int
Identificador único de la imagen
nChannels
int
Número de canales de color de la imagen
depth
int
Profundidad de la imagen
heigth
int
Dimensión de la imagen
width
int
Dimensión de la imagen
channelSeq
byte[]
Valor de los pixels
imageData
byte*
Estructura para representar las caracterı́sticas de la imagen
p next
struct picture t *
Referencia a la siguiente imagen
colorModel
byte[]
modelo de color de la imagen
Cuadro 4.12: Elementos más importantes de la estructura IplImage
Como se puede ver en la tabla 4.11, en la estructura picture t no se dispone de los datos
reales de la imagen, sino que esta imagen está compuesta por diferentes planos (matriz de
estructuras plane t), y en estos planos es donde disponemos de los datos reales de la imagen.
4.4. Fase de implementación
95
En la siguiente tabla podemos ver los componentes de la estructura plane t.
Nombre
Tipo
Descripción
p pixels
uint8 t *
Puntero al comienzo de los datos del plano
i lines
int
Número de bytes en una linea ,incluyendo márgenes
i pitch
int
Número de canales de color de la imagen
i pixel pitch
int
Tamaño de un pı́xel (por defecto es 1) según los canales de color
i visible lines
int
Número de lı́neas visibles en un plano
i visible pitch
int
Número de pixels visibles en una linea
Cuadro 4.13: Elementos más importantes de la estructura plane t
Como vemos, las IplImage no tienen planos, por lo que se creará una IplImage por cada
uno de los planos de picture t. Por eso tenemos en la estructura vout sys t el componente IplImage *p cv image[VOUT MAX PLANES], matriz cuyas posiciones representan los
diferentes planos de picture t y en la que iremos guardando una IplImage por cada posición.
Lo primero que se debe hacer es obtener las dimensiones de la nueva imagen que se va a
crear. Para poder crear el tamaño de una IplImage se usa la siguiente función:
CvSize cvSize( int width, int height );
Devuelve una estructura llamada CvSize utilizada para definir las dimensiones de un rectángulo en pı́xeles. Tendremos que introducir a esta función las dimensiones del plano, y en la
estructura plane t no se tienen las dimensiones del plano. En la figura 4.20 se puede ver la
descomposición del plano en pı́xeles y lı́neas.
4.4. Fase de implementación
96
Figura 4.20: Plano de una picture t
Observando esta figura, se deduce claramente que se pueden obtener las dimensiones de
un plano de la siguiente forma:
width: El ancho de la imagen puede ser calculado conociendo el número de pı́xeles que
hay en una lı́nea. Esa información se tiene en i visible pitch. Pero como el tamaño de
un pı́xel puede tener distinto tamaño (aunque suele ser uno) según los canales de color
que este tenga, se dividirá entre el tamaño del pı́xel.
i visible pitch i pixel pitch (4.1)
heiht: Como vemos en la figura 4.20 la altura del plano será el número de lı́neas visibles
del plano. Y está dimensión se obtiene de i visible lines.
Después de obtener el tamaño de la IplImage se creará una imagen de ese tamaño para
ello se utiliza la siguiente función:
IplImage* cvCreateImageHeader(CvSize size,int depth,int channels);
Esta función nos devolverá una IplImage, a esta función se le han pasado los siguientes
parámetros:
size: Las dimensiones de la imagen calculadas anteriormente.
4.4. Fase de implementación
97
depth: Profundidad que se le asignará a la imagen. Se ha elegido 8 bit de enteros sin
signo para representar los valores de color de la imagen. En OpenCV se representa
mediante la constante IPL DEPTH 8U.
channels: Indica el número de canales de color que va a tener la imagen. Le asignamos
i pixel pitch que nos proporciona el número de canales de color que tiene cada pı́xel.
Por lo que ası́ se obtendrá una IplImage de las dimensiones, profundidad y color requeridos. Pero esta imagen no es más que un esqueleto que no contiene todavı́a realmente los
datos del plane t. El siguiente paso es asignar los datos del plano a la estructura IplImage,
recién creada. Como se puede observar en la tabla 4.12, las estructuras de datos IplImage se
diferencian respecto a las picture t y sus planos en que las imágenes no son almacenadas por
pı́xel sino que son almacenadas como arrays de niveles de color. Estos arrays suelen estar
almacenados en orden BGR. Y este array está representado en imageData[] como se puede
observar en la siguiente tabla.
imageData[0]
imageData[1]
imageData[2]
imageData[3]
imageData[4]
imageData[5]
B
G
R
B
G
R
Cuadro 4.14: Campos del array ImageData
En cada plane t se guardan los datos relativos a los pı́xeles del plano en el puntero p pixel,
por lo que habrá que introducir estos datos en el campo imageData de IplImage. Para realizar
esta acción se ha usado la siguiente función:
void cvSetData( CvArr* array, void* data, int step )
Que permite introducir los datos data dentro de array de longitud step in bytes. Por lo que
como parámetros de la función se le ha pasado:
array: Se le ha pasado el campo imageData de la IplImage que se ha creado.
data: Los datos que queremos copiar dentro de array en este caso p pixel campo de
plane t.
4.4. Fase de implementación
98
step: Es el número de campos columnas que va a tener el array, en nuestro caso uno
para cada canal de color; es decir, le pasamos i pitch de plane t.
Realizando esta copia de datos quedarı́a totalmente transformado un plano t en una IplImage. Ahora se debe realizar todas estas acciones para cada uno de los planos de picture t.
A continuación se puede ver el algoritmo completo de transformación que a partir de una
picture t obtiene un array de IplImage, una por cada plano de picture t.
Listing 4.4: Algoritmo de tranformación de picture t a IplImage
1
p l a n e s = p s y s −>p p r o c i m a g e −>i p l a n e s ;
2
p s y s −>i c v i m a g e s i z e = p l a n e s ;
f o r ( i = 0 ; i < p l a n e s ; i ++ ) {
3
s z = c v S i z e ( a b s ( p s y s −>p p r o c i m a g e −>p [ i ] .
4
i visible pitch /
5
p s y s −>p p r o c i m a g e −>p [ i ] . i p i x e l p i t c h ) ,
6
a b s ( p s y s −>p p r o c i m a g e −>p [ i ] . i v i s i b l e l i n e s ) ) ;
7
p s y s −>p c v i m a g e [ i ] = c v C r e a t e I m a g e H e a d e r ( sz ,
IPL DEPTH 8U ,
8
p s y s −>p p r o c i m a g e −>p [ i ] . i p i x e l p i t c h ) ;
9
c v S e t D a t a ( p s y s −>p c v i m a g e [ i ] ,
( char ∗ ) ( p s y s −>p p r o c i m a g e −>p [ i ] . p p i x e l s ) , p s y s
10
−>p p r o c i m a g e −>p [ i ] . i p i t c h ) ;
}
11
Como podemos ver en el algoritmo a partir de la imagen p proc image que se encuentra
dentro de la estructura p sys se obtendrá la matriz de IplImage p cv image que es también un
campo de p sys.
4.4.3.
Filtrado de cada frame por separado
Tras obtener una imagen en formato OpenCV es el momento de poder filtrarla, para ello
se podrá utilizar cualquier filtro de OpenCV. En esta sección se explicará como se ha implementado el filtro para la detección de gestos de manos y como se ha aplicado el clasificador
4.4. Fase de implementación
99
de caras para realizar el filtro de detección de rostros.
La posibilidad de añadir nuevos filtros es muy grande ya que OpenCV es una herramienta
con una amplia gama de funciones que permiten realizar todo tipo de acciones con imágenes.
4.4.3.1.
Filtro de detección de caras
Este filtro a partir de una IplImage de OpenCV detectará si en ésta hay alguna cara humana
modificando la imagen original marcando la cara con un cı́rculo.
Primero, se debe suavizar la imagen y pasarla a escala de grises, ya que los colores no
son interesantes para poder buscar una cara, ya que simplemente nos centraremos en formas
geométricas. Para realizar esta acción, se utiliza la siguiente función de OpenCV que nos
dará la imagen de entrada en escala de grises:
cvCvtColor(IplImage orig, IplImage dest, CV_GRAY2GRAY)
Cuando se obtiene una imagen con las dimensiones y colores adecuado se procederá a la
detección de caras en la imagen. Para ello se utilizará la siguiente función:
CvSeq* cvHaarDetectObjects( const IplImage* img,
vHidHaarClassifierCascade* cascade,
CvMemStorage* storage,
double scale_factor,
int min_neighbors, int flags);
Esta función encuentra regiones rectangulares en la imagen de entrada que tienen una gran
probabilidad de contener los objetos para los que el parámetro cascade ha sido entrenado, devolviendo estas regiones como una secuencia de rectángulos. Esta función escanea la imagen
varias veces en diferentes escalas. Aplicando algoritmos de heurı́stica para reducir el número
de regiones analizadas.
Por lo que simplemente se deberá pasar como parámetro un CvHidHaarClassifierCascade
entrenado para detectar caras. Estos clasificadores son archivos XML y en particular se ha
usado un clasificador de OpenCV que nos permite encontrar caras de frente. Este clasificador
es haarcascade frontalface alt.xml.
4.4. Fase de implementación
100
Después se obtendrá una secuencia de rectángulos donde se encuentran las caras por lo
que lo único que se debe hacer es recorrer esta secuencia e ir marcando con un cı́rculo cada
una de las caras.
4.4.3.2.
Detección de manos
Al contrario que con la detección de caras, para el reconocimiento de manos OpenCV no
dispone de ningún clasificador entrenado para realizar esta labor. Por lo que se ha implementado dicho clasificador para este proyecto. Realizar un clasificador requiere un largo y tedioso
proceso. En la figura 4.21 se pueden ver las diferentes etapas que se han seguido para realizar
el clasificador.
Figura 4.21: Etapas para realizar el clasificador de manos
El primer paso que se debe seguir para crear el clasificador será tomar las imágenes que
van a ser utilizadas para entrenar dicho clasificador. Estas imágenes son de dos tipos:
Imágenes negativas: Son imágenes tomadas de forma arbitraria. Lo más importante de
estas imágenes, es que no contengan el objeto a clasificar, en este caso que no contengan
4.4. Fase de implementación
101
ninguna mano. Estas imágenes pueden ser imágenes de diferentes lugares. Para realizar
el clasificador se han usado 5000 imágenes. En la figura 4.22 se puede observar una
pequeña muestra de estas imágenes.
Figura 4.22: Ejemplo de la muestra de imágenes negativas utilizadas
Imágenes Positivas: Son imágenes en las que se encuentra el objeto a clasificar de una
forma clara en este caso, imágenes de manos. Para realizar el clasificador se han tomado más de 2500 imágenes de las que finalmente se han utilizado 1400 imágenes. Estas
imágenes han sido tomadas desde diferentes ángulos, con diferentes fondos y diferente iluminación. En la siguiente figura podemos observar un ejemplo de las imágenes
tomadas.
4.4. Fase de implementación
102
Figura 4.23: Ejemplo de las imágenes positivas utilizadas
Una vez adquiridas las imágenes se pasará a la siguiente etapa, crear la muestra. Para crear
la muestra se utilizará el siguiente comando de OpenCV:
opencv-createsamples -info positives/info.txt
-vec infovec.vec -num 1400 -w 20 -h 20
Donde num es el número de imágenes positivas, w y h la longitud que se desea que tengan
las imágenes de muestra de salida, -vec el vector de salida e info.txt es un archivo de texto
que contiene la información de donde se encuentran las manos en las imágenes positivas. Este
archivo tiene la siguiente estructura:
Ruta_imagen número x y ancho largo
Por lo que en cada una de las 1400 imágenes se deberán obtener las dimensiones y coordenadas de donde se encuentra la mano. Para facilitar esta tarea se ha implementado una
herramienta de marcado utilizando OpenCV, que creará el archivo de texto automáticamente
y permitirá marcar las manos con un rectángulo utilizando el ratón.
Tras realizar este proceso se creará el vector que contiene las imágenes de muestra, estas
imágenes estarán normalizadas, en escala de grises y con el tamaño adecuado. En la figura
4.24 podemos encontrar un pequeño ejemplo de la muestra generada.
4.4. Fase de implementación
103
Figura 4.24: Ejemplo de la muestra
La siguiente etapa, después de crear la muestra, es la de entrenamiento del clasificador.
Para ello se ha utilizado el siguiente comando de OpenCV:
opencv-haartraining -data trainout -vec infovec.vec -bg negatives.txt
-nstages 30 -nsplits 2 -minhitrate 0.999-maxfalsealarm 0.5 -npos 1400
-neg 5000 -w 20 -h 20 -mem 700 -mode ALL
Donde cada uno de los argumentos tienen el siguiente significado:
data: Ruta de salida del clasificador.
vec: Vector de la muestra que se ha creado en la fase anterior.
bg: Archivo de texto con la ruta de las imágenes negativas.
nstages: Número de etapas que van a ser entrenadas. A un mayor número de etapas,
más potente será el clasificador. En este caso se han usado 30 etapas, que es un número
alto.
nsplit: Determina la debilidad del clasificador a utilizar. En nuestro caso es 2, lo que
indica que se utilizará el clasificador CART con 2 divisiones internas de nodos.
minhitrate: Mı́nimo rango de cada etapa. Se estima a partir del número de etapas.
maxfalsealarm: Máximo rango que se permite de falsas alarmas para cada etapa del
clasificador. Cuanto mayor sea este rango, peor será el clasificador.
4.4. Fase de implementación
104
npos: Número de elementos positivos de la muestra.
neg: Número de elementos negativos de la muestra.
w y h: Longitud de las imágenes.
mem: Memoria que se va a utilizar para el proceso de entrenamiento.
Este entrenamiento de OpenCV esta basado en AdaBoost [33] que es un algoritmo de
aprendizaje que se centra en 2 aspectos importantes:
Seleccionar un conjunto de caracterı́sticas que representen la mano.
Entrenar este clasificador con una combinación lineal de las mejores caracterı́sticas.
La fase de entrenamiento tiene un alto nivel computacional y necesita varias horas para
finalizar el proceso. En este caso se tardaron 20 horas en tener un clasificador robusto. En el
capı́tulo de resultados se describirán los resultados obtenidos.
Cuando la fase de entrenamiento ha terminado disponemos de un clasificador cascade en
formato XML que podrá ser usado de la misma forma que en la detección de caras; es decir,
se creará un algoritmo que a partir de una imagen de entrada nos diga si contiene alguna
mano. Para ello se realizará el proceso ya explicado en el caso de la detección de caras:
1. Se normalizará la imagen de entrada.
2. Se pasará a escala de grises.
3. Se pondrá en el tamaño adecuado.
4. Se usará el método objectDetect pasándole como parámetros la imagen de entrada y el
clasificador cascade que se ha creado.
Tras realizar este proceso, se conocerá en cada imagen si hay una mano y si es ası́, las
coordenadas exactas donde se encuentra. Estos datos serán mandados al reconocedor de gestos para que diga si esa mano está realizando alguno de los gestos. La forma de implementar
el reconocedor de gestos será explicada en la siguiente sección.
4.4. Fase de implementación
4.4.3.3.
105
Filtro de reconocimiento de gestos
Tras obtener las imágenes de las manos, estamos preparados para implementar el algoritmo de reconocimiento de gestos. Para nosotros, un gesto va a ser cualquier cambio o movimiento desde una posición original de la mano (mano abierta) a una nueva forma o posición,
por ejemplo cerrar el puño, apuntar con el dedo, mover un dedo, etc. En la figura 4.25 se
muestran algunos ejemplos de posibles gestos.
Figura 4.25: Ejemplo de posibles gestos
Al detector de gestos le irán llegando, una a una, la secuencia de manos que va detectando
el detector de manos. Por lo que se deberá conocer en cada momento, qué cambios se han
ido produciendo en la mano con respecto de la mano anterior. Sólo nos centraremos en los
cambios de una imagen respecto a la otra. Para ello se ha realizado el siguiente proceso:
Se irá guardando siempre la última imagen de mano procesada, para compararla con la
siguiente.
Cuando llegue una nueva imagen de una mano, se comparará con la última imagen
para saber los cambios que se han producido. Con la librerı́a OpenCV disponemos de
la siguiente función que nos va a permitir obtener la diferencia de dos imágenes en una
nueva imagen:
cvAbsDiff (img1, img2, resultado);
4.4. Fase de implementación
106
Por lo que con esta función obtendremos una nueva imagen que representa únicamente
los cambios producidos entre las dos últimas imágenes.
Será necesario representar en una única imagen un gesto y servirá como patrón para comparar
el grado de parecido que tiene con otras imágenes. Para formar las imágenes únicas que
representen el gesto, se irán añadiendo a una imagen las diferencias que se van produciendo
entre las dos últimas imágenes. Para diferenciar el orden en el que se han producido los
cambios se utilizan distintos colores:
Se usará el color rojo para representar los cambios más recientes que se han producido.
El color azul representará los cambios más antiguos en la imagen.
Cuando llega una nueva imagen se compara con la anterior se obtiene la diferencia y esta
diferencia se añade en color rojo a la imagen que va formando el gesto pasando a colores más
azules la parte del gesto que ya contiene la imagen y desapareciendo de la imagen las partes
más antiguas (en color azul).
Figura 4.26: Proceso de cambios de color si no hay cambios en la imagen
En la figura 4.28 se puede observar como pasan los colores de rojo a azul de una mano
que no realiza ningún movimiento. Finalmente la imagen desaparece ya que no se produce
ningún cambio en la mano.
Por lo que finalmente, se obtendrá una única imagen con colores azules y rojos que represente el gesto. En la siguiente figura se muestra la evolución de la imagen cuando se realiza
el gesto de cerrar el puño, la imagen señalada serı́a cuando se ha finalizado el gesto y serı́a la
imagen que sirve de muestra del gesto.
4.4. Fase de implementación
107
Figura 4.27: Proceso de gesto
En la imagen marcada vemos que la parte azul corresponde a la posición original de la
mano y la roja al movimiento que ha realizado (cerrar el puño).
A continuación se mostrarán las partes más importantes del algoritmo que lleva a cabo
todo el proceso explicado.
Listing 4.5: Algoritmo de detección de gestos
1
2
if (! last )
l a s t = cvCloneImage ( small img ) ;
3
cvAbsDiff ( small img , l a s t , l a s t ) ;
4
cvConvertScale ( last , last , 0.005) ;
5
c v C o n v e r t S c a l e ( r e s , r e s , 0 . 9 , −0.5) ;
6
/ / ponemos l o s c a m b i o s de e s t e f r a m e
7
cvSet ( res , cvScalar (255) , l a s t ) ;
8
/ / ahora l a u l t i m a es e s t e frame
9
c v R e l e a s e I m a g e (& l a s t ) ;
10
l a s t = small img ;
11
/ / l a componente r o j a es r e s d i r e c t a m e n t e
12
I p l I m a g e ∗ c r e s = c v C r e a t e I m a g e ( WSIZE , IPL DEPTH 8U , 3 ) ;
13
cvSetZero ( cres ) ;
14
cvMerge ( 0 , 0 , r e s , 0 , c r e s ) ; / / BGR
15
/ / l a c o m p o n e n t e a z u l e s 255 − r e s
16
I p l I m a g e ∗ b l u e = c v C r e a t e I m a g e ( WSIZE , IPL DEPTH 8U , 1 ) ;
4.4. Fase de implementación
17
cvSetZero ( blue ) ;
18
cvSubRS ( r e s , c v S c a l a r ( 2 5 5 ) , b l u e , r e s ) ;
19
cvMerge ( b l u e , 0 , 0 , 0 , c r e s ) ; / / M e z c l a de l a c o m p o n e n t e a z u l y
108
roja
El sistema dispondrá de varias imágenes patrones de gestos (de colores azul y rojo) con
las que comparar, y si el grado de parecido entre la imagen patrón de un gesto y la imagen
que se ha creado es muy alto se determinará que ese gesto se ha producido. Estas imágenes
patrones son almacenadas a través de la clase CodeBook que guarda las rutas de donde se
almacenan realmente estas imágenes y dispone de 2 métodos importantes:
void insert(IplImage* img, std::string name): Función que permite insertar nuevas imágenes en el Codebook.
IplImage* findSimilar(IplImage* img, double dif, std::string name): Función que devuelve la imagen almacenada en el codebook más parecida a img almacenando en dif
el valor de la diferencia entre ambas imágenes. Esta función es utilizada para obtener
la imagen más similar a una dada y ası́ conocer si esta imagen coincide con alguno de
los gestos almacenados en CodeBook.
Figura 4.28: Ejemplo de imagen patrón que representa cerrar el puño y mover el dedo ı́ndice
4.4.4.
Rehacer la señal
Cuando acaba el proceso de filtrado el Filtro le da la nueva IplImage al Conversor. Y
este debe convertir la imagen al formato de VLC. En esta sección se muestra como se ha
implementado este proceso.
4.4. Fase de implementación
4.4.4.1.
109
Convertir de IplImage a picture t
Al diseñar el sistema se pensó en realizar la función convertirToPicture que aceptara una
IplImage como parámetro y devolviera esa imagen en una estructura picture t. Pero al realizar
la implementación del caso contrario (pasar de picture t a IplImage) se ha observado que este
proceso ya no es necesario. Esto es debido a que tras realizar la conversión del algoritmo 4.5
cualquier modificación que se realice en la IplImage se hará también en la imagen original.
Ya que al asignar los datos del plano a los datos de la IplImage con la función:
cvSetData( p_sys->p_cv_image[i],
(char*)(p_sys->p_proc_image->p[i].p_pixels),
p_sys->p_proc_image->p[i].i_pitch );
Cuando se modifique p sys->p cv image[i] estos cambios se harán automáticamente en p sys>p proc image->p[i] ya que con la función cvSetData hace que estas dos estructuras estén
compartiendo los mismos datos.
La ganancia con respecto a la eficiencia del sistema es muy grande, ya que se ahorrará el
tiempo de realizar la conversión desde IplImage a picture t.
4.4.5.
Enviar la señal
Tras realizar todo el proceso anterior, el usuario tiene la opción de enviar la señal a otro
equipo a través de la red, creando un nuevo flujo rtsp. Al igual que cuando se captura la señal
rtsp, nuestro programa se abstrae de estas acciones usando las funcionalidades de VLC. Para
realizar esta acción si el usuario ha introducido esta opción automáticamente se creará un
script que ejecutará VLC en modo telnet con una dirección,un puerto y una contraseña:
% vlc --ttl 12 -vvv --color -I telnet --telnet-password videolan
--rtsp-host 0.0.0.0:5554
Y creará un objeto VOD ( Vı́deo On Demand) con la información de la rtsp de origen y que
lance el plugin:
4.4. Fase de implementación
110
new Test vod enabled
setup Test input rtsp://direccion_de_captura
--vout-filter Capture
Por lo que se irá creando un nuevo flujo que será un filtrado del flujo original que cualquier
otro usuario puede capturar con vlc desde otra maquina conectada a través de la red. Para ello,
simplemente ese usuario deberá introducir la nueva dirección rtsp:
vlc rtsp://server:5554/Test
4.4.6.
Mostrar el vı́deo
El usuario no tiene por qué querer mandar la señal a otras máquinas, sino que quizás
desea simplemente ir mostrando el vı́deo filtrado en su propio ordenador. Para ello, el método
Render del plugin, cuando el Conversor le va dando las nuevas picture t filtradas, deberá decirle a VLC que saque por su salida de vı́deo estas imágenes. Esto se hace con dos funciones
principalmente:
vout_DatePicture(vout_thread_t *p_vout, picture_t *p_pic, date d)
Con esta función se le asignarán a la nueva picture t el tiempo exacto en el que se tiene
que reproducir. En nuestro caso, le asignaremos el tiempo en el que estaba previsto que se
reproduciera la imagen original. Esto permitirá sincronizar el audio con el vı́deo de forma
correcta. Ahora sólo queda decir a vlc que reproduzca esta imagen y para ello se usa la
función:
vout_DisplayPicture(vout_thread_t *p_vout, picture_t *p_pic)
A esta función se le pasa como parámetro el hilo de salida de vı́deo y la picture t filtrada que
se quiere reproducir. Como resultado las imágenes serán visualizadas por el usuario en su
pantalla.
Capı́tulo 5
Resultados
5.1. Introducción
5.2. Resultados del proceso de captura
5.2.1. Eficiencia al realizar la captura
5.2.2. Posibilidad de trabajo distribuido
5.3. Resultados del clasificador de Manos
5.4. Resultados en la detección de gestos
5.4.1. Eficiencia
5.4.2. Interacción con el computador
5.1.
Introducción
En este capı́tulo se explicarán los resultados más importantes obtenidos a nivel de tiempo
y eficiencia, tanto del proceso de captura como del proceso de filtrado. Además, se propondrán
algunas de las posibilidades para las que se ha probado el software desarrollado.
5.2.
Resultados del proceso de captura
En esta sección se explicarán los resultados más importantes con respecto al proceso de
captura de la señal RTSP.
111
5.2. Resultados del proceso de captura
5.2.1.
112
Eficiencia al realizar la captura
Se han realizado mediciones de tiempo para comprobar la latencia del Plugin realizado.
Para ello se ha medido el tiempo que tarda VLC en mostrar la señal en varias situaciones:
Tiempo que se tarda sin que se realice la conversión VLC-OpenCV-VLC.
Tiempo que se tarda realizando la conversión VLC-OpenCV-VLC. Haciendo una pequeña modificación en la imagen, que no suponga pérdida de tiempo, por lo que este
tiempo no se tendrá en cuenta.
A continuación, se detallarán y se compararán los resultados obtenidos en ambas mediciones:
5.2. Resultados del proceso de captura
113
Frame
Con conversión
Sin conversión
Diferencia
1
0,49514
0,280348
0,21
2
0,28355
0,167648
0,12
3
0,3412
0,166125
0,18
4
0,43699
0,197013
0,24
5
0,48387
0,175015
0,31
6
0,44845
0,169346
0,28
7
0,23369
0,167445
0,07
8
0,22909
0,0979604
0,13
9
0,22361
0,116065
0,11
10
0,2006
0,0941212
0,11
11
0,22458
0,0890702
0,14
12
0,27502
0,101752
0,17
13
0,22273
0,100042
0,12
14
0,22097
0,0877085
0,13
15
0,21024
0,0916497
0,12
16
0,23027
0,0882124
0,14
17
0,23525
0,0939592
0,17
18
0,21813
0,0878524
0,12
19
0,24494
0,103677
0,13
20
0,22047
0,0953569
0,12
Cuadro 5.1: Tiempos en us de los 20 primeros frames
En la tabla 5.1 vemos el tiempo obtenido en milisegundos de cada una de las medidas.
Y la diferencia de tiempos entre las 2 medidas en un mismo frame. Calculando la diferencia
media en los 50 primeros frames esta es de 0,15 us. Es decir, de media sólo se tardan 0,15 us
en realizar la conversión de formato vlc a OpenCV y de nuevo a vlc. Esta diferencia es una
cantidad muy pequeña que no se va a apreciar por el ojo humano cuando se reproduzca un
flujo RTSP. En la siguiente figura se puede apreciar las diferencias entre las 2 medidas.
5.2. Resultados del proceso de captura
114
Figura 5.1: Tiempo obtenidos en la medidas realizando la conversión(azul) y sin realizar la
conversión (rojo)
Se puede concluir que el resultado obtenido es un resultado muy positivo ya que las diferencias en tiempo de utilizar nuestra aplicación y no utilizarla son prácticamente inexistentes.
5.2.2.
Posibilidad de trabajo distribuido
El trabajo de procesamiento y filtrado de vı́deos puede ser una tarea costosa computacionalmente, por lo que es mejor que esta tarea pueda ser distribuida en varios ordenadores.
El diseño del sistema permite realizar el procesamiento distribuido de una fuente de vı́deo.
Este trabajo en paralelo se puede realizar en varios computadores donde a cada uno de estos se le asignará un trabajo concreto. A continuación se explicarán las distintas formas de
procesamiento que permite el sistema.
La primera forma de trabajo distribuido que permite el sistema es que varios ordenadores
reciban, procesen y filtren distintos flujos de vı́deo RTSP para finalmente enviar de nuevo
estos flujos a otra máquina que sea la encargada de unir todos los flujos de vı́deo en un único
flujo RTSP. En la siguiente figura se puede ver un esquema que representa esta idea.
5.2. Resultados del proceso de captura
115
Figura 5.2: Arquitectura distribuida: unión de flujos de vı́deo
Una de las posibles aplicaciones de este tipo de arquitecturas, puede ser a partir de imágenes de 3 cámaras distintas, formar una única imagen panorámica. Teniendo mayor eficiencia
que si la imagen panorámica la mandara un única cámara, ya que de esta forma el filtrado de
las imágenes se realizará de forma paralela en varias máquinas. Otra de las ventajas de este
sistema es que se pueden conseguir imágenes con dimensiones superiores que si se utilizan
cámaras panorámicas.
5.2. Resultados del proceso de captura
116
Figura 5.3: Imagen panorámica a partir de las fuentes de 3 cámaras
El siguiente tipo de trabajo distribuido que se puede realizar con la aplicación, está enfocado a que cada computador realice una etapa del filtrado. Por ejemplo, para el detector de
gestos, un computador podrı́a realizar la tarea de encontrar las manos en el flujo principal y,
posteriormente rehacer el flujo de vı́deo conteniendo únicamente las imágenes de las manos,
y este flujo será recibido por otro computador que realizará la tarea de detectar si esas manos
contienen gestos. En la figura 5.4 se puede apreciar un esquema del diseño de esta idea.
5.2. Resultados del proceso de captura
117
Figura 5.4: Arquitectura distribuida: Filtrado por separado
De esta forma el sistema es mucho más eficiente ya que mientras la máquina 2 esta detectando gestos en el frame n la máquina 1 detectará manos en el frame n+1. Por lo que, en este
caso en particular, se realizará la tarea de filtrado el doble de rápido.
La tercera forma de distribuir el trabajo esta basada en la misma forma de distribución
que la estrategia anterior, es decir, que cada máquina realice una parte del filtro, pero en este
caso, las 2 máquinas recibirán la misma señal de vı́deo. Por lo que estas máquinas deberán
comunicarse entre ellas para ver que tipo de filtrado realiza cada una. Por ejemplo, para nuestro filtro de detección de gestos nuevamente la máquina 1 realizará la detección de manos y la
máquina 2 la de gestos. Como las 2 máquinas reciben la misma señal de vı́deo, si la máquina 1
ha encontrado una mano en el frame n simplemente deberá decirle las coordenadas de dónde
se encuentra la mano a la máquina 2 y ésta se encargará de detectar si es o no un gesto. Para
5.3. Resultados del clasificador de Manos
118
que ambos máquinas se comuniquen se utiliza un canal de eventos. La figura 5.5 resume el
diseño de esta idea.
Figura 5.5: Arquitectura distribuida: Filtrado por separado con la misma señal de vı́deo
5.3.
Resultados del clasificador de Manos
Como se explicó en el capı́tulo anterior, la última fase del entrenamiento de un clasificador
de objetos de OpenCV es la fase de pruebas, para realizar esta pruebas OpenCV dispone del
siguiente comando:
opencv-performance -data handDetector.xml -info info.txt
Para realizar esta prueba se han utilizado 50 imágenes que contienen manos. En el archivo
info.txt se le dice las coordenadas donde se encuentran las manos. Y la herramienta nos
devuelve los siguientes datos:
Objetos encontrados.
Objetos perdidos.
Falsos positivos.
5.3. Resultados del clasificador de Manos
119
Imagen
Encontrados
Perdidos
Falsos Positivos
1
1
0
0
2
1
0
0
3
1
0
0
4
1
0
0
5
1
0
0
6
1
0
1
7
0
1
1
8
1
0
0
9
1
0
0
10
1
0
0
11
1
0
1
12
1
0
0
13
1
0
0
14
1
0
0
15
1
0
0
16
1
0
2
17
1
0
1
18
1
0
0
19
1
0
0
20
1
0
0
21
1
0
0
22
1
0
1
23
1
0
0
24
1
0
0
25
1
0
0
26
1
0
0
27
0
1
0
5.3. Resultados del clasificador de Manos
120
28
1
0
3
29
1
0
0
30
1
0
1
31
1
0
0
32
1
0
0
33
1
0
0
34
1
0
0
35
1
0
0
36
1
0
0
37
1
0
1
38
1
0
1
39
1
0
1
40
1
0
0
41
1
0
0
42
1
0
0
43
1
0
0
44
1
0
0
45
1
0
0
46
1
0
2
47
1
0
0
48
0
1
0
49
1
0
0
50
1
0
0
Total
48
2
16
Cuadro 5.2: Resultados de las pruebas del clasificador
5.3. Resultados del clasificador de Manos
121
En el cuadro 5.2 se dan los resultados obtenidos en las 50 imágenes de prueba. Se puede
apreciar que el nivel de acierto es muy alto, ya que se alcanza un 96 % de aciertos; es decir,
hay un 96 % de posibilidades de que si existe una mano en una imagen, el clasificador la
encuentre.
En la siguiente figura se pueden ver algunas de las imágenes de salida de las pruebas , en
las que se ha producido acierto y ningún falso positivo.
Figura 5.6: Imágenes resultado del test del clasificador
En la tabla 5.2 se aprecia que se han producido 16 falsos positivos; es decir, que en las 50
imágenes se han marcado como manos 16 objetos que no son manos. Estos falsos positivos
son debidos a las diferencias de ambientes, fondos y luminosidad. La ventaja es que estos falsos positivos suelen ser imágenes muy pequeñas que cuando se realice el filtrado, a través de
la función ObjectDetect, serán descartados automáticamente. En la figura 5.7 se dan algunos
ejemplos de los falsos positivos que se han producido.
5.4. Resultados en la detección de gestos
122
Figura 5.7: Imágenes resultado del test del clasificador con falsos positivos
Con estos resultados se concluye que el clasificador tiene un alto grado de robustez y
eficiencia, ya que su ı́ndice de aciertos es muy alto.
5.4.
Resultados en la detección de gestos
En esta sección se describirán los resultados más importantes que se han conseguido en
la detección de gestos.
5.4.1.
Eficiencia
Al igual que con la parte del filtro encargada de detectar manos, se han realizado pruebas
a este filtro que nos permiten comprobar la eficiencia de este detector de gestos. Como el detector de gestos no es un clasificador, no se podrá utilizar la herramienta opencv-performance
y las pruebas se han realizado manualmente. Concretamente se han probado 2 gestos:
Gesto 1: Pasar de la posición original mano abierta a la posición final mano cerrada.
5.4. Resultados en la detección de gestos
123
Figura 5.8: Gesto 1
Gesto 2: Pasar de la posición original mano abierta a la posición final mano cerrada y
movimiento del dedo ı́ndice.
Figura 5.9: Gesto 2
Se ha realizado cada uno de los gestos 100 veces para comprobar la eficiencia y robustez
del sistema, en el siguiente cuadro se da un resumen de los resultados obtenidos.
PP
PP
PP
P
Gesto
Gesto1
Gesto2
Aciertos
70
95
Fallos
30
5
Falsos positivos
5
4
% Aciertos
70 %
95 %
Resultado
PP
P
PP
P
Cuadro 5.3: Resultados de las pruebas realizadas al detector de gestos
El nivel de acierto en ambos gestos es muy alto. Se observa que los datos del gesto 2 son
mucho mejores que los del gesto 1, ya que éstos alcanzan un acierto del 95 % esto es debido
a que el gesto 2 tiene mucho más movimiento, y este detector de gestos está basado en el
5.4. Resultados en la detección de gestos
124
movimiento, por lo que cuanto más movimiento tenga un gesto será mucho más fácil que el
detector lo encuentre. Los resultados a nivel general son buenos aunque pueden ser mejorables, sobre todo para los gestos más estáticos. Los falsos positivos son aquellos momentos
en los que no se está realizando el gesto y el detector piensa que sı́. Si se quiere eliminar
totalmente estos falsos positivos se deberá acotar más el rango de cada uno de los gestos,
pero realizando esta acotación es posible que el número de aciertos disminuya y se pierda en
eficiencia.
5.4.2.
Interacción con el computador
Una de las aplicaciones para las que se ha utilizado el detector de gestos es para la interacción con el computador. Esta interacción se basa en poder realizar movimientos de ratón y
pulsar teclas a través de la cámara. Como en cada momento se conoce perfectamente donde
se encuentra la mano de un individuo, se ha asignado la posición de esta mano a la posición
del ratón en la pantalla del ordenador, por lo que cuando se mueva la mano del individuo el
ratón se moverá en la pantalla en la misma proporción. Por otro lado, se ha asignado a cada
uno de los gestos almacenados la pulsación de una tecla del teclado, por lo que cuando el
detector perciba que se ha realizado un gesto se realizará una llamada al sistema que mande
la señal de pulsación de una tecla. Esta interacción por computador se ha refinado para poder
realizar las siguientes acciones:
Pasar transparencias de una presentación, realizando un gesto sin necesidad de pulsar
ninguna tecla.
Realizar los movimientos del personaje de un juego en primera persona utilizando la
mano y realizar alguna acción si se produce algún gesto.
El campo de aplicación donde se puede aplicar el detector de gestos es muy amplio. Ya
que añadiendo nuevos gestos se puede llegar a poder controlar cualquier aplicación de un
ordenador utilizando exclusivamente las manos.
Los resultados tanto del movimiento del ratón como de la pulsación de teclas han sido
buenos, pero pueden ser mejorables ya que el funcionamiento está muy limitado a condiciones
5.4. Resultados en la detección de gestos
125
especiales. Pero para mejorar el sistema, basta con añadir nuevos gestos y asignarlos a nuevas
teclas, éste es un trabajo sencillo, aunque muy tedioso.
Aun ası́, los resultados obtenidos se pueden considerar buenos ya que permiten el movimiento del ratón y pulsar varias teclas con los dos gestos implementados.
Capı́tulo 6
Conclusiones y Propuestas
6.1. Conclusiones
6.2. Lineas de investigación abiertas
6.2.1. Detector de gestos
6.2.2. Detector de manos
6.2.3. Movimiento de cámaras Axis
6.1.
Conclusiones
En esta sección se explicará en qué medida se ha conseguido cada uno de los objetivos
que se propusieron en el capı́tulo 2. A continuación se enumeran los objetivos:
El objetivo principal de este proyecto era realizar un marco de trabajo para capturar
flujos de video RTSP/RTP que permita añadir todo tipo de filtros y mecanismos de
procesamiento de imágenes: Este objetivo se ha conseguido claramente, ya que se ha
creado un marco de trabajo con el que se pueden realizar todo tipo de procesamiento
de imágenes a flujos de vı́deo RTSP/RTP. Se ha unido la fuerza de las 2 principales
herramientas en cada uno de estos campos:
• VLC como herramienta de flujos de vı́deo a través de la red.
• Opencv como herramienta para la visión por computador y tratamiento de imágenes.
126
6.1. Conclusiones
127
Gracias a estas dos herramientas se permite, por un lado, usar todas las técnicas de
procesamiento de imágenes que incluye OpenCV, lo que hace que nuestro marco de
trabajo sea una herramienta potente para el procesado de imágenes, y por otro lado,
poder procesar todo los tipos de flujos de vı́deo que permite VLC, por lo que no se
queda sólo en flujos RTSP/RTP, sino que también, se permite otro tipo de capturas,
como HTTP y MMSH. Podemos decir, por tanto, que el objetivo principal del proyecto
ha sido alcanzado con éxito.
Detección de caras: Gracias a OpenCv este objetivo ha sido fácilmente superado, ya
que OpenCV dispone de un clasificador de caras que nos permite detectar si en una
imagen hay una cara humana. Por lo que la implementación de este objetivo ha sido
trivial.
Detección de manos y gestos: Se ha implementado un clasificador que permite detectar
cuando hay una mano en una imagen. También se ha logrado implementar un detector
de gestos basado en el movimiento que permite diferenciar entre varios gestos realizados con las manos. Es posible realizar alguna mejora en este detector de gestos, pero
para este proyecto el objetivo se ha alcanzado claramente.
Compatibilidad con MPEG-4: Al ser VLC compatible con este estándar de vı́deo, nuestra aplicación también lo es. Cumpliendo este objetivo se puede estudiar el aprovechamiento del sistema para el proyecto Hesperia.
Eficiencia en tiempo real: Como se ha visto en el capı́tulo de resultados, la captura del
flujo de vı́deo se realiza sin una gran latencia; de media 0,15 us, por lo que la aplicación
en sistemas de vı́deo en tiempo real será realmente eficiente.
Dar una gestión dinámica de los recursos: El sistema realiza una buena gestión de la
memoria sin realizar un uso excesivo de ningún recurso, por lo que este objetivo se ha
cumplido.
Proporcionar una sencilla instalación del software: El software se instala de forma sencilla ya que al tener la arquitectura de Plugin bastará con añadir este Plugin a los módulos de VLC.
6.2. Lı́neas de investigación abiertas
128
Proporcionar un sistema multiplataforma: Tanto las tecnologı́as utilizadas (OpenCV
y VLC) como los lenguajes de programación utilizados permiten que el sistema sea
multiplataforma. El sistema ha sido probado con los 2 grandes sistemas operativos del
mercado (Windows y Linux) y los resultados han sido buenos en ambos casos.
Desarrollar el sistema utilizando tecnologı́as libres: Este objetivo se ha cumplido, ya
que tanto VLC como OpenCV son tecnologı́as libres.
6.2.
Lı́neas de investigación abiertas
Son varios los aspectos del sistema que pueden ser investigados en más profundidad. En
esta sección se darán algunas ideas de futuras mejoras que pueden ser realizadas al sistema.
Esta ideas se dividen en diferentes grupos.
6.2.1.
Detector de gestos
El detector de gestos puede ser mejorado añadiendo nuevos gestos que permitan al sistema
poder enfrentarse a un mayor número de situaciones. Una de las posibles lı́neas de investigación que tiene este sistema es poder utilizar este detector de gesto para interpretar el lenguaje
de gestos que utilizan las personas sordomudas. De esta forma el sistema podrı́a ser utilizado como traductor de lenguaje de signos y permitirı́a que una persona que no conoce este
lenguaje pueda entenderlo gracias a una cámara y un ordenador.
6.2. Lı́neas de investigación abiertas
129
Figura 6.1: Lenguaje de signos
En la figura 6.1 vemos que los signos de este lenguaje siguen la misma estructura que la
que se ha utilizado en este detector de gestos. Incluso los gestos utilizados como ejemplo de
nuestro detector son ya dos signos del lenguaje de signos que representan las letras A y D. Por
lo que implementar el resto de los signos de este lenguaje no debe suponer un gran esfuerzo.
6.2.2.
Detector de manos
El entrenamiento realizado para crear el clasificado ha sido realizado usando exclusivamente la mano derecha del autor del proyecto. Por lo que este clasificador puede ser entrenado
utilizando imágenes de manos de más personas, consiguiendo ası́ un mayor poder de detección. Otra de las posibilidades de mejora, es tratar como objetos distintos a las manos derecha
e izquierda.
6.2. Lı́neas de investigación abiertas
6.2.3.
130
Movimiento de cámaras Axis
Otra de las lı́neas de investigación es permitir, a través de nuestra aplicación, el movimiento de cámaras Axis. A parte de poder capturar la señal de vı́deo de estas cámaras, se
deberı́a poder usar todas las funcionalidades que este tipo de cámaras poseen:
Movimiento.
Realizar zoom.
Todas estas aplicaciones pueden ser añadidas al sistema.
Apéndice A
Manual de usuario
A.1.
Instalación
Para poder poner en funcionamiento la aplicación primero será necesario tener instalado
en el computador tanto VLC como OpenCV, si esto no es ası́ se pueden descargar de sus
respectivas páginas web: [15] y [19].
Junto a la aplicación se proporciona un script llamado instalar.sh que al ejecutarlo compilará la aplicación y añadirá el plugin a la lista de módulos de VLC.
Para comprobar que todo el proceso de instalación ha sido correcto se puede ver si el
Plugin ha sido añadido a VLC utilizando el siguiente comando:
vlc --list
Si todo ha sido correcto el plugin Capture debe aparecer en esta lista y se podrá proceder
a su ejecución.
A.2.
Ejecución
Para utilizar la aplicación se debe ejecutar el script interfaz.sh. Este script nos mostrará la
interfaz de la aplicación. En la figura A.1 se puede ver la interfaz.
131
A.2. Ejecución
132
Figura A.1: Interfaz de la aplicación
Se puede observar que la interfaz tiene los siguientes elementos:
Cuadro de texto: En este cuadro de texto se debe introducir la dirección rtsp, http o
archivo de vı́deo que se quiere reproducir.
Caja de selección: Se debe elegir que tipo de filtrado se quiere realizar.
Enviar: Se debe marcar esta casilla si se desea volver a enviar el flujo de vı́deo.
A.2. Ejecución
133
Cuando se hayan introducido los datos se pulsará el botón Capturar que hará que comience
el proceso de captura como se puede observar en la figura A.2
Figura A.2: Interfaz de la aplicación cuando se reproduce un flujo de vı́deo
Bibliografı́a
[1] Aphelion’s official site. http://www.aai.com/.
[2] Artoolkit’s official site. http://www.hitl.washington.edu/artoolkit/.
[3] Bazar’s official site. http://cvlab.epfl.ch/software/bazar/.
[4] ccRTP’s official site. http://www.gnu.org/software/ccrtp/.
[5] Gandalf’s official site. http://gandalf-library.sourceforge.net/.
[6] HIPS’s official site. http://www.cns.nyu.edu/ msl/hipsdescr.html.
[7] IETF’s official site. http://www.ietf.org/.
[8] JavaRTP’s official site. http://www.cs.columbia.edu/hgs/teaching/ais/1998/projects/javartp/.
[9] JRTPLIB’s official site. research.edm.uhasselt.be/jori/jrtplib/jrtplib.html.
[10] Live555’s official site. http://www.live555.com/liveMedia/.
[11] Matrox Image Library’s official site. http://www.matrox.com/imaging/.
[12] MPEG4IP’s official site. http://mpeg4ip.net/.
[13] MPlayer’s official site. http://www.mplayerhq.hu/.
[14] NeatVision’s official site. http://neatvision.eeng.dcu.ie/.
[15] OpenCV’s official site. http://opencvlibrary.sourceforge.net/.
[16] oRTP’s official site. http://www.linphone.org/.
[17] Proyecto hesperia official site. https://www.proyecto-hesperia.org/.
[18] UCL’s official site. http://www-mice.cs.ucl.ac.uk/multimedia/software/common/.
[19] VLC’s official site. http://www.videolan.org/.
[20] Vxl’s official site. http://vxl.sourceforge.net/.
[21] Wit’s official site. http://www.logicalvision.com/.
134
BIBLIOGRAFÍA
135
[22] Florian Adolf. OpenCV’s Rapid Object Detection. Fraunhofer Institute for Autonomous
Intelligent Systems Sankt Augustin, Germany, 2003.
[23] J. Angulo and R. Madrigal. Visión Artificial por Computador. Paraninfo, 1986.
[24] Intel Corporation. OpenCV Reference Manual. 2001.
[25] J. L. Crowley. Vision as process. Springer, 1994.
[26] M. Dimitrijevic, V. Lepetit, and P. Fua. Human body pose detection using bayesian
spatio-temporal templates. Computer Vision and Image Understanding, December
2006.
[27] Working Group for Video Audio Architectures Compression. Information Technology
Council Subcommittee for Video on Demand. University of Utah, 2005.
[28] Internet Engineering Task Force. Real Time Streaming Protocol (RTSP). Columbia
University, 1998.
[29] Internet Engineering Task Force. RTP: A Transport Protocol for Real-Time Applications. Columbia University, 2003.
[30] K. Gruneberg, L. Celetto, and E. Quacchio. SVC Encoding/Delivery Platform Description. ASTRALS, 2007.
[31] Rainer Lienhart and Jochen Maydt. An Extended Set of Haar-like Features for Rapid
Object Detection. Intel Labs, Intel Corporation, Santa Clara, 2003.
[32] Steve Mack. Streaming Media Bible. Hungry Minds, 2002.
[33] Jiri Matas and Jan Sochman. AdaBoost. Centre for Machine Perception Czech Technical
University, Prague.
[34] Raúl Igual Carlos Medrano. Tutorial de OpenCV. Computer Vision Lab, 2007.
[35] Domingo Mery. Visión por Computador. Departamento de Ciencia de la Computación
Universidad Católica de Chile.
[36] Julien Pilet, Vincent Lepetit, and Pascal Fua. Fast non-rigid surface detection, registration and realistic augmentation. International Journal of Computer Vision, January
2007.
[37] José Francisco Vélez Serrano, Ana Belén Moreno Dı́az, and Ángel Sánchez Calle.
[38] Linda Shapiro. Computer Vision. Washingtong University, 2002.
[39] Damien Stolarz. Mastering Internet Video: A Guide to Streaming and On-Demand Video. Addison-Wesley Professional, August 2004.
[40] J.Andrés Somolinos Sánchez. Avances en robótica y visión por computador. Ediciones
de la Universidad de Castilla-la Mancha, 2002.
BIBLIOGRAFÍA
136
[41] Paul Viola and Michael J. Jones. Rapid Object Detection using a Boosted cascade of
simple features. IEEE CVPR, 2001.