Desarrollo de una plataforma basada en dispositivos Android para centralizar la informacion proveniente de camaras de seguridad privadas

Vista previa del material en texto

Trabajo Final
Ingeniería de Sistemas - Facultad de Ciencias Exactas - UNICEN
TEMA: Desarrollo de una plataforma basada en dispositivos Android para centralizar la
información proveniente de cámaras de seguridad privadas.
Alumnos:
● Casabó, Santiago.
● Maly Varni, Mateo.
Director: Dr. Rubiales, Aldo.
Co-Director: Ing. Domínguez, Leonardo Daniel.
A nuestra� familia�, amig�� � docente� po� acompañarn��
� l� larg� d� est� carrer�.
Mucha� gracia� � tod��.
Índice de Contenidos
1. Introducción Pág. 1
a. Motivación Pág. 1
b. Estado del arte Pág. 4
c. Metodología Pág. 5
d. Objetivos Pág. 6
e. Requisitos Funcionales Pág. 7
f. Estructura del Documento Pág. 9
2. Contexto Pág. 10
a. La Arquitectura Kurento Pág. 11
b. El problema detrás de NAT Pág. 13
c. Protocolos de envío y negociación Pág. 14
d. ¿Por qué utilizar Android? Pág. 14
e. Herramientas Pág. 15
i. WebRTC Pág. 15
ii. GStreamer Pág. 16
iii. FFmpeg Pág. 16
iv. Firebase Pág. 16
v. OwnCloud Pág. 18
vi. OpenCV Pág. 18
vii. TensorFlow Pág. 19
3. Desarrollo Pág. 20
a. El Sistema Pág. 20
b. Flujo de la aplicación: Interfaz de usuario Pág. 23
c. Estructuras de datos utilizadas Pág. 27
i. Cámara Pág. 27
ii. Archivos de video Pág. 28
iii. Dispositivos Pág. 28
d. Proceso de implementación Pág. 28
e. Resultados y pruebas preliminares Pág. 32
f. Implementación mediante FFmpeg Pág. 33
g. Consumo de Recursos: FFmpeg y GStreamer Pág. 37
i. CPU Pág. 37
ii. Memoria Principal (RAM) Pág. 38
iii. Uso de la red Pág. 39
iv. Consumo de energía Pág. 40
h. Organización de archivos Pág. 40
i. Eventos Pág. 42
j. Análisis funcional Pág. 43
i. Flujo funcional: Grabación Pág. 44
ii. Flujo funcional: Streaming Pág. 46
iii. Flujo funcional: Sincronización de archivos Pág. 48
k. Chequeos de conexión Pág. 51
l. Administración de almacenamiento Pág. 52
i. Cálculo efectivo de espacio requerido Pág. 53
ii. Administración dinámica de almacenamiento Pág. 55
iii. Asignación de memoria basada en bloques Pág. 56
iv. Escogiendo una alternativa Pág. 57
m. Procesamiento de imágenes Pág. 59
i. Herramientas y características Pág. 59
ii. Detectando objetos: Esquema de Funcionamiento Pág. 62
n. Resultados: Tiempo de procesamiento y uso de recursos Pág. 63
i. Comparación de rendimiento: Modelo optimizado para móviles
Pág. 63
ii. Uso de recursos del módulo de detección en móviles Pág. 65
o. Experiencia con el departamento de servicios de la Municipalidad de Tandil
Pág. 67
4. Conclusiones y trabajo futuro Pág. 70
5. Anexo Pág. 72
6. Bibliografía Pág. 82
Índice de Figuras
1. Arquitectura de Kurento Pág. 11
2. Diagrama de alto nivel de la arquitectura del sistema Cámaras Privadas Tandil
Pág. 13
3. Arquitectura del sistema de CámarasPrivadasTandil Pág. 21
4. Flujo de la aplicación CámarasPrivadasTandil Pág. 26
5. Consumo de CPU por parte de un proceso GStreamer Pág. 37
6. Consumo de CPU por parte de un proceso de FFmpeg Pág. 38
7. Consumo de memoria principal por parte de GStreamer Pág. 38
8. Consumo de memoria principal por parte de FFmpeg Pág. 39
9. Uso de red por parte de FFmpeg (Grabación). Las líneas azules representan la
recepción de datos mientras que la amarilla el envío de los mismos Pág. 39
10. Consumo de energía por parte de FFmpeg Pág. 40
11. Jerarquía para la organización interna de archivos dentro del dispositivo Pág. 41
12. Jerarquía para la organización de archivos en el servidor OwnCloud Pág. 41
13. Esquema de funcionamiento de un watcher Pág. 45
14. Flujo del proceso de grabación de video Pág. 46
15. Flujo del proceso de envío de video Pág. 48
16. Flujo del proceso de sincronización de archivos (solicitudes) Pág. 50
17. Flujo del proceso de sincronización de archivos (envío automático) Pág. 51
18. Esquema de alojamiento utilizando umbrales Pág. 55
19. Arquitectura presente de OpenCV en la manipulación de I/O Pág. 60
20. Esquema de funcionamiento del módulo de detección de objetos Pág. 62
21. Esquema final de funcionamiento del módulo de detección de objetos Pág. 63
22. Gráfico comparativo de los tiempos de procesamiento Pág. 64
23. Uso de energía por parte del módulo de detección de objetos Pág. 65
24. Uso de memoria principal por parte del módulo de detección de objetos Pág. 66
25. Uso de CPU por parte del módulo de detección de objetos Pág. 66
26. DVR en la sección de servicios de la Municipalidad de Tandil Pág. 67
27. Captura de la cámara en el depósito de camiones Pág. 68
28. Captura de la cámara en la gasolinera Pág. 69
29. Pantalla de Ingreso a la aplicación Pág. 72
30. Pantalla de creación del dispositivo (asignación de nombre) Pág. 72
31. Pantalla de creación del dispositivo (completar domicilio) Pág. 73
32. Menú principal de la aplicación sin ninguna cámara asociada Pág. 73
33. Menú principal de la aplicación con una cámara asociada (opciones sin desplegar)
Pág. 74
34. Menú principal de la aplicación con una cámara asociada (opciones desplegadas)
Pág. 74
35. Tarjeta de una cámara durante el proceso de grabación Pág. 75
36. Tarjeta de una cámara durante el proceso de streaming Pág. 75
37. Pantalla de creación de cámaras (asignación de nombre) Pág. 76
38. Pantalla de creación de cámaras (asignación de IP) Pág. 76
39. Pantalla de creación de cámaras (descubrimiento de dispositivos) Pág. 77
40. Pantalla de selección de canales para cámaras Pág. 77
41. Pantalla de selección de canales para NVRs/DVRs Pág. 78
42. Pantalla para completar el registro de la cámara, o para continuar en caso de contar
con usuario Pág. 78
43. Pantalla para completar la contraseña de la cámara y finalizar su integración
Pág. 79
44. Pantalla de visualización en vivo Pág. 79
45. Pantalla de visualización de los registros Pág. 80
46. Menú de ajustes de una cámara Pág. 80
47. Pantalla de opciones de grabación Pág. 81
48. Pantalla de opciones de streaming Pág. 81
Índice de Tablas
1. Valores para las fronteras utilizados en dispositivos con menos de 8GB de
almacenamiento Pág. 56
2. Valores para las fronteras utilizados en dispositivos con más de 8GB de
almacenamiento Pág. 56
3. Tiempos de procesamiento Pág. 64
4. Especificaciones de los equipos utilizados para ésta prueba Pág. 64
Introducción
Motivación
La reducción de costos y tiempos en el desarrollo tecnológico, han generado en los últimos
años una masificación de dispositivos electrónicos. Así, la evolución es apabullante. Si se
observa por ejemplo el proceso histórico de los microprocesadores, veremos que en 1971, el
Intel 4004 construido con 2300 transistores, era capaz de procesar 92000 instrucciones por
segundo [1] (0.092 MIPS) con una velocidad máxima de 740 kHz. 22 años más tarde, en 1993,
Intel lanzó el Intel Pentium, construido con 3.1 millones de transistores y una velocidad
máxima de 100 MHz, capaz de procesar 188 MIPS (2043 veces más rápido) mientras que 27
años después, en 2020, el AMD Ryzen 3990X alcanzó los 2356230 MIPS a 4.35 Ghz (12533
veces más rápido que el Pentium) [2]. Pero este drástico aumento en la capacidad y
velocidad de procesamiento no fue (ni es) el único gran avance realizado en las últimas
décadas. Por su parte, las telecomunicaciones han sufrido un cambio muy significativo
desde la aparición de ARPANET en la década de los ‘60 hasta la aplicación masiva de fibra
óptica en la actualidad: redes de gran tamaño y alta velocidad utilizadas para todo tipo de
aplicaciones desde transmisiones multimedia a ofimáticas de uso compartido [3] [4].
Sin embargo, estos procesos no se han llevado adelante de forma homogénea en todo el
mundo, sino que uno se ha visto más beneficiado que otro. Es el caso de nuestro país por
ejemplo, cuya infraestructura en telecomunicaciones no se encuentra lo suficientemente
desarrollada. Basta con alejarse de los grandes centros urbanos para evidenciar que incluso
los servicios de telefonía móvil no cuentan con una cobertura decente en un mundo dónde
se comienza a implementar de forma masiva el 5G. Pero si a esta situación se la compara con
la variedad de dispositivos y gamas de estos, nos encontraremos con una grata sorpresa:existe una gran capacidad de cómputo en los hogares de cada uno de los argentinos, desde
computadoras a teléfonos de última generación.
Esta capacidad de adquisición de dispositivos se ha visto incrementada últimamente tanto
en el mundo como en la Argentina, y en particular por sectores vinculados a la seguridad
con la adquisición de equipos de vigilancia. No resulta novedoso encender la televisión, o
abrir Twitter para recibir una ola de noticias sobre inseguridad tanto en la vía pública como
en los hogares de los ciudadanos. Con esta situación, tanto gobiernos como los particulares
se han hecho con cámaras de seguridad utilizadas para monitorear sitios de interés: el
1
primero las utiliza en espacios públicos como calles, plazas e instituciones; mientras que los
segundos en sus hogares y locales. En el caso de los actores públicos, estas cámaras son
gestionadas en general por un centro de monitoreo o CM, un agente público o privado que
tiene acceso a las imágenes. En la ciudad de Tandil, es el municipio el ente estatal encargado
de gestionar su propio sistema de cámaras de vigilancia (Anónimo), tarea llevada a cabo por
el centro de monitoreo de la ciudad. Pero es el municipio el encargado tanto del
mantenimiento de los equipos como de su adquisición [5].
La mayoría de los municipios de tamaño medio de la República Argentina tiene su propia
infraestructura de servidores, cámaras y red de alta velocidad que permite la transmisión en
tiempo real de video desde los distintos puntos de la ciudad. Generalmente estos videos son
almacenados de manera centralizada en un data center propio. El aumento de la calidad de
imágen de las cámaras, la cantidad de cámaras requeridas, y del costo de los equipos y
mantenimiento de las redes hace que para los Municipios cada vez sea más difícil estar a la
altura de los requerimientos actuales de la población. Esto hace que se deba pensar en
nuevos enfoques públicos/privados y descentralizados que permitan disminuir los costos
de tener un conjunto administrado de dispositivos registrando video en tiempo real.
Los mismos ciudadanos, comercios, estaciones de servicio u otros espacios, que no contratan
los sistemas de monitoreo, aún así suelen tener cámaras de vigilancia conectadas a una red
local que les permite observar el entorno que les rodea. Pero, ¿Es posible diseñar un sistema
capaz de integrar un conjunto de cámaras de diferentes fabricantes para así ofrecer un
servicio confiable de monitoreo? Pues la respuesta a esta pregunta es si. Sin embargo, esto
requiere que la cámara deba poder ser accedida desde fuera de la red privada. Para sortear
este obstáculo podría accederse al flujo de vídeo de forma pública, lo que implicaría que el
usuario realice una serie de pasos para configurar los equipos, para lo cual debería contar
con ciertos conocimientos técnicos que no necesariamente pueda tener. A su vez, a pesar de
que fuera capaz de realizar dicha tarea, implicaría una pérdida de seguridad por su parte, ya
que cualquier usuario podría acceder a la cámara y ver qué es lo que ocurre (aunque se
pueda agregar un usuario y una contraseña, exponer el dispositivo a internet, no es algo
recomendado). Es por esto que es necesario tener en cuenta que el sistema sea fácil de
instalar, previniendo además que el usuario exponga su privacidad. Para lograr esto, se
plantea la utilización de un dispositivo en los diferentes sitios que requieran de monitoreo, y
que este sea el responsable de realizar las grabaciones o enviar el video en caso de que el
centro de monitoreo así lo requiera. En principio, las grabaciones se harían localmente, lo
que evita el uso de la nube para su completo almacenaje. Ahora, si es necesario algún
2
archivo de video para su análisis por parte del centro de monitoreo, este podrá ser enviado a
través de internet (On-Demand). Además, será posible enviar las imágenes en tiempo real
hacia el sistema utilizado por el servicio de vigilancia, lo que da acceso inmediato a los
sucesos.
Asimismo, en este trabajo se propone aplicar los conceptos de Fog Computing o Edge
Computing [6] a los sistemas de video vigilancia buscando distribuir no sólo el
procesamiento de video sino también las necesidades de almacenamiento de los mismos. A
su vez, también se busca prescindir de una red de alta velocidad dedicada, y permitir que la
coordinación de los dispositivos y transferencia de video se realice a demanda utilizando los
enlaces de Internet de cada particular en forma óptima (por ejemplo si dos operadores
quisieran acceder al streaming de una cámara, solo se iniciaría una conexión al domicilio
particular).
Este proyecto se encuentra incluído dentro de SmartCam [7], una plataforma utilizada para el
análisis inteligente de video desarrollado por PLADEMA en conjunto con la Municipalidad
de Tandil. El mismo surge de la necesidad de incluir más cámaras, y en particular, equipos
desacoplados a la red de fibra óptica dispuesta por este último, de modo de poder
transportarlas de un punto a otro, en base a la demanda temporal (por ejemplo ante un
evento multitudinario, o en regiones con alguna problemática temporal). Una Smartcam es
un equipamiento de monitoreo y almacenamiento por video con capacidad de
procesamiento “in-situ” y acceso remoto vía 4G o WiFi local, utilizando técnicas de análisis
de imágenes gracias a la incorporación de una computadora robustecida conectada
directamente a la cámara y preparada para soportar cambios en las condiciones climáticas y
variaciones o cortes de suministro eléctrico (ya que cuenta con un sistema propio de
baterías).
El sistema tiene además, un módulo de software que opera como un monitor del
equipamiento, el cual reporta y genera alertas en casos de situaciones anormales. Los
sensores con los que cuenta el equipo son:
● Temperatura interna del equipamiento
● Apertura de puertas
● Tensión eléctrica y nivel de carga de la batería
● Tipo de conectividad
3
Actualmente el Municipio cuenta con un número cercano a 10 de estos dispositivos y dado
que el costo de estos dispositivos no es económico, es por eso que surge la necesidad de
integrarse con cámaras privadas, lo cual se alinea con el objetivo de la presente tesis.
Estado del arte
Actualmente las herramientas de las que se dispone para realizar tareas de vigilancia
resultan ser de lo más variadas tanto en los servicios que ofrecen como en la forma de
monetizarlo. Servicios como BriefCam1 permiten no sólo la grabación de las imágenes
captadas por las cámaras, sino también la posibilidad de realizar diversos análisis de las
mismas (ya sea reconocimiento facial o de objetos) haciendo uso de inteligencia artificial,
además de ofrecer un servicio de alertas personalizado. Otros como Angel Cam2 permiten,
mediante la adquisición de un dispositivo denominado AngelBox, conectar cámaras ip
locales para almacenar los videos en la nube, y observar tanto las imágenes en vivo como las
grabadas. Algunos de estos servicios son gratuitos y otros están disponibles luego del pago
de una suscripción mensual. La ventaja o lo disruptivo del servicio, es que con solo encender
y establecer la ubicación de las cámaras, ya se puede hacer uso completo del servicio sin la
necesidad de configuraciones técnicas sobre el router del hogar, ofreciendo así un servicio
plug and play.
Sin embargo, esta clase de servicios que requieren de una estable y rápida conexión a
internet resultan difíciles de implementar aquí, además de la dificultad de encontrar este
tipo de soluciones dada la situación para importar [8], por lo que debe optarse por otro tipo
de solución. Es por esto que se propone, en lugar de utilizar la nube en forma exclusiva para
el almacenamiento de los archivos, también hacerlo del disco interno de artefacto. De esta
manera no solo se permite aligerar los consumos de red, sino también permite distribuir la
responsabilidad de un hipotético servidor central. Los videos podrán ser accesibles desde la
nube,siempre en cuanto sean explícitamente solicitados, evitando también el mantenimiento
rutinario eliminando archivos no utilizados.
En lo referente al análisis de las imágenes, generalmente es realizado en servidores que
manipulan los videos almacenados en un repositorio remoto. En este proyecto se pretende
realizar pruebas preliminares que permitan, a modo de concepto, aligerar la responsabilidad
y la carga a estos aplicando conceptos de Edge Computing. Este paradigma plantea la
realización de tareas de procesamiento y análisis lo más cercano a la fuente de los datos
2 https://www.angelcam.com/
1 https://www.briefcam.com/
4
como sea posible. Este tipo de prácticas permitirá una reducción tanto en los tiempos de
respuesta así como en el ancho de banda. Es importante mencionar que este concepto no es
un sinónimo de Internet de las cosas (IoT [9]), ya que este último resulta ser una tecnología
incluída dentro de Edge Computing, tratándose en particular de una arquitectura y no de un
paradigma. Por lo tanto, para terminar de definir este concepto, se trata de aligerar la carga
en los servidores y la transmisión de datos al realizar tareas computacionales en los sectores
más cercanos a las fuentes. Generalmente quien se termina acercando a la fuente es el
servidor el cual cuenta con el poder de cómputo necesario para abarcar los procesamientos
más demandantes, pero resultaría costoso de implementar y de mantener para una ciudad
no muy extensa, como para el escenario planteado en este proyecto. En este caso particular
se introduce el concepto de mobile computing [10], lo que hace referencia al uso de
dispositivos móviles como los encargados de realizar las tareas de procesamiento y análisis,
para luego enviar solo información necesaria o ya pre-procesada, logrando de esta manera
atenuar tanto la carga total de procesamiento en los servidores y el ancho de banda necesario
para enviar el video capturado por las cámaras.
Metodología
El proyecto constó de 4 etapas. En la primera de ellas, se evaluó y recopiló información sobre
las diferentes alternativas a la hora de enviar video en tiempo real desde un dispositivo
Android. Esta etapa concluyó con una aplicación móvil de demostración que enviaba video
de una cámara pública a una aplicación web de pruebas dónde se observaba el video
emitido.
En la segunda se procedió a organizar los diferentes requisitos del sistema dentro de lo que
serían las pantallas de la aplicación, las cuáles una vez establecido su comportamiento, se
comenzó a implementar las mismas tanto visual como funcionalmente. En esta etapa
también se estableció la existencia de usuarios quienes cuentan con credenciales de
autenticación, lo que derivó en un sistema de reconocimiento para los mismos.
En la tercera se integró una base de datos en la nube tanto para la autenticación de usuarios
como para los dispositivos de estos y las cámaras con las que están asociadas, además de
incluir el escritor de archivos (que serán manipulados en una etapa posterior).
Finalmente, se trataron cuestiones relacionadas con la estabilidad de la aplicación y control
de concurrencia, temas que se abordarán con mayor profundidad en otros capítulos.
5
Objetivos
En primera instancia, desde la perspectiva del tratamiento de multimedia, se espera que la
aplicación sea capaz de realizar las siguientes tareas en simultáneo utilizando la menor
cantidad de recursos posibles de la forma más eficiente, ya que al utilizar esta clase de
dispositivos Android los recursos con los que se cuentan son más reducidos que en
cualquier otra plataforma:
● Permitir dar de alta cámaras IP o NVRs/DVRs para monitoreo.
● Grabar vídeo de forma contínua almacenando los archivos generados dentro del
almacenamiento local o extraíble del dispositivo. La calidad de la grabación deberá ser
lo mejor posible.
○ El video podrá ser solicitado por la central de monitoreo. En caso de que esto
ocurra deberá sincronizarse con un repositorio en la nube para su posterior
reproducción. Esto no deberá impedir que la aplicación siga grabando el
video de las cámaras.
○ El ciclo de grabación deberá regular el espacio utilizado. Para ello, se
eliminarán los archivos con mayor antigüedad, siguiendo un esquema FIFO
[11].
● Listar y visualizar los videos registrados por cada cámara.
● Enviar video de una cámara en tiempo real desde un dispositivo android con la menor
latencia posible cuando se lo solicite desde el centro de monitoreo.
○ Hay muchos factores a considerar a la hora de enviar video que pueden
afectar la transmisión del mismo: conectividad, procesamiento de imágenes o
uso de memoria. Es por esto que se debe hacer un balance entre estos para
obtener la mejor imagen posible en el menor tiempo.
○ En caso de que ocurra un error en la transmisión, ya sea por una falla debido
a alguna de las causas mencionadas anteriormente, la aplicación se deberá
recuperar automáticamente del fallo.
● Permitir al usuario ver en vivo cualquiera de las cámaras asociadas a la aplicación.
6
● Se debe notificar al usuario en todo momento el estado del sistema. Es decir, debe estar
al tanto del momento en que una cámara se encuentra compartida, grabando o
enviando video al centro de monitoreo.
● El usuario podrá controlar en todo momento cualquiera de los ajustes de la cámara
(compartir, grabar, entre otros).
● Se deberá iniciar el sistema de forma automática ante un fallo energético.
Un objetivo que es común a los anteriores mencionados y no hay que dejar de lado es la
eficiencia. Dado que, cómo se dirá más adelante, se está programando para un dispositivo
móvil, por lo que hay que tener demasiado cuidado en lo que se programa, ya que los
recursos son mucho más limitados que en un PC por ejemplo, haciendo este tipo de tareas
un poco más complejas que de costumbre.
Finalmente se plantea como último objetivo el evaluar la inclusión de un módulo de
detección de objetos al sistema en cuestión. Éste módulo se desarrolla como una prueba de
concepto de Edge Computing, permitiendo reducir la carga de procesamiento sobre un
servidor centralizado.
Requisitos Funcionales
Se espera que la aplicación permita realizar las siguientes acciones sin ningún orden en
particular:
● La aplicación debe ser de fácil utilización y navegación para el usuario, ya que el
mismo podrá hacer uso de un control remoto.
● Se debe permitir a los usuarios ingresar en su cuenta haciendo uso de un usuario y
contraseña.
● Un usuario debe poder configurar el dispositivo que utiliza, dotando al mismo de un
nombre y de la dirección del domicilio donde este se encuentra.
7
● Las cámaras deberán contener su URL, junto con un nombre para identificarlas. A su
vez se debe poder modificar sus atributos.
○ En caso de que la información ingresada no se corresponda con ninguna
cámara, se comunicará con un error.
● Debe mostrarse en la pantalla principal la lista de todas las cámaras gestionadas por
la aplicación. De cada una de ellas se mostrará su nombre y una pequeña fotografía
que muestra el lugar al que apunta.
○ Esta lista debe dar acceso a información particular de una cámara cuándo el
usuario desee ver información de alguna de las mismas, indicando si está
siendo transmitida, si está grabando o si la cámara está accesible.
● Por cuestiones de privacidad, el usuario debe poder elegir si desea compartir su
cámara (grabaciones y/o video en vivo).
● Se debe poder iniciar y detener la grabación de archivos de video locales cuando el
usuario así lo desee.
○ El proceso de grabación debe poder llevarse a cabo durante las 48 horas del
día de forma ininterrumpida.
○ Los mismos deben ser alojados dentro del almacenamiento interno del
dispositivo o en el almacenamiento externo en caso de contar con uno.
○ El acceso a dichos archivos de video debe ser directo desde la aplicación,
simplificando la búsqueda de los mismos.
○ En caso de falla de energía, el servicio de grabación debe reanudarse en el
momento en el quela aplicación vuelva a abrirse.
○ Si la cámara no es accesible a la hora de grabar, debe intentar hasta que se
logre conectar o el usuario deshabilite explícitamente el proceso.
○ Se debe poder configurar la calidad de grabación en caso de que el usuario
desee economizar el espacio de los archivos en el almacenamiento.
● La aplicación debe poder responder las peticiones que son enviadas desde la central
de monitoreo.
○ En caso de que se solicite el acceso al video en vivo, solicitud que solo llegará
en caso de que esto sea permitido por el usuario, se debe iniciar la
8
transmisión. El usuario podrá editar la calidad del video a fin de ahorrar
recursos tales como banda ancha y procesador.
○ Ante una petición de un archivo de video se debe sincronizar el mismo con la
nube, haciendo uso de los servicios de un tercero.
● La aplicación debe ser capaz de recuperarse ante un corte en el suministro eléctrico y
mantener los estados de las cámaras consistentes.
● La aplicación deberá integrarse al resto de herramientas que componen la plataforma
SmartCam.
Estructura del documento
En lo referente a la estructura de este documento, el primer capítulo introducirá cuál es el
problema, qué es lo que se quiere lograr y cómo fueron las etapas de desarrollo del proyecto.
En el siguiente se abordan conceptos generales, junto con las herramientas consideradas
para este proyecto junto a las ventajas y desventajas que estas presentan. En la tercera
sección de este documento se comenzará a comentar cuestiones relacionadas con la
implementación de la aplicación como bibliotecas utilizadas y los resultados obtenidos,
principalmente en el módulo de detección de objetos. Finalmente, en el apartado de
conclusiones se resumirán los resultados obtenidos junto con una breve reflexión sobre el
futuro del proyecto que ocupa estas líneas.
9
Contexto
Cuando se trata de manipular multimedia existen varios factores que complejizan la tarea,
más aún si se desea hacerlo en tiempo real. Algunos de estos se encuentran a la hora de
establecer una conexión, como la identificación de cada extremo o los protocolos de
negociación, y otros que permiten que la transmisión a través de la red sea lo más fluida
posible como los protocolos de transmisión o la latencia en la red. Ahora bien, existen
herramientas capaces de tomar en consideración todos estos factores logrando reproducir,
almacenar y compartir multimedia: estas son llamadas servidores multimedia (o media
servers en inglés). Algunos de los más populares son Red5 [12], Kurento [13], Wowza y Ant
Media Server3. Para lograr transmitir video en tiempo real se hace uso de WebRTC [14], un
proyecto de código abierto que permite conectar aplicaciones y proveer capacidades de
comunicación en tiempo real (RTC o Real Time Communication). En el caso de Red5, se
cuenta con un servidor multimedia de código abierto que solo ofrece la comunicación por
WebRTC en su versión paga, pero dado que es necesario reducir los costes de
mantenimiento, no se consideró su uso para este proyecto. Por otro lado, el resto de los
servidores multimedia proveen esta funcionalidad, pero aún así no resultan completamente
utilizables: el servicio provisto por Wowza ofrece un periodo gratuito de prueba que dura 30
días con todas las funcionalidades, una vez vencido el plazo se deberá abonar
mensualmente según el plan que se escoja; Ant Media Server tiene una versión gratuita con
todas las herramientas necesarias para lograr lo planteado en el proyecto, pero presenta una
latencia de entre 8 y 12 segundos en la transmisión de video, por lo que no permite que sea
en tiempo real como se desea; finalmente surge Kurento4, herramienta de código abierto que
implementa todas las funcionalidades requeridas sin la necesidad de pagar el servicio,
debido a que se trata de un proyecto financiado entre la Unión Europea y España. Es por
esto que se optó por Kurento para la realización de este proyecto: sus variadas utilidades en
conjunto con su nulo coste, hacen de esta la herramienta ideal. A continuación se
profundizará en los beneficios que conlleva la utilización de Kurento y se explicará más en
detalle algunos de los factores mencionados anteriormente a la hora de manipular
multimedia.
4 Desarrollado en conjunto entre el Ministerio de Economía, Finanzas y Competitividad de España y el Fondo de
Desarrollo Regional Europeo bajo el proyecto LERNIM (RTC-2016-4674-7).
3 https://github.com/ant-media/Ant-Media-Server/wiki.
10
La Arquitectura de Kurento
Tal y como se indicó con anterioridad Kurento es un media server, esto implica que es
utilizado para el almacenamiento y transmisión de multimedia a través de la red. El mismo a
su vez cuenta con una API que abstrae el comportamiento de otra herramienta utilizada
para el intercambio de multimedia llamada GStreamer [15]. La misma será explicada en una
sección posterior. En la figura 1 puede observarse la arquitectura de Kurento, dónde
podemos identificar la existencia de tres componentes principales:
● El Kurento Media Server (KMS), el cual es el encargado de gestionar las
comunicaciones entre los distintos interlocutores. Todo flujo de datos fruto del
intercambio debe pasar por aquí. Además es en este componente donde se pueden
aplicar modificaciones sobre los datos.
● El Kurento Application Server (KAS) es el encargado de regular la comunicación
entre cada uno de los individuos y el servidor, ya que el módulo se encuentra en
constante comunicación con estos.
● Finalmente la aplicación cliente será aquella que utilice el usuario final para enviar o
recibir multimedia.
Figura 1. Arquitectura de Kurento.
La interacción entre estos componentes se puede ver en dos fases separadas: Una de
negociación y la otra de intercambio de multimedia.
11
❖ Fase de negociación: En esta primera etapa el cliente, en caso de este proyecto el
centro de monitoreo, es quien inicia la comunicación hacia el servidor pidiendo algún
tipo de multimedia. En caso de que la multimedia sea en tiempo real, el cliente le
provee al servidor las preferencias deseadas a través de un protocolo llamado SDP
(Session Description Protocol [16]). Cuando el servidor (KAS) recibe la petición, y
según las instrucciones indicadas por el desarrollador, el KMS (Kurento Media
Server) instancia los elementos multimedia acordados y los asocia en un media
pipeline. Una vez creado, se devuelve al cliente el cómo y dónde acceder al contenido
multimedia. Durante este proceso sólo rigen protocolos de señalización.
❖ Fase de intercambio de multimedia: En esta etapa se produce el intercambio de
multimedia, donde el cliente le pide al servidor el contenido según la información
proveída en la etapa anterior.
Si bien ahora se tiene conocimiento de la arquitectura del software que se utiliza, es
necesario adquirir nociones básicas de cómo dotar del comportamiento deseado al software.
Para ello, es necesario comentar qué es un media pipeline y cómo relacionar el concepto
tanto con los usuarios como con los datos que estos desean enviar. Un media pipeline es un
canal por el cual se pueden enviar media elements, para proveer multimedia de una manera
específica, siendo un media element un componente que encapsula comportamiento
multimedia. Esto quiere decir que es posible dotar a este elemento de un comportamiento al
cual pueden someterse los datos de audio y video. Con Kurento se suelen utilizar dos tipos
de elements: endpoints y filtros. Los primeros representan a cada agente involucrado en la
comunicación, es decir, emisores y receptores. Como tales, tienen la capacidad de recibir o
enviar contenido multimedia al pipeline. Existen endpoints que describen el intercambio de
datos entre la web y el pipeline (WebRTC, RTP, HTTP [17]) y aquellos asociados a la
manipulación de archivos (grabar o leer).
Los filtros se encuentran en el medio del pipeline y son asociados a estos. Los mismos toman
una fuente de multimedia, le aplican una modificación (yasea un cambio de color o en la
perspectiva de la imagen) y generan una salida modificada fruto de la combinación de los
datos y filtros. Es importante recalcar que una vez asociado un filtro al pipeline, no es
posible disociarlo, por lo que es de vital importancia estar seguro de cuál es el proceso que se
desea llevar adelante.
12
El problema detrás de NAT
Se cuenta con una herramienta que es capaz de dar solución a nuestra necesidad de ofrecer
un servicio de calidad, pero existe una barrera que debe ser sobrepasada. El identificar los
actores que realizan la comunicación parece tratarse de un proceso trivial de localización de
interlocutores. Pues nada más lejos de la realidad. Debido a la utilización masiva de IPv4, lo
más probable es que la gran mayoría de usuarios se encuentren detrás de un NAT [18] que
garantice su acceso a internet. Esta situación dificulta el proceso de conexión ya que no se
sabe hacia dónde hay que transmitir la información. Para esto, es necesario utilizar STUN o
TURN [19]. La primera alternativa consiste en utilizar un servidor para obtener las
direcciones IP externas para luego comenzar con el proceso de comunicación; mientras que
la segunda se sustenta en el uso de un retransmisor, es decir, recibe datos del emisor y es este
quién debe garantizar el envío de la información hacia el receptor. Cabe destacar que TURN
soporta STUN. Generalmente se utiliza en principio STUN ya que es menos costoso, y en
caso de que no se obtenga una respuesta, se procede a utilizar TURN. En el caso de Kurento
se recomienda utilizar Coturn, una herramienta que permite la configuración de servidores
TURN y STUN.
Figura 2. Funcionamiento de TURN y STUN detrás de NAT.
13
Protocolos de envío y negociación
Existen múltiples enfoques para la transmisión de audio y video, pero en este trabajo se hará
hincapié en la comunicación en tiempo real. Para ello es necesario utilizar RTP o Real-Time
Transport Protocol [20], un protocolo diseñado para transmitir datos en tiempo real. De esta
manera, es posible transmitir multimedia prácticamente al mismo tiempo que se emite
despreciando un retardo entre la grabación y la realidad que siempre se encuentra presente
(por supuesto, con el objetivo de reducir al mínimo estos retardos).
Con RTP se busca entregar los paquetes que contienen datos multimedia de la manera más
rápida posible, pero es necesario para poder enviar estos que se haya establecido algún tipo
de conexión entre el emisor y el receptor del flujo multimedia. Es aquí cuando SDP entra en
acción. Este protocolo es utilizado para el establecimiento de sesiones, por las cuales se
transmitirán los datagrams de audio y video. Para ello, se pueden identificar tres
necesidades: anuncio de sesión, es decir, existe un usuario que desea establecer una conexión
con otro; la invitación a la sesión, donde el emisor envía formalmente una solicitud para
establecer la conexión; y finalmente la negociación de parámetros, donde ambos actores se
comunican estableciendo condiciones particulares para el intercambio (ya sea número de
puerto, tamaño de los paquetes, velocidad de transmisión y formato de los datos).
¿Por qué utilizar Android?
En los últimos años se ha popularizado el desarrollo de aplicaciones móviles en diversos
campos, ya sea en el desarrollo de aplicaciones para el estudio de la química del carbono
hasta los más variados juegos [21]. Y es algo que resulta más que lógico: el poder llevar
nuestra información y nuestras necesidades a cualquier lado es algo que se ha naturalizado
de forma anormal. Sin embargo, a pesar de que la informática ha realizado avances
sorprendentes en los últimos años, eso no quiere decir que resulte sencillo la programación
para este tipo de dispositivos. Los recursos con los que estos cuentan en su mayoría
continúan siendo escasos en comparación con los de una PC de escritorio o laptop, lo que
limita (al menos, hasta ahora) las posibilidades de estos. Pero incluso a pesar de esto, se ha
escogido como plataforma de desarrollo. Esto se debe a que a dos factores:
● Alta disponibilidad: Si bien alguien puede no contar con un equipo de escritorio o
portátil, es altamente probable que cuente con un dispositivo móvil o tablet que haga
14
uso de Android. Esto se debe a que prácticamente todos los grandes fabricantes de
dispositivos móviles incluyen en los suyos éste, lo que permite que se encuentre de
forma más fácil y a precios más accesibles debido a que cada uno de ellos
generalmente cuenta con tres gamas de dispositivos: gama baja, media o alta
(algunos contando con variantes intermedias, tales como la gama media-alta,
contando con prestaciones de ambas categorías), haciendo que prácticamente
cualquiera pueda hacerse con uno.
● Costo: De forma masiva, podemos identificar la existencia de dos sistemas
operativos: Android (desarrollado por Google) e iOS (desarrollado por Apple). Los
costes de adquisición del primero, si bien dependen de la gama del dispositivo,
tienden a ser menores que los del segundo. Además hay que tener en cuenta que es
necesario pagar para utilizar la plataforma de desarrollo de Apple, mientras que en
Android se puede desarrollar sin la necesidad de invertir dinero alguno.
La aplicación Android realizada para este proyecto puede ser ejecutada por cualquier
dispositivo (dentro del rango de versiones especificados), pero su principal destinatario son
aquellos denominados AndroidTV. Estos aparatos cuentan con el poder de procesamiento
necesario para actuar como un gestor de cámaras privadas y son más económicos que otros
dispositivos que cuentan con características similares, como por ejemplo, un raspberry pi. El
objetivo detrás de correr la aplicación en un dispositivo aparte de un teléfono móvil es por el
hecho de que siempre debe estar disponible para el correcto funcionamiento del sistema, es
decir con acceso a internet y encendido, estado en el que un dispositivo móvil no siempre se
encuentra.
Herramientas
A lo largo de este proyecto se han usado diversas herramientas para poder ofrecer las
funcionalidades requeridas. A continuación se comentarán éstas, junto con una breve
descripción de las mismas.
WebRTC
Como se ha comentado anteriormente, WebRTC son las siglas para Web Real Time
Communication (en español, Comunicación Web en Tiempo Real), es un framework de código
abierto que ofrece una alta calidad a la hora de establecer comunicaciones que requieren el
15
intercambio multimedia tales como las videollamadas o los chats por voz, por lo que busca
no limitarse solo a plataformas de escritorio sino también a las móviles o incluso en
dispositivos IoT intentando proveer mecanismos comunes para la interacción entre los
mismos.
Además se encuentra implementado en navegadores de amplia difusión como lo son Google
Chrome y Mozilla Firefox, buscando convertirse en un nuevo estándar en las
telecomunicaciones actuales.
GStreamer
GStreamer es un framework para la comunicación audiovisual basada en pipelines, es decir,
requiere establecer un canal para la manipulación de los datos. Se puede dotar a este
componente con múltiples comportamientos tales como la aplicación de filtros de video
(cambio de color o reconocimiento facial) y mecanismos de codificación y decodificación de
multimedia, además de operaciones sobre la misma tales como recorte, extracción de
segmentos particulares y su combinación, entre otras. La desventaja que presenta es que
ocupa más espacio si se lo compara con otro tipo de frameworks.
FFmpeg
De manera similar que GStreamer, FFmpeg [22] es un framework de código abierto capaz de
manipular contenido multimedia y altamente portable para integrar en sistemas. La
herramienta cuenta con bibliotecas que pueden ser utilizadas en aplicaciones y contienen lo
necesario para realizar la transmisión de video en tiempo real o para grabar el material de
un video en un sistema de archivos local, que como se ha mencionado en el apartado de
objetivos,estas operaciones son requeridas para el proyecto. En particular, se destaca por
soportar gran cantidad de codecs esenciales y altamente difundidos y filtros. Sin embargo, no
provee mecanismos a la hora de implementar entrada/salida (I/O) para audio y video.
Firebase
La aplicación contará con un sistema de usuarios, los cuáles para ingresar a la aplicación
requerirán de un usuario y una contraseña que ya tendrán asignados (por parte de los
administradores) al momento de utilizar la misma. Esto requiere entonces, de una base de
datos en donde almacenar y verificar los datos de autenticación, así como también la
información de sus cámaras de video. Con esto en mente, es posible lograr los objetivos
16
anteriores haciendo uso de una base de datos local o remota. La primera de las alternativas
queda descartada debido a que sería necesario contener una copia de la base de datos en
cada dispositivo para poder asegurar no solo el ingreso del usuario a sus cámaras sino la
información de estas. Esta situación solo nos deja con una alternativa: el uso de una base de
datos remota. Existen múltiples servicios que son capaces de proveer la funcionalidad
necesaria, pero en este proyecto se hará uso de Firebase, más concretamente de la
herramienta Firestore5. El mismo consiste en una base de datos no relacional [23] alojada en
servidores gestionados por Google, los cuáles permiten no solo el acceso a datos remotos,
sino que también cuentan con una gran ventaja como lo es su uso bajo condiciones de cero
conectividad. Esto quiere decir que si durante unos momentos el dispositivo no cuenta con
acceso a internet, dentro del mismo se almacena la estructura de la base de datos
perteneciente al usuario actual. Una vez que el internet vuelva a estar disponible, todas las
actualizaciones realizadas en la copia local se transmitirán al servidor de inmediato,
solucionando cualquier inconsistencia que pueda haber sido generada.
En lo que respecta a la estructura de la base de datos, Firestore organiza los datos dentro de
colecciones llamadas collections. A su vez, en el interior de las mismas se almacenarán los
llamados documents, que contendrán los atributos de los elementos que representen u otras
colecciones. Por ejemplo, para este trabajo podríamos identificar una colección de usuarios,
donde cada uno puede contar con un nombre completo, la dirección de su domicilio y un
número de teléfono, junto con una colección de cámaras, que contendrá cada una de las
cámaras que el usuario posee. Cabe recalcar que los atributos de los documentos son
representados por un único tipo primitivo: si el atributo “número de teléfono” está
representado por una cadena de caracteres, siempre esa instancia del atributo tendrá dicho
tipo.
En lo que respecta a la funcionalidad proveída por Firebase Firestore, alguna de las
utilizadas en este proyecto son:
● Observers/Listeners: Como se comentará en una futura sección, habrá situaciones
en las que ciertos eventos de la aplicación se activarán ante el cambio en un valor de
un atributo en la base de datos. Es posible desencadenar estas acciones haciendo uso
de listeners.
5 https://firebase.google.com/docs/firestore.
17
● Autenticación: Firebase incluye un sistema de autenticación basada en usuarios.
Cuándo uno ingresa a la aplicación, la base de datos guarda las credenciales del
mismo, permitiendo acceso a la aplicación sin la necesidad de estar reingresando a la
misma cada vez que se abre.
OwnCloud
Como ya se mencionó anteriormente, la aplicación deberá ser capaz de subir archivos de
video que hayan sido solicitados por el centro de monitoreo. Éstos estarán almacenados
localmente dentro del dispositivo o bien en una memoria externa, lo que implica que están
fuera del alcance de los operadores de seguridad que quieran ver el contenido grabado de
una cámara. Para lograr visualizar las grabaciones, es necesario tener algún servidor en la
nube y así compartir estos archivos con el centro de monitoreo. Es por esto que se optó por
hacer uso de la herramienta OwnCloud [24]. Este software actúa como un administrador de
archivos que se encuentra alojado en un servidor en la nube, permitiendo almacenar,
recuperar y organizar archivos de forma sencilla. Además de lo que se pueda esperar de un
servidor en la nube donde se alojarán archivos (almacenamiento, control de versiones,
cifrado), esta herramienta presenta varias ventajas, entre ellas: compartir archivos entre
grupos o usuarios de la base y la administración de los mismos, para lo cual se requieren de
credenciales (ya sea usuario y contraseña o un token de autenticación).
Si bien es vasta la funcionalidad que provee OwnCloud, sólo será de interés lo que compete
a la creación de archivos en un servidor remoto, siempre y cuando se utilicen las
credenciales correctas. Más adelante se abordará con profundidad cómo se llevó a cabo esta
tarea.
OpenCV
A fin de desarrollar el módulo de detección de objetos mencionado anteriormente, es
necesario tener la capacidad de tomar cada frame de un video para poder procesar el mismo.
Con este fin se hará uso de OpenCV, una biblioteca desarrollada para computer vision [25]. La
misma ofrece variadas funcionalidades además de la mencionada anteriormente, como
puede serlo la detección de movimiento, el reconocimiento facial y el reconocimiento de
expresiones.
18
En un futuro apartado se profundizará más en el papel de OpenCV y en las utilidades que el
mismo aportará en este proyecto.
TensorFlow
TensorFlow [26] consiste en una biblioteca desarrollada por Google utilizada en procesos de
inteligencia artificial (más concretamente en Machine Learning [27]), utilizada junto con
OpenCV en el módulo de detección de objetos propuesto en este documento. En particular
se hará uso de TensorFlow Lite, una herramienta recientemente lanzada optimizada para la
ejecución de esta herramienta en dispositivos móviles [28], plataforma a la cual se destina
este proyecto.
19
Desarrollo
En esta sección se detallarán cuestiones relacionadas con la implementación del sistema,
pudiéndose distinguir entre la aplicación Android y el sistema en el cual se integra la misma.
En principio se comentará sobre la arquitectura del sistema para luego continuar con el
desarrollo de la aplicación, elemento principal de este documento.
El sistema
Desde un punto de vista más abstracto, este sistema tendrá dos elementos centrales:
● El dispositivo Android (llamado en la imágen Android TV), el cuál tomará las
imágenes de una/s cámaras de vigilancia. El usuario manipulará los posibles cursos
de acción interactuando con la televisión a la cuál se encuentra el dispositivo
vinculado. Esta clase de elementos cuentan con un control remoto que permite
navegar dentro del sistema al usuario.
Figura 2. Diagrama de alto nivel de la arquitectura del sistema Cámaras Privadas Tandil.
20
● El centro de monitoreo, ente encargado de la visualización de las imágenes, en este
caso en particular se hace referencia al centro mantenido por la municipalidad de
Tandil.
Ambos se comunicarán mediante internet, y almacenarán datos de importancia para el
sistema dentro de una base de datos, la cuál será compartida para ambos. En la siguiente
imagen puede apreciarse su arquitectura. Como puede observarse existen seis elementos que
componen a la misma:
Figura 3. Arquitectura del sistema de CámarasPrivadasTandil.
● La aplicación Android, que contendrá el comportamiento que se ha comentado en la
sección anterior de este documento;
● El servidor OwnCloud, utilizado para el almacenamiento de los archivos de video
que hayan sido solicitados por la aplicación web;
● El componente Firebase Firestore utilizado como base de datos no relacional a lo
largo de todo el proyecto, que contendrá datos de los usuarios, sus cámaras y los
archivos filmados por las mismas;
21
● El servidor Kurento, encargado de gestionar el envío de video y la comunicación
entre el emisor y el receptor multimedia;● La cámara de video (IP Camera), elemento del cual se obtendrá toda multimedia
utilizada a lo largo de este proyecto, incluyendo imágenes y archivos de video;
● Y finalmente una aplicación web utilizada por un centro de monitoreo, principal
interesado en las imágenes obtenidas por las cámaras de los usuarios.
Cómo puede apreciarse, ambas aplicaciones harán uso de la misma base de datos para la
lectura y escritura de los datos (siendo en este caso Firebase Firestore, cómo ya se ha
comentado). Esto también implica que el servidor Kurento que utilizarán será el mismo,
representando el servidor el emisor de video y la aplicación web el receptor de este. Sin
embargo, a la hora de enviar los registros hacia la nube, se utilizará el servicio provisto por
OwnCloud para su almacenaje.
Si el centro de monitoreo desea acceder al video de alguna cámara, se iniciará una petición
desde la aplicación web. Para ello, enviará a Firestore los datos necesarios para iniciar el
proceso de visualización a una colección de alertas asociadas al dispositivo que administra la
cámara que se desea observar. La aplicación por su parte se encontrará monitoreando que se
ingresen entradas a la colección de alertas, y en caso de que esto ocurra, se verificará la
posibilidad de llevar a cabo la tarea deseada. Si la aplicación lo permite, se procederá con el
envío de video. Este procedimiento es similar si en lugar de la imágen de la cámara se
requiere una grabación: nuevamente se envía una solicitud a la colección de alertas la cual,
de ser aceptada por la aplicación, se procederá a enviar una copia del archivo al servidor
(más específicamente a OwnCloud). La única funcionalidad que podrá evocar el usuario por
su cuenta es la grabación de las cámaras, proceso que ocurre exclusivamente dentro del
dispositivo Android.
En lo que respecta a la recepción y envío de mensajes, se comentará en una futura sección
dónde se explique con mayor detalle cómo se implementó el mismo. Obviando este último
comentario, es posible continuar con el próximo punto, en donde se detallará el flujo de la
aplicación.
22
Flujo de la aplicación: Interfaz de usuario
Desde el punto de vista estructural del programa, al tratarse de una aplicación móvil,
podemos identificar en principio un componente básico: las pantallas. Dentro de las mismas,
el usuario interactúa con la aplicación a la hora de, por ejemplo, añadir una cámara o iniciar
una grabación. La pantalla que dará la bienvenida al sistema será la de ingreso. La misma se
compone de dos campos para completar: el correo electrónico utilizado por el usuario y su
contraseña. Una vez ingresados estos datos, se debe presionar el botón acceder, el cual
procederá a validar la identidad del cliente. En caso de que se haya verificado de forma
exitosa, la aplicación le permitirá continuar. De no ser así, se notificará al mismo que no se ha
podido verificar la existencia de un usuario con esas credenciales.
Dependiendo de los datos que se encuentren en el dispositivo, la pantalla que procederá al
inicio puede variar ante las siguientes condiciones:
● Si la aplicación no cuenta con un dispositivo registrado, ingresará a la pantalla de
creación de dispositivos.
● Si el usuario ya ha creado el dispositivo, se procederá al menú principal.
En todos los casos anteriores no es necesario el reingreso de las credenciales del usuario ya
que estas quedan cargadas en el dispositivo. En principio se comentará el flujo de la
aplicación siguiendo las condiciones establecidas en el primero de los puntos mencionados
anteriormente, más específicamente el caso en el que un usuario ingresa por primera vez a la
plataforma.
En ese caso no contará con ningún dispositivo asociado, por lo que deberá registrar uno.
Para ello deberá ingresar el nombre que desea darle, junto con la dirección geográfica en la
que se encuentra. Luego, al apretar el botón crear, se procederá al menú principal, dónde se
le dará la posibilidad de crear una nueva cámara para el dispositivo. El usuario deberá
escoger la opción Añadir. Esto abrirá una pantalla en la que se solicitará en primera instancia
el nombre que identificará a la cámara que se dará de alta. Si el nombre ingresado
corresponde a uno ya en uso dentro del dispositivo, se comunicará que debe de escoger otro.
De continuar con el proceso, se procederá a la pantalla de selección de IP, dónde el usuario
23
completará la dirección asociada a la cámara/NVR/DVR dentro de su red. Existen dos
posibles caminos a seguir para completar dicha información:
1) El usuario conoce la dirección, por lo que procede a colocarla en forma manual.
2) El usuario ignora la dirección, por lo que podrá hacer uso de un módulo de
descubrimiento de dispositivos6. Para hacer uso del mismo, el usuario deberá escoger
la opción Descubrir Dispositivos. La misma ejecutará una rutina que barre la subred en
la que se encuentra el dispositivo e intentará conectarse a cada uno de los 255 host de
la misma. De cada uno descubierto, obtendrá su IP y fabricante, a fin de facilitar la
identificación de cada dispositivo conectado.
Independientemente de la opción escogida se procederá a la pantalla de selección de canal,
en la que se deberá escoger uno de entre los disponibles discerniendo entre cámaras y
NVRs/DVRs. Esto es debido a que las primeras cuentan con 2 canales (generalmente uno
con menor calidad que el otro), mientras que los segundos cuentan con tantos canales como
cámaras tengan asociadas, generalmente variando entre los 16 y los 32 canales. Luego
continúa la pantalla de selección de usuario que resulta optativa, ya que el dispositivo a
asociar puede contar con credenciales. En caso de contar con ellas, deberá completar el dato
solicitado y proceder a la siguiente pantalla para colocar la contraseña.
Una vez completados todos los datos, ya posea o no credenciales, se procederá a validar la
información ingresada. Para ello, se compone la primera mitad de la dirección URL de la
cámara, pudiendo variar entre las alternativas
ó .𝑟𝑡𝑠𝑝: // < 𝑢𝑠𝑢𝑎𝑟𝑖𝑜 >: < 𝑐𝑜𝑛𝑡𝑟𝑎𝑠𝑒ñ𝑎 > @ < 𝑑𝑖𝑟𝑒𝑐𝑐𝑖ó𝑛 𝐼𝑃 > 𝑟𝑡𝑠𝑝: // < 𝑑𝑖𝑟𝑒𝑐𝑐𝑖ó𝑛 𝐼𝑃 >
Esto se realiza debido a que cada fabricante genera la URL del contenido de manera
diferente, pero en todas ellas se mantiene constante las representaciones mencionadas
anteriormente. Luego se procede a probar con cada posible terminación de entre las
cargadas en la aplicación, que son las más comunes encontradas durante el desarrollo de
este proyecto, junto con el canal provisto por el usuario. De no ser posible establecer una
conexión con ninguna de las alternativas, se mostrará una pantalla en la que se comunica al
usuario de esta situación, junto a la posibilidad de ingresar manualmente la dirección. De no
desearlo, podrá cancelar la operación retornando a la pantalla principal.
6 https://github.com/tejmagar/AndroidWiFiTools
24
Si la validación resulta exitosa, se comunica al usuario y se retorna al menú principal. Aquí
se mostrará un listado de tarjetas conteniendo todas las cámaras asociadas al dispositivo. Por
cada cámara se mostrará su nombre, un thumbnail (una pequeña captura) del video en vivo
y dos íconos que indicarán el estado de la cámara (es decir, si la cámara se encuentra
grabando o enviando video). En caso de que la tarjeta sea seleccionada, se desplegará un
pequeño menú que contendrá una serie de acciones.
● Observar video en vivo (preview): Como su propio nombre indica, al seleccionar esta
opción se podrá ver el video de la cámara en tiempo real de la cámara seleccionada.
● Ver grabaciones: En esta pantalla se mostrarán todas las grabaciones realizadas por la
cámara actual ordenadas decrecientemente por la fecha en que han sido grabadas.
● Ajustes: Aquí será posible editar la URL de la cámara, así como sus opciones de
grabación (la calidad de la imágen), y calidad de transmisión de video, junto a la
posibilidad de grabar la misma. En un apartado posterior se comentaráen más
detalle funcionalidades particulares de alguna de las opciones aquí seleccionables.
● Compartir: Este ajuste representa la comunicación entre la aplicación y el centro de
monitoreo. Su desactivación implica que este último no podrá acceder ni al video en
vivo así como a las grabaciones que el dispositivo contenga. En el caso contrario, será
posible solicitar ambos.
En el caso de que el usuario ingrese a la aplicación ya contando con un dispositivo creado, se
procederá a la pantalla principal, dónde podrá dar de alta las cámaras siguiendo el flujo
comentado con anterioridad.
El enfoque de este flujo es que sea lo más directo posible, es decir, no intentar de incorporar
toda la funcionalidad en un mismo lugar sino distribuirla a lo largo de la aplicación y guiar
así al usuario de forma más intuitiva. Dado que esta aplicación será principalmente utilizada
por los llamados AndroidTv, se descartó la idea de un menú y se optó por el uso de botones
para una experiencia más cómoda, ya que se debe utilizar control remoto para la
navegación, siempre con la posibilidad de volver hacia atrás entre pantallas.
25
26
Figura 4. Flujo de la aplicación CámarasPrivadasTandil.
Estructuras de datos utilizadas
En este proyecto fueron implementadas un conjunto de entidades que representan los
elementos más importantes de esta aplicación. Estos además contarán con sus propias
entradas en la base de datos de Firebase Firestore (en este caso en particular, colecciones),
por lo que resulta de vital importancia definir los mismos.
Cámara
Este componente es fundamental para la aplicación, ya que todo gira en torno a las cámaras.
A través de este se puede interactuar con ellas, siempre y cuando estén al alcance.
Representa un conjunto de ajustes, propiedades y estados que tendrán las cámaras.
● Entre los ajustes se pueden mencionar: la capacidad de grabar; la cantidad de horas a
grabar; qué codificador utilizar; la calidad de grabación; la calidad de transmisión de
video; y también si se desea sincronizar los archivos de video automáticamente con
la nube.
● Una cámara consta de: un nombre para identificarlas; una uri, esencial para acceder a
la cámara dentro de una red; un identificador que se crea desde la base de datos; el
tipo de cámara, que al estar asociadas a un dispositivo, todas serán del tipo privado;
una dirección física para ubicar esa cámara en una localidad; una fecha que
representa la última conexión con el sistema; y finalmente un nombre interno,
utilizado principalmente por el centro de monitoreo para una rápida búsqueda de
esta.
● Lo más importante de este componente para la aplicación son los estados, ya que
estos permiten informar al usuario que está sucediendo con la cámara. Son cuatro los
estados que puede poseer: si se encuentra disponible, es decir si se encuentra
encendida o es alcanzada por la red; si está grabando; si está transmitiendo video
hacia el centro de monitoreo; y si está siendo compartida, es decir, si se desea
permitir el acceso la cámara por centro de vigilancia. Éste es el estado que más
restringe la funcionalidad del dispositivo, ya que si no se desea compartir la cámara,
toda la interacción con el centro de monitoreo va a estar inhabilitada. Sin embargo la
27
grabación y la vista previa de la cámara pueden realizarse sin ningún inconveniente
permitiendo así al usuario gestionar sus cámaras de manera local. Si la cámara está
siendo compartida, la gestión local no se verá afectada y el centro de monitoreo
podrá solicitar una transmisión de la cámara en tiempo real o un video grabado, si es
que posee alguno.
Archivos de video
Estas estructuras contendrán información de los archivos que serán subidos al servidor en la
nube para su reproducción por parte del centro de monitoreo. De estos se tendrá el nombre,
su duración en segundos, el peso o espacio ocupado en el almacenamiento en megabytes
(MB) y un estado. El mismo representará la situación de un archivo en tiempo real. Si un
archivo, por ejemplo se encuentra disponible, el centro de monitoreo lo sabrá por este
campo.
Dispositivos
Finalmente, podemos definir la estructura de datos utilizada para los dispositivos. Los
mismos como ya se explicó con anterioridad contienen en su interior el conjunto de cámaras
asociadas al mismo, pero además cuentan con un nombre (utilizado para distinguir los
dispositivos del usuario), la versión de software que están corriendo, la fecha y hora de la
última conexión y una dirección, la cual contendrá la dirección del domicilio dónde se
encuentra el aparato.
Proceso de implementación
Cuándo se inició el proyecto, se evaluaron diferentes alternativas para manipular
multimedia. En principio, surgieron dos posibles: GStreamer y FFmpeg. Ambas ofrecen la
funcionalidad requerida mediante la ejecución de comandos contando cada uno con su
sintaxis particular, pero había una sutil diferencia que guió la elección: el soporte oficial. La
biblioteca de GStreamer cuenta con mantenimiento de sus desarrolladores (situación que
garantiza su estabilidad presente y futura), mientras que los proyectos de FFmpeg en
Android son desarrollados por comunidades de usuarios ajenas a los desarrolladores. Esto
llevó a que se considerase GStreamer como motor del proyecto.
28
Esta biblioteca, si bien está dirigida para sistemas Android, utiliza código nativo escrito en C
y C + +. Esto hizo que fuese necesario investigar sobre un conjunto de herramientas que
dispone Android llamada NDK por sus siglas en inglés Native Development Kit [29], dentro
de la que se encuentra JNI (Java Native Interface) que permite la utilización de código nativo
en Java mediante la compilación del mismo siguiendo una serie de pasos:
1) Se deben definir dos archivos llamados Android.mk y Aplication.mk. En el primero
de estos se especifica dónde se encuentran alojados los recursos de la biblioteca que
se quiere utilizar (en este caso, GStreamer); mientras que el segundo contiene
información de configuración, como la arquitectura del sistema destino y versión del
compilador nativo utilizado.
2) Se debe especificar, dentro de la clase Java que haga uso del código nativo, la
biblioteca utilizada y los métodos que se utilizarán definiéndose con la palabra
reservada native.
Una vez que se cuenta con ambos requisitos, se procede a compilar el código fuente escrito
en C para que el mismo pueda ser invocado y ejecutado en código Java. Ahora bien, este
código no podrá ser utilizado en cualquier segmento de código, sino que exclusivamente
puede ser ejecutada por la clase que se especifica dentro del código nativo y defina en su
interior los métodos nativos. ¿Qué quiere decir esto? JNI obliga a nombrar los métodos
nativos bajo el formato Java_<paquete>_<nombre de método>, siendo el paquete la jerarquía de
carpetas donde se encuentra la clase que ejecutará los métodos. Por ejemplo, si se quiere
invocar el método nativo “Ejemplo” en una clase que se encuentra dentro de las carpetas
/com/example/project/, en C (o C++) se deberá escribir una función que tenga por nombre
Java_com_example_project_Ejemplo. A su vez, dentro de Ejemplo se deberá definir como
método nativo <Modificador privacidad> native <Tipo de retorno> Ejemplo(<Parámetros>). Es por
esta razón que se decidió generar una clase que contenga en su interior todas las definiciones
necesarias para el funcionamiento de la aplicación. La misma fue llamada
MultimediaManager, ya que será la encargada de administrar cualquier operación multimedia
llevada a cabo.
Al tener en claro la necesidad de una clase para utilizar el código nativo, se procedió a
evaluar cómo realizar las tareas requeridas dentro de este. Primero, se implementó el
comando necesario para el envío de video. En este caso se utilizó un software provisto por
29
Kurento para realizar las pruebas pertinentes7. En ella se establece un puerto RTP al cual se
debe enviar el video. Anteriormente se comentó que ambas bibliotecas hacen uso decomandos para la gestión de multimedia, por lo que el problema se reduce a encontrar un
comando que sea capaz de tomar una fuente de video y la envíe a la aplicación web en el
puerto negociado. Dado que se desea enviar video, podemos identificar dos componentes
clave sin la necesidad de mencionar cuestiones relacionadas con la sintaxis del mismo:
1) Una fuente de video que será enviada a través de la red.
2) Si se desea transportar paquetes a través de la internet, es necesario especificar un
destino mediante una dirección IP por ejemplo.
Teniendo en cuenta lo anterior, el comando utilizado para realizar esta tarea puede
encontrarse a continuación.
uridecodebin uri=<URL de la cámara> ! videoconvert ! videoscale !
video/x-raw,width=426,height=240 ! x264enc tune=zerolatency bitrate=150 !
rtph264pay !
application/x-rtp,media=(string)video,payload=(int)103,encoding-name=(string)H264
! udpsink sync=false host=<IP del servidor> port=<Nro. Puerto>
Comando GStreamer utilizado para el envío de video.
El mismo toma como entrada una fuente de video utilizando un elemento llamado
uridecodebin el cuál toma el video de la fuente y un decodificador acorde al tipo de media que
posee la fuente. Luego se modifica la resolución del video haciendo uso de los elementos
videoconvert y videoscale, afectando cada frame (fotograma) decodificado. La resolución
escogida es de 426x240, ya que se buscó que el uso de banda ancha sea lo más bajo posible.
El video en estas instancias se encuentra en estado raw (es decir, solo con sus datos sin
formato) que posee la totalidad de la información de cada fotograma, por lo que en principio
no puede ser reproducido . Es por esto que para permitir que pueda ser utilizado por un
reproductor multimedia, se codificó con el elemento x264enc comprimiendo datos en el
formato H264 [30], uno de los más difundidos por la internet y las aplicaciones multimedia,
junto a algunas opciones que también ayudarían a reducir el tamaño de los paquetes
codificados logrando así que la transmisión de video sea en “tiempo real”. Ahora bien, como
se convierte el video a este formato, es necesario que los paquetes sean enviados con formato
H264, lo que se logra utilizando el elemento rtph264pay. Consecuentemente, se debe
7 https://doc-kurento.readthedocs.io/en/stable/tutorials/java/tutorial-rtp-receiver.html
30
especificar otras características de los paquetes como la carga por paquete y el tipo de datos
que se está enviando. Finalmente, se procede a especificar la dirección IP y puerto de destino
del video utilizando udpsink. Además de esto, puede verse que se especifica junto con estos
dos campos un tercero llamado sync. Este permite que, en caso de que se corte la
conectividad con el video, al reanudarse lo haga en el momento actual y que no recupere los
frames perdidos por la carencia de conectividad.
Luego de haber logrado enviar video desde el dispositivo android de forma satisfactoria, se
procedió a implementar la funcionalidad requerida para la reproducción por parte de la
aplicación del video filmado por las cámaras. Esto se hizo con el fin de que los usuarios
pudieran ver, si es que así lo desean, el video de las cámaras siempre que quieran de forma
fácil y rápida. Para esto, nuevamente se hizo uso de un comando GStreamer. El mismo,
puede encontrarse a continuación.
uridecodebin uri=<URL de la cámara> ! videoconvert ! videoscale !
video/x-raw,width=1280,height=720 ! autovideosink sync=false
Comando GStreamer utilizado para la reproducción de video.
Como es apreciable, existen en este nuevo comando elementos que fueron utilizados en el
primero mostrado en este documento, elementos como uridecodebin, videoconvert y videoscale,
con una única diferencia en la resolución del video: en esta ocasión se utilizará una
resolución de 1280x720p. El único elemento que no ha sido utilizado con anterioridad es
autovideosink, el cual se encarga de establecer de forma automática el destino de toda la
multimedia asociada a la dirección que se especifica. En este caso, se tiene como objetivo
observar el video en una superficie definida dentro de una pantalla. La opción sync continúa
presentando el mismo comportamiento que el especificado en udpsink, situación que denota
que ambos componentes forman parte de una misma familia: mientras que este último tiene
como finalidad establecer el destino del video a través de la red, autovideoskink lo hará de
forma automática (para este caso, en una superficie).
Finalmente se utilizó un comando para almacenar archivos de video en disco tomando como
fuente de entrada un flujo de video desde la red. El objetivo de la grabación local es que la
calidad sea la mayor posible, ya que los videos son la evidencia necesaria en caso de ocurrir
algún siniestro el cual nadie pudo presenciar más que la cámara. Para ello se toma el registro
31
de la cámara utilizando nuevamente la URL asociada a la misma y se graba en formato mp4.
El siguiente fragmento de código muestra el comando utilizado para realizar esta tarea.
uridecodebin uri=<URL de la cámara> ! queue ! videoconvert ! x264enc ! mpegtsmux
! hlssink target-duration=<Tiempo de grabación>
location=<Ubicación de escritura + "/" + Nombre de la cámara + /%05d.mp4>
playlist-location=<Ubicación de escritura + "/" + Nombre de la cámara +
/playlist.m3u8> max-files=<Cantidad de archivos>
Comando GStreamer utilizado para la grabación de video.
Al igual que en el caso anterior, aparecen elementos ya utilizados como uridecodebin,
videoconvert y x264enc. Por otra parte, surgen nuevos elementos. Queue se usa para
descomponer la entrada en diferentes buffers, ya que el proceso de grabación es lento por el
hecho de estar escribiendo en disco. Es por esto que se busca paralelizar lo mayor posible la
entrada y, a medida que se van grabando los fragmentos, se liberen los buffers. El otro
componente introducido en este comando es mpegtsmux, encargado de tomar varios streams
generados por el elemento descrito anteriormente y hacer un stream de transporte MPEG, el
cual define la manera en que se transportan los datos de video. Por último está el
componente que indica cómo se desea almacenar en disco los archivos generados, el hlssink.
Dado que la cámara graba en forma continua, por lo que en principio se contaría con una
fuente infinita de video, se debe especificar un tiempo de grabación para generar fragmentos
de este. En este proyecto se grabarán archivos de 5 minutos máximo, ya que se espera que
los mismos sean lo suficientemente pequeños como para poder envíarse con facilidad a la
nube sin consumir demasiados recursos de red. También se provee una cantidad de archivos
que se deseen grabar para no abarcar todo el espacio disponible en almacenamiento, y en
caso de que se llegue al límite, se irán reemplazando los videos más antiguos con los más
nuevos. Finalmente se indican las ubicaciones de los archivos junto a la lista de reproducción
que se genera automáticamente.
Resultados y pruebas preliminares
Con los comandos anteriores en principio se pudo obtener un prototipo funcional de la
aplicación, por lo que se pudo iniciar con la prueba de la misma para verificar que todo
funcione de manera correcta y eficiente. Sin embargo, se obtuvieron resultados poco
alentadores. Se notó un gran consumo de recursos por parte del dispositivo, sobre todo en el
proceso de grabación: uso de memoria por encima de 1 GB; uso del procesador casi al cien
por ciento; y un consumo de energía muy elevado. En el caso particular de las grabaciones,
32
el elemento hlssink presente en el comando no está optimizado para dispositivos móviles lo
que implica una ejecución demasiado exigente, situación que atenta contra uno de los
objetivos centrales de este proyecto. En el caso de la transmisión de video era evidente un
retraso acumulativo a medida que avanzaba en el tiempo, es decir que cuándo se presentaba
un problema de conexión, el video no avanzaba hacia el momento actual sino que mostrabalas imágenes desde que ocurrió el error perjudicando el requisito de realizar envíos en
tiempo real. Además, al mantener una sesión abierta por un tiempo prolongado, era mucho
más probable que esto ocurriese.
Por los motivos expuestos en el párrafo anterior se optó por abandonar el uso de GStreamer
en los procesos de grabación y envío de video, y utilizar la alternativa no escogida en los
inicios del proyecto, es decir, FFmpeg. Sin embargo, de ser necesario un potente
manipulador de multimedia, GStreamer sería la opción ideal para realizar el trabajo debido
a la amplia variedad de operaciones que soporta. Además este último no ha sido descartado
por completo, sino que continuará siendo utilizado a la hora de mostrar el video en vivo en
la aplicación. Esto se debe a que para la reproducción no hace uso de ningún codec, además
de permitir su integración de forma nativa con los componentes de interfaz provistos por
Android, algo con lo que FFmpeg no cuenta.
En las próximas líneas se explicarán los comandos utilizados para realizar cada una de las
tareas requeridas, evaluando si fué o no suficiente para lograr un uso eficiente de los
recursos del dispositivo.
Implementación mediante FFmpeg
FFmpeg a pesar de no contar con el soporte oficial de sus desarrolladores para su uso en
dispositivos móviles, cuenta con implementaciones por parte de la comunidad de usuarios
(situación ya expuesta en una sección anterior). Para este proyecto se hará uso de la
biblioteca FFmpegKit8 la cual implementa tanto FFmpeg (para manipulación de video) como
FFprobe (utilizado para la obtención de información de archivos multimedia o streamings).
En un principio se utilizaron ambos, pero por razones que se expondrán en siguientes líneas,
se determinó utilizar sólo el primero de los elementos. En lo que respecta a su adición en el
código, no es necesaria la utilización de JNI para su inclusión, ya que se encuentra contenida
8 https://github.com/tanersener/ffmpeg-kit
33
dentro de gestores de dependencias, lo que hace que sea más fácil de utilizar. Esta
herramienta tiene las siguientes características:
● Su funcionamiento radica en el uso de sesiones: cada comando que se ejecuta en el
sistema tiene asociada una sesión. Al finalizar la ejecución del comando, la sesión
finaliza.
● La ejecución de los comandos puede ser síncrona o asíncrona. Dado que las primeras
bloquean la interfaz de usuario (situación que hay que evitar en todo momento al
programar soluciones móviles), se hará uso de las segundas.
● Implementa callbacks para el final de ejecución. Esto resultará de suma importancia
ya que se podrán llevar a cabo acciones para mantener la consistencia en la
aplicación, como por ejemplo, la actualización de los estados de una cámara al
finalizar el proceso de streaming.
Con esto en mente, daremos paso a la explicación de los comandos utilizados. Al igual que
en la sección anterior, se iniciará comentando sobre el comando utilizado para el envío de
video. Para ello, fueron implementados dos comandos diferentes, donde la única diferencia
radica en el protocolo de transporte utilizado, es decir, TCP [31] y UDP [32]. En principio se
hace uso de la segunda opción, sin embargo, existen casos en los que por motivos de
configuración no se procede con la ejecución del comando y es necesario utilizar un canal de
conexión mediante TCP. Para lograr esto, se hizo uso de los callbacks mencionados
anteriormente, dónde ante la falla del comando UDP, se procede a ejecutar el segundo. A
continuación pueden observarse ambos.
-re -i <URL de la cámara> -an -c:v <Formato de encoding> -tune zerolatency
-preset superfast -payload_type 103 -f rtp rtp://<URL del servidor>:<Puerto de
escucha>
Comando FFmpeg utilizado para el envío de video (transporte UDP).
-rtsp_transport tcp -re -i <URL de la cámara> -an -c:v <Formato de encoding>
-tune zerolatency -preset superfast -payload_type 103 -f rtp rtp://<URL del
servidor>:<Puerto de escucha>
Comando FFmpeg utilizado para el envío de video (transporte TCP).
34
Comencemos definiendo los elementos utilizados en los comandos de izquierda a derecha.
Dado que ambos son idénticos con la única diferencia en las primeras líneas, utilizaremos el
segundo para la explicación. La opción -rtsp_transport es utilizada, como su nombre indica,
para especificar el tipo de transporte utilizado por el protocolo RTSP, el cuál será en ese caso
TCP. En el primero no se especifica ya que la opción por defecto es UDP. Luego, -re es
utilizado para especificar que se leerá multimedia en tiempo real, seguido de -i abreviatura
de input (entrada en inglés), donde a continuación se colocará el origen del video. Dado que
se utiliza la dirección de la cámara para acceder a su contenido, será este valor quién
continuará a dicho elemento. Dado que se desea enviar solo video, la opción -an descarta los
datos de audio (en caso de encontrarse). El elemento -c es utilizado para especificar el codec o
formato de codificación de un elemento multimedia, pero dado que es de importancia
exclusivamente el video, se especifica dicho tipo mediante :v. De esta manera, -c:v representa
el tipo de codec para video. Existen tres diferentes tipos de encoding que podrán ser
utilizados y configurados por los usuarios de la aplicación:
● Copy consiste en copiar el formato con el cual se obtiene el video. Por ejemplo, si este
se encuentra en formato H.264 al ser leído, el stream será enviado en dicho formato.
La ventaja que presenta es que no se utilizan recursos extra para su conversión, lo
que evita un exceso en el procesamiento en el dispositivo.
● El otro tipo de encoding es H.264 o Advanced Video Encoding, que se obtiene
utilizando el elemento libx264. Este es uno de los formatos estándar más difundidos
en la actualidad para la compresión de video. La desventaja de este (y de cualquier
otro formato que no sea obtenido por copy) consiste en que es necesario que el
procesador transforme los paquetes de un formato a otro, haciendo uso de CPU y
memoria extra. Esto a su vez dependerá del tipo de sistema que ejecute la aplicación,
ya que existen dispositivos que cuentan con soporte para realizar las conversiones de
forma más eficiente.
● Finalmente la tercera opción que se podrá seleccionar será, mediante el uso de
libx265, H.265 (también conocido como High Efficient Video Coding) que es el sucesor
del formato anteriormente mencionado. La ventaja que presenta este frente a su
antecesor es que posee mayores niveles de compresión a medida que la resolución
del video se incrementa, situación cada vez más común en la tecnología moderna.
35
Además presenta un ahorro del bitrate9 de entre el 25% y 50% comparado con el
presentado en la biblioteca anterior, manteniendo la misma calidad visual10. Sin
embargo, continúa presentando la misma desventaja que H.264, con el agravante de
que solo se encuentra optimizado en dispositivos más modernos, por lo que no es
recomendable utilizar este bajo sistemas más antiguos o de bajo rendimiento.
Relacionado con este apartado se encuentran los elementos -tune y -preset. El primero
permite modificar la configuración del proceso de encoding según la entrada, en este caso el
video de la cámara, utilizando zerolatency ya que permite un rápido proceso de encoding y
un video de baja latencia, fundamental para lograr los objetivos planteados en este proyecto;
mientras que el segundo es utilizado para proveer determinadas velocidades de encoding y
tazas de compresión, para lo cual se utilizará la opción superfast, siendo la más rápida, solo
detrás de ultrafast. Finalmente, las últimas opciones son similares a las especificadas en el
comando GStreamer utilizado originalmente: -payload_type denota el tipo de datos que se
enviará a través de la red (nuevamente con el valor 10311); y -f utilizado para forzar el
formato del video en la salida, que sería en este caso el destino del video representado por la
URL del servidor y el puerto en el cual