STREAMING DE VIDEO POR TELEFONÍA MOVIL
JULIANA GARZÓN VÁSQUEZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA ELECTRÓNICA
Bogotá, D.C.
2
STREAMING DE VIDEO POR TELEFONÍA MOVIL
JULIANA GARZÓN VÁSQUEZ
Cód. 20111005069
Proyecto de grado presentado como requisito para optar al título de:
Ingeniera Electrónica
Director Interno:
Ingeniero Julián Rolando Camargo López
Director Externo:
Ingeniero Carlos Andrés Martínez Beltrán
En la modalidad de:
Pasantía
Empresa:
Wavecomm Corporation
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA ELECTRÓNICA
Bogotá, D.C.
3
AGRADECIMIENTOS
En el desarrollo de la carrera y la pasantía muchas personas me acompañaron y apoyaron para poder llevar a culminación esta gran etapa, gracias a todos mis compañeros y amigos que codo a codo recorrimos este camino, a cada profesor que me formó. Un especial agradecimiento a cada uno de la familia Wavecomm por formarme como profesional y como persona, que me enseñaron que trabajar amando lo que haces y con el mejor ambiente es posible. A cada maestro en la universidad, en el trabajo y en la vida, que me han enseñado sobre la vida y la felicidad. Agradezco enormemente a mi familia que me ha apoyado en cada larga noche que muchas veces no acababa porque sin su apoyo nada seria, a mi nona que me demuestra su fuerza día a día, a quienes son mi familia sin compartir nada de sangre y que siempre están ahí. Gracias Dios por permitirme llegar acá.
5
ÍNDICE
AGRADECIMIENTOS ... 3
DEDICATORIA ... 4
ÍNDICE ... 5
LISTADO DE ACRÓNIMOS ... 7
CAPÍTULO 1 ... 8
1.1 INTRODUCCIÓN ... 8
1.2 PLANTEAMIENTO DEL PROBLEMA ... 9
1.3 OBJETIVOS ... 10
1.4 JUSTIFICACIÓN ... 11
CAPÍTULO 2 ... 12
2.1.9 Comunicación TCP en java bajo nivel ... 16
2.1.10 Protocolos de transmisión ... 16
2.1.10.1 Adobe HDS ... 16
2.1.10.2 Adobe RTMP ... 17
2.1.11 Formatos de archivos de video ... 17
2.1.11.1 MP4 (QuickTime container) ... 17
2.1.12 RTSP- Real time streaming protocol ... 17
2.1.13 Netty ... 18
6
2.1.15 FFserver ... 19
2.1.16 Node.js ... 19
CAPÍTULO 3 ... 20
3.1 DESARROLLO DEL PROYECTO ... 20
3.1.1 Primera, segunda y tercera semana ... 20
3.1.2 Cuarta a octava semana ... 28
3.1.3 Novena semana ... 31
3.1.4 Decima y decima primera semana ... 33
3.1.6 Decimocuarta y decimoquinta semana ... 35
3.1.7 Decimosexta semana ... 36
3.2 RESULTADOS ALCANZADOS ... 38
CAPÍTULO 4 ... 39
4.1 ANALISIS DE RESULTADOS ... 39
4.2 PRODUCTO ... 41
4.3 IMPACTOS DEL TRABAJO DE GRADO ... 42
CAPÍTULO 5 ... 43
5.1 EVALUACION Y CUMPLIMIENTO DE LOS OBJETIVOS DE LA PASANTIA ... 43
CAPÍTULO 6 ... 44
6.1 CONCLUSIONES ... 44
6.2 REFERENCIAS ... 45
6.3 PÁGINAS DE CONSULTA ... 46
ANEXOS ... 50
CRONOGRAMA ... 50
CONCEPTO PROFESIONAL DESIGNADO ... 51
CERTIFICADO CUMPLIMIENTO DE HORAS ... 52
7
LISTADO DE ACRÓNIMOS
GPS Global Positioning System - Sistema de Posicionamiento Global MDVR Mobile Digital Video Recorder - Grabadora de video digital móvil
RTP Real-time Transport Protocol - Protocolo de transporte de tiempo real RTSP Real-time Streaming Protocol - Protocolo de transmisión en tiempo real
RTMP Real-Time Messaging Protocol – Protocolo de mensajería en tiempo real HLS HTTP Live Streaming - Transmisión en vivo HTTP
HDS HTTP Dynamic Streaming - Transmisión dinámica HTTP
TCP Transmission Control Protocol - Protocolo de Control de Transmisión UDP User Datagram Protocol - Protocolo de datagramas de usuario
MPEG Moving Picture Experts Group – Grupo de expertos de imágenes en movimiento
CODEC Codificación y decodificación
8
CAPÍTULO 1
1.1
INTRODUCCIÓN
El monitoreo vehicular es un campo de acción de gran valor en innovación y desarrollo para la industria automotriz ya que busca no solo obtener la geo-referenciación del automotor, por medio del GPS, sino que permite identificar mayor información como la velocidad, los datos del acelerómetro, del odómetro interno, entre otros. Sin embargo, las compañías que hacen parte de este mercado no han avanzado en la transmisión del video como parte de la estrategia de monitoreo. Esto se debe a la complejidad que conlleva codificar, transmitir, recibir y reproducir de forma adecuada un streaming de video y por el costo que genera la transmisión del mismo por medio del uso de datos móviles. Bajo este contexto surge la necesidad de realizar el monitoreo vehicular de video y de ubicación. Este proyecto se realizará mediante el dispositivo MDVR de origen chino proveído por Wavecomm Corporation SAS.
Cabe aclarar que para este proyecto no se cuenta con el protocolo de comunicación del proveedor, sin embargo, contamos con un servidor nativo para poder visualizar el video y la posición por GPS del dispositivo. Con base a ese servidor se realizará la ingeniería inversa para desarrollar un servidor autóctono que extraiga esa información de forma correcta e independiente o en su defecto la mejor aproximación al objetivo; el cual es poder visualizar de forma dinámica y en tiempo real toda la información suministrada por el dispositivo en especial la información más significativa como lo es el video, esta visualización se realizará en la plataforma web de la empresa y será presentada bajo una interfaz que tenga altos niveles de usabilidad para que cualquier usuario pueda acceder a esta.
9
1.2 PLANTEAMIENTO DEL PROBLEMA
Este proyecto parte de la necesidad de desarrollar e integrar a una plataforma el monitoreo de vehículos por medio de video que permita a las industrias, empresas y pymes el control, vigilancia y seguimiento de los recursos físicos de aquellas instituciones, los procesos que se realicen en estos y el correcto uso por parte del personal encargado ya que actualmente no son muchos los productos en el mercado con la versatilidad del video en tiempo real, solamente se puede hacer seguimiento de ubicación, pero sin detallar en información de video en tiempo real.
Adicionalmente, la industria automotriz colombiana no ha profundizado en el desarrollo de herramientas en este campo, por el alto costo y el extenso tiempo para llevarlo a cabo. Sin embargo, este proyecto identifica esta necesidad que requiere ser desarrollada e implementada para suplir las falencias del mercado de monitoreo.
10
Embeber video y datos de ubicación en la plataforma web de producción de la empresa, por medio de un dispositivo MDVR, para monitorear de forma visual las condiciones de velocidad, aceleración, posición, streaming de video entre otras, de un automóvil de tal forma que esté disponible para los gestores, operadores o programadores logísticos del activo, haciendo posible la supervisión objetiva y dinámica del trabajo dentro del automóvil.
1.3.2 Objetivos específicos.
1. Conocer el MDVR, el protocolo de comunicación de control, de los datos y del video.
2. Crear un servidor que esté en la capacidad de: realizar una comunicación exitosa con el dispositivo, extraer la información de ubicación de forma adecuada y almacenarla en la base de datos.
3. Implementar la visualización del video de forma adecuada en la plataforma web preexistente usando, de ser necesario y en su mínima medida, el servidor nativo.
4. Generar y embeber a la página el video de forma autónoma con base a la información de la codificación y trama del video suministrado por el proveedor del dispositivo. Implementar el dispositivo en un automóvil con la visualización en tiempo real con sus datos de ubicación en la página web de servicio de la empresa o en la plataforma que sea designada para este fin.
11
1.4 JUSTIFICACIÓN
Este proyecto busca tener un impacto en los procesos de monitoreo y así mismo en los procesos industriales de Colombia ya que al permitir el monitoreo de video aumenta la productividad de las empresas porque reduce los tiempos de control de los vehículos, permite determinar cómo mejorar el rendimiento del uso de los vehículos y que el trabajo por parte de los operarios de los vehículos se realicen en los tiempos estimados. Además, ayuda a la supervisión y seguridad de los vehículos y/o su carga ya que el monitoreo visual podría permitir identificar intentos de robo y poder realizar las acciones necesarias en el menor tiempo posible.
12
CAPÍTULO 2
2.1 MARCO TEÓRICO
En este capítulo se mostrarán los conceptos estudiados y usados para desarrollar el proyecto de forma concisa, con el fin de introducirlos y conocerlos al momento de ser abordados sobre el desarrollo.
2.1.1 MPEG
MPEG siglas de Motion Picture Experts Group establecido en 1988 como un grupo de trabajo dentro del ISO/IEC que definió estándares para la compresión digital de señales de video y audio.
MPEG2: Es un estándar de codificación, siendo una extensión del estándar MEPG-1, publicado en 1995 como el estándar ISO/IEC 13818.
Define los métodos de codificación para comprimir el video escaneado progresivamente, así como el video entrelazado escaneado.
Comúnmente es utilizado en formato de difusión, tales como definición estándar de televisión (SDT) y televisión de alta definición (HDT)
Soporta una taza de codificación de 3 a 15 Mbit/s para SDT y 5 a 20 Mbit/s para HDT.
2.1.2 H264
El vídeo digital se comprime para ahorrar espacio, independientemente del ancho de banda de que se disponga o del material multimedia de que se trate, y un códec (abreviatura de compresión-descompresión) se encarga de realizar la codificación y la decodificación. La mejora de los estándares de compresión en los que se basa un códec permite transmitir vídeo de una mayor calidad usando el mismo o un menor ancho de banda.
13 determinada información para corregir cualquier diferencia de textura pequeña. En aquellos casos en los que la estimación del movimiento no puede encontrar coincidencias adecuadas, los codificadores utilizan la textura de los bloques cercanos en el mismo fotograma para predecir la textura del bloque y almacenar la diferencia entre la predicción y la textura real. Esto es más eficaz que almacenar la textura directamente, pero es más costoso que la estimación del movimiento. Los codificadores actúan como compresores “con pérdidas” y su objetivo no es reproducir la imagen original de una manera exacta sino elegir los medios óptimos para reducir la velocidad de los datos conservando al mismo tiempo la calidad visual de la mejor manera posible. Con unos valores adecuados, las diferencias pueden ser imperceptibles incluso cuando la compresión sobre los datos sin procesar se aproxima a 100:1.
El estándar H.264 ofrece unas mejoras sustanciales en cuanto al rendimiento en comparación con sus predecesores. Por ejemplo: un DVD estándar puede incluir una película de dos horas comprimida usando el códec MPEG-2 (el estándar habitual de las películas de DVD) y cuatro horas de películas usando un códec H.264. [1]
2.1.3 RTP
RTP siglas de Realtime Transport Protocol. Es un protocolo utilizado para la transmisión de información en tiempo real, principalmente para audio y video, o la combinación de ambas como en las videoconferencias. Fue desarrollado por el grupo de trabajo de transporte de Audio y Video del IETF, dentro del estándar de internet STD 64 en la norma RFC 3550.
El protocolo RTP trabaja en conjunto con el Realtime Control Protocol (RTCP) el cual se maneja sobre UDP en el modelo OSI.
14 2.1.4 HLS
Es un protocolo de transmisión de multimedia que está montado sobre el protocolo HTTP y ha sido implementado por Apple Inc. Para el procesamiento de la multimedia y en especial del video lo que hace es romper el flujo en pequeñas secuencias basada en HTTP. Este protocolo maneja una lista extendida de formato M3U extendida que contiene los metadatos y los datos de multimedia.
2.1.5 Node.js
Es un entorno de ejecución para JavaScript que se destaca por no manejar contenido Flash haciéndolo más confiable y seguro, igualmente tiene alta compatibilidad con equipos móviles y tabletas, con la gran ventaja de que solo requiere la librería Socket.io para recibir el streaming de video.
Es decir, este servidor web hace posible trasmitir video y audio en vivo, sin la necesidad de Flash.
2.1.6 WebRTC
A nivel web la librería webRTC es un primer paso que se ha instaurado para ver streaming de video, inicialmente se tiene instaurada una función para poder visualizar el video de la webcam. Sin embargo, si se desea transmitir este video hay que usar adicionalmente un servicio web, como lo es el nombrado anteriormente, el Node.js, teniendo como una gran ventaja el no uso de plugins, siendo así una plataforma transparente para el usuario.
2.1.7 Flash
Por medio del programa Adobe Flash se realiza la creación y manipulación de gráficos vectoriales, trabajando sobre fotogramas; los archivos reproducibles tienen, por lo general, la extensión de archivo .SWF, estos archivos multimedia son reproducibles por medio del adobe flash player.
15 Como punto de comparación cabe decir que la plataforma del servidor nativo maneja el video por medio de esta instancia flash, pero por las razones previamente mencionadas, se decidió utilizar HTLM5 para ver el video en vivo.
2.1.8 Protocolos de Transporte
2.1.8.1 Protocolo TCP (Transmission Control Protocol)
El protocolo TCP está orientado a conexión. Eso quiere decir que cuando se establece una conexión y hay un envió de datos se debe tener una respuesta confirmando la llegada de los mismos, esa respuesta se conoce como acuse de recibo, con las siglas ACK de su nombre en inglés acknowledgement. Esto sucede gracias al control CRC de datos que se basa en una ecuación matemática que permite verificar la integridad de los datos transmitidos. De este modo, si los datos recibidos son corruptos, el protocolo TCP permite que los destinatarios soliciten al emisor que vuelvan a enviar los datos corruptos. [2]
2.1.8.2 Protocolo UDP (User Datagram Protocol)
Es un protocolo no orientado a conexión, contrario al protocolo UDP. Es decir, cuando una maquina A envía paquetes a una maquina B, el flujo es unidireccional. La transferencia de datos es realizada sin haber realizado previamente una conexión con la máquina de destino (maquina B), y el destinatario recibirá los datos sin enviar una confirmación al emisor (la maquina A). Esto es debido a que la encapsulación de datos enviada por el protocolo UDP no permite transmitir la información relacionada al emisor. Por ello el destinatario no conocerá al emisor de los datos excepto su IP. [2]
El MDVR usado en esta práctica usa el protocolo de comunicación TCP clasificación AF12, lo que significa que tiene prioridad frente a otras tramas cuando hay tráfico.
2.1.8.3 Socket TCP
Para empezar, debemos decir que los sockets son un concepto abstracto por el cual se genera un flujo de datos, en los cuales quedan guardadas las direcciones IP de origen, destino y los puertos de los mismos para garantizar la comunicación Los sockets tienen dos roles principales, el servidor que siempre está a la escucha de un puerto fijo y es el que, por lo general, procesa la información; y el cliente apunta a la Ip y al puerto, fijos previamente para establecer la conexión y enviar los datos importantes.
16 2.1.9 Comunicación TCP en java bajo nivel
En muchas oportunidades necesitamos conocer la cabecera de la comunicación TCP ya que algunas veces debemos diferenciar las tramas que son únicamente ACK y las que son push (PSH); está es una instrucción donde se le pide al receptor que procese en ese momento los datos que estén llegando o que estén en el buffer.
Esta comunicación a bajo nivel se necesitó para procesar las tramas que llegaban de video, puesto que por lo general llegaban tramas con información de los cuadros, apenas se completa la información que se presume son los 30 cuadros envía el último mensaje con un PSH para avisar ese acontecimiento.
2.1.10 Protocolos de transmisión
2.1.10.1 Adobe HDS
17 2.1.10.2 Adobe RTMP
El protocolo de mensajería en tiempo real (RTMP) fue diseñado para la transmisión de audio, video y datos de alto rendimiento entre las tecnologías de Adobe Flash Platform, incluyendo Adobe Flash Player y Adobe AIR. RTMP está ahora disponible como una especificación abierta para crear productos y tecnología que permitan la entrega de vídeo, audio y datos en los formatos de AMF, SWF, FLV y F4V compatibles con Adobe Flash Player. [4]
2.1.11 Formatos de archivos de video
2.1.11.1 MP4 (QuickTime container)
MP4 es un formato de archivo creado por MPEG como un formato de contenedor multimedia diseñado para almacenar datos audiovisuales. El formato MP4 reemplaza en gran medida a los formatos de archivos multimedia anteriores y crea algunos cambios en la forma en que los se presentan los archivos audiovisuales al público.
El MP4 se basa en un formato de archivo QuickTime y tiene varias extensiones de nombre de archivo que pueden ayudar a proporcionar pistas sobre qué tipo de contenido está contenido en el archivo. [5]
2.1.11.2 FLV (Flash Video)
FLV significa Flash Video, que es un formato de archivo contenedor utilizado para entregar el vídeo a través de Internet usando Adobe Flash Player. Los contenidos FLV pueden ser incrustados dentro de archivos SWF. Los datos de audio y vídeo en archivos FLV se codifican de la misma forma como se codifican los de archivos SWF. Es un formato diseñado para la reproducción de vídeo en la web, que ofrece altas tasas de compresión y produce alta calidad de video. [6]
2.1.12 RTSP- Real time streaming protocol
18 Este protocolo no fue usado puesto que los datos de transmisión al ser procesados e implementados por el servidor web la transmisión se maneja en forma transparente.
2.1.13 Netty
Es una librería de manejo de la red con el manejo de sockets asíncrono funcionando por eventos, el cual brinda un gran portafolio para el manejo entre servidores y clientes de alto rendimiento. Esta librería facilita el manejo de las tramas recibidas, ya sean de información o multimedia puesto que maneja en forma paralela todos los hilos y adicionalmente todos los eventos, haciendo que no sea secuencializada, sino que pueda procesarse de forma adecuada y en paralelo; por otra parte, puede manejar diferentes tipos de protocolos de transporte (TCP y UDP) como protocolos de red como FTP, SMTP, HTTP además de varios protocolos binarios heredados.
En este caso se utilizó esta librería para manejar todas las tramas procedentes del MDVR, incluyendo las tramas de control con su respectivo procesamiento y principalmente su respuesta, adicionalmente se manejaron las tramas de video donde se procesan y se transmiten de forma adecuada para que el servicio web lo distribuya de forma adecuada.
2.1.14 FFmpeg
19 Este Framework puede manejar streaming tanto de entrada como de salida, esto se puede hacer de dos formas; la primera es enviar los frames a un servidor web para distribuirlo o a un solo destinatario es decir a un cliente.
Este Framework se escogió para procesar las tramas de video del proyecto puesto que es libre, liviano y cumple todas las características de manejo multimedia que se requiere.
2.1.15 FFserver
En el framework de ffmpeg buscaron desarrollar una solución web para distribuir los archivos multimedia, esta es la solución más directa después del procesamiento de las tramas del video por medio del ffmpeg, pero para solución a gran escala con múltiples dispositivos y se vuelve ineficiente puesto que cuenta con bajo soporte ya que han dejado de trabajar en él y tendrá una fecha de caducidad pronta, por esta razón esta solución no es viable para el proyecto y se descarta.
2.1.16 Node.js
20
CAPÍTULO 3
3.1 DESARROLLO DEL PROYECTO
Dentro del plan de trabajo se plantearon cinco fases; conocimiento del dispositivo, análisis, desarrollo, pruebas e implementación.
Para realizar el proyecto, las fases se entrelazaron entre sí, por esta razón se mostrará semana a semana el desarrollo del mismo.
3.1.1 Primera, segunda y tercera semana
3.1.1.1 Conocimiento del dispositivo
3.1.1.1.1 Servidor Nativo:
21
Parte del conocimiento de esta plataforma es realizar la correcta conexión del dispositivo a la misma, de esa forma se configuraron los puertos de cada uno de los servicios, los usuarios y la creación del dispositivo.
Los valores de los puertos son ejemplos para ilustrar el comportamiento del dispositivo.
3.1.1.1.2 Dispositivo MDVR:
Por otra parte, también fue necesario configurar el dispositivo de forma adecuada, este proceso abarca la siguiente información.
22 Configuración ID dispositivo
Configuración dirección IP y puertos del servidor
23 Configuración visualización del video y tiempos de grabación
Configuración transmisión de video
24 Configuración alarma de acelerómetro – para verificar detenciones bruscas o choques.
Configuración alarma por velocidad
3.1.1.1.3 Condiciones Físicas
Finalmente se desarrollaron pruebas físicas para manejar una información verificada y tener las precauciones necesarias a la hora de la instalación.
Alimentación del dispositivo
25 Diferencia de potencial entre tierra y chasis
La diferencia de potencial entre la tierra y el chasis con una alimentación de 14 Voltios es de 200 mV DC en promedio, mostrando en parte de la prueba picos de máximo 300 mV DC. Estas medidas se tomaron en diferentes puntos del chasis y se evidencia este potencial principalmente en las zonas no recubiertas por la pintura como lo son los tornillos.
Medición diferencia de potencial chasis (tornillo) a tierra:
Corriente
Se realizó la medición de la corriente entre la fuente de alimentación y la unión de los cables VCC y arranque para medir la corriente total. Se realizan las pruebas con una alimentación de 14 Voltios DC.
Corriente Promedio
26
Corriente sin activar led de zonas oscuras ni transmisión de video:
27 Corriente máxima
Esta ocurre cuando se activa la transmisión del video y los leds para zonas oscuras de la cámara. De esta forma se evidencia que la transmisión de video eleva la corriente en 200mA.
3.1.1.2 Análisis
Posteriormente y por medio de un software de monitoreo de red llamado Wireshark se empieza a reconocer la comunicación entre el servidor nativo y el dispositivo MDVR, por este medio se sabe que el protocolo manejado es TCP, se conocen bajo diversas pruebas que los puertos usados son los ejemplificados previamente.
28 3.1.2 Cuarta a octava semana
3.1.2.1 Desarrollo
Después de analizar la información de las tramas de control se procede a construir un servidor para el procesamiento de dichas tramas.
Por medio del lenguaje de programación Java se realiza este programa por medio de Sockets y más específicamente por medio de la librería Netty, ya que esta al ser orientada a los eventos permite la lectura y la escritura simultanea de los datos dentro de la trama de forma asincrónica y permitiendo el manejo de diferentes hilos.
Igualmente se realizó el parseo de las tramas según el análisis hecho en las semanas anteriores.
3.1.2.1.1 Procesamiento de la información
Antes de iniciar con el desglose de las tramas debo aclarar que la información de las tramas son ejemplos para mostrar la comunicación de los dispositivos y el servidor.
La comunicación entre el MDVR y el Servidor tiene múltiples Tramas de control para la comunicación, las tramas tienen la siguiente estructura para la comunicación.
<Índex>, <Número serial>,<Código Mensaje>, ,,<fecha y hora>,<…>
Donde <…> quiere decir información adicional dependiendo de la trama y puede ser nulo. A continuación, se mostrarán las Tramas más significativas.
Conexión inicial o Login
Este mensaje se realiza cada vez que se genera la sincronización entre el servidor y el dispositivo para verificar la correcta conexión. El dispositivo envía un mensaje con código X123, el servidor responde con la trama Y987.
Mensaje Dispositivo:
29 Donde <…> es información que no se sabe con exactitud que significa y no se usa en el Agente Intermedio.
Respuesta del Servidor Nativo:
055,<Número serial>,Y987,,<fecha y hora>,V101,,<fecha y hora de la solicitud>,0,1
Información de Posición
El dispositivo envía información de posición, velocidad y odómetro cada cierto tiempo, bajo el código de mensaje X234, el servidor responde un mensaje simple con el código Y876.
Mensaje Dispositivo:
144,<Número serial>,X234,,<fecha y hora>,<Longitud>,<Latitud>,,<Velocidad >,<…>,<odómetro>,<…>,
Respuesta del Servidor Nativo:
031,<Número serial>,Y876,,<fecha y hora>
Mensaje para no perder la conexión
El dispositivo cada cierto tiempo envía un mensaje para no perder la conexión para el código X345 donde solo se especifica la fecha y hora, el servidor responde igual que en el caso anterior con el código Y765 y la misma información.
Mensaje Dispositivo:
30 Respuesta del Servidor Nativo:
031,<Número serial>,Y765,,<fecha y hora>
Mensaje para pedir transmisión de video
El servidor según la solicitud del usuario pide al dispositivo empezar la transmisión de video por medio del puerto 35001, esta solicitud se realiza bajo el código Y654 y el dispositivo responde por con código X456.
Mensaje del servidor nativo:
070,<Número serial>,Y654,,<fecha y hora>,<información
desconocida>,<Ip>,<puerto>
Mensaje Dispositivo:
171,<Número serial>,X456,,<fecha y hora>,<Longitud>,<Latitud>,<Velocidad >,<…>,<odómetro >,<…>, Y654,<fecha y hora de la solicitud>,
Mensaje para acabar transmisión de video
El servidor según la solicitud del usuario pide al dispositivo acaba la transmisión de video por medio del puerto 35001, esta solicitud se realiza bajo el código Y654 y el dispositivo responde por con código X456. Pero tiene parámetros diferentes como se puede ver a continuación. Mensaje del servidor nativo:
052,<Número serial>,Y654,,<fecha y hora>,<información desconocida>,0,0,1,0
Mensaje dispositivo:
31 El servidor parsea las tramas recibidas por su separación por comas guardando la información. De estos mensajes se extrae: tipo de mensaje, latitud, longitud, hora del mensaje, velocidad, dirección Ip y puerto y odómetro total.
Se realiza la conversión de latitud y longitud de minutos y segundos a decimal, teniendo en cuenta que el espacio destinado a segundos cuenta con los dos primeros números como enteros y el resto como decimales. Por otra parte, se hace la conversión de la velocidad de millas por horas a kilómetros por hora.
3.1.2.1.2 Conexión a la base de datos y visualización de la información
Por medio de la librería SQL se realizó la conexión a la base de datos con la cual se realizan las consultas necesarias para guardar todos los datos parseados y así actualizar la información a la plataforma web llamada Wavetrack con los datos más recientes del dispositivo, además de ser insertados en una tabla histórica y así conocer el recorrido del vehículo que contiene el MDVR.
3.1.2.2 Pruebas
El servidor se dejó en prueba por una semana para verificar su funcionamiento, se realizaron múltiples correcciones en el cual se generó un servidor estable, el cual no necesita intervención de un operador. Se tuvo que tener especial cuidado puesto que las respuestas son variables en especial porque el código inicial que debe enviar varía según el código inicial del mensaje entrante.
3.1.3 Novena semana
3.1.3.1 Análisis
Se analizó la plataforma web del servidor nativo y principalmente la división del video, ya que el servidor estaba instalado en nuestra máquina se pudo revisar el código en el cual se reproducía el video en aquella plataforma.
32 Con base al servidor nativo se creó una página que incluye exclusivamente la visualización de video, guardado en el mismo servidor nativo, en esta se debe enviar el número de dispositivo, internamente se maneja el nombre de usuario y la contraseña del mismo que para el servidor nativo será un usuario y contraseño con acceso limitado.
De esta forma se pudo embeber esa página en la plataforma web Wavetrack, sin embargo, esta forma de ver el video es bastante ineficiente puesto que se necesita el usuario y contraseña de la plataforma web nativa, además de usar una visualización en Flash siendo muy insegura esta forma de embeber el video.
3.1.3.2 Desarrollo
Se estudió exhaustivamente el código desarrollado por medio de una página web, con la dificultad de que está vagamente comentado en idioma chino, se extrajo del entorno web dejando solamente la solución de video de la forma más simple posible.
3.1.3.3 Pruebas
33 En la plataforma web Wavetrack se relacionan los datos extraídos por el servicio de control y el video por medio de la identificación del vehículo. Donde se recopila e inserta toda la información necesaria proveniente del servidor de control.
3.1.4 Decima y decima primera semana
3.1.4.1 Análisis
34 cancela por completo la comunicación de video, transmitiendo solamente unos cuantos segundos de video.
3.1.4.2 Desarrollo
Bajo el lenguaje de programación Java se realizó el desarrollo de este servidor utilizando la comunicación TCP por medio de Sockets y más específicamente usando la librería Netty, similar al servidor de control visto previamente, en el cual permite la lectura de tramas de longitud variable y sin caracteres especiales que determinen el inicio y la finalización de los datos, teniendo los mismos beneficios de la versión de control, es decir, que está orientado a los eventos permitiendo la lectura y la escritura simultanea de los datos de forma asincrónica y permitiendo el manejo de diferentes hilos.
Como se vio anteriormente el puerto de llegada de video es por medio del puerto 35001. Para empezar, se creó un programa denominado agente intermedio de video el cual recibe la trama y la pasa directamente al servidor nativo, esto se realizó antes de conocer la forma en que se da la respuesta del servidor nativo hacia los frames de video. Para esto se modificó en el servidor nativo el puerto de llegada de video al 23100. Esta redirección fue acabada en el momento que se analizó la respuesta y se logró realizar el envío de la misma de forma autónoma por medio del servidor creado.
Por otra parte, para el procesamiento de video que se realizó, las tramas de video que llegan del MDVR se transmiten por medio de un servidor interno por el puerto 23300 el cual se usará posteriormente con el aplicativo ffmpeg. Igualmente usando la librería
Runtime.getRuntime().exec(); se inicializa una instancia de ffmpeg cada vez que se realiza una nueva conexión de video.
3.1.5 Decimosegunda y decimotercera semana
3.1.5.1 Desarrollo
En el Framework ffmpeg se realizó el procesamiento y conversión de las tramas de video para transmitirla posteriormente al servidor de video. Funciona como cliente pidiendo la trama de video al servidor creado previamente al puerto 23300, configurando los parámetros de la siguiente forma:
Formato: Video Mpeg1 (-f).
35 Luego se envía esa trama a los puertos 2340x donde ‘x’ es el número de la cámara, notados desde 0 hasta 3 y suministrados desde el servidor de video.
Adicionalmente tiene la instrucción para guardar el video reproducido teniendo en cuenta el número del dispositivo la cámara a la cual se le solicito y la fecha.
Instancia hacia FFmpeg:
$ ffmpeg -i http://127.0.0.1:23300 -f mpeg1video -vf scale=352x240
http://127.0.0.1:2340<camara>/2715/352/240/<dispositivo>/<camara>
C:\\\\Users\\MDVR\\Documents\\MDVR\\VideosBk\\video<dispositivo>_<camara>_< fecha>.mp4 -y
A continuación, se mostrará un ejemplo de la forma en que se instancia el framework ffmpeg: (Dispositivo = 6700001; Cámara = 0; Fecha = 12 enero de 2017)
3.1.6 Decimocuarta y decimoquinta semana
3.1.6.1 Desarrollo
3.1.6.1.1 Servidor Web
Para finalizar este proyecto se usó el programa node.js para realizar los servidores web. Se realizaron cuatro servidores independientes e idénticos, esto con la idea de manejar un servidor por cada cámara ya que al usar la conexión de webSocket no hay forma de enviar las tramas a cuatro puertos distintos sin que interfieran entre sí, a continuación, se describe la estructura de los cuatro servidores.
36 3.1.6.1.1 Interfaz:
Luego, se estructura la página web del video, la cual se realizó en PHP para poder pasar los datos necesarios de forma privada, por otra parte, se utilizó la librería webSocket para recibir el video el cual se procesa en cuatro etiquetas de Canvas. Ya que se necesita pedir video sin usar el servidor nativo se usó la librería Socket.io para establecer una conexión al servidor de control, es decir por el puerto 35004, en el momento que se oprima el botón PLAY y acabar la conexión cuando se oprima el botón STOP.
3.1.7 Decimosexta semana
3.1.7.1 Pruebas
37 La página final se muestra a continuación.
38
3.2 RESULTADOS ALCANZADOS
En este proyecto se alcanzaron todos los objetivos propuestos en tres entregas de resultados. En la primera entrega se presentó el servidor con la capacidad de extraer datos relevantes de las tramas, procesarlos, subirlos a una base de datos y mostrarlos en la plataforma web. La segunda entrega consistió en lograr visualizar el video en la plataforma web al embeberlo del servidor nativo.
En la tercera se entregó un servidor que ofrece los servicios necesarios para reproducir el streaming de video recibido del dispositivo MDVR en una página web de servicio de monitoreo de automóviles, al igual que datos de ubicación geoespacial. Este servidor es autónomo y de interacción directa con el dispositivo.
La visualización de los datos y el video se presentan de forma dinámica, continua y en tiempo real, para satisfacer el monitoreo adecuado de los automóviles.
39
CAPÍTULO 4
4.1 ANALISIS DE RESULTADOS
El proyecto se desarrolló bajo una metodología divida en cinco fases: conocimiento del dispositivo, análisis, desarrollo del aplicativo, pruebas e implementación, recalcando que en las fases de análisis y pruebas se realizaron reiterativamente hasta que el aplicativo cumplió en su totalidad con el objetivo del proyecto y para poder hacer su salida a producción.
El proyecto tuvo una duración estimada de 16 semanas, empezando con la ejecución de dos semanas de la fase del conocimiento del dispositivo donde se realizaron las tareas de verificar la configuración física del dispositivo, verificar la configuración del servidor nativo, conocer el manejo del servidor nativo, visualizar la información recibida del dispositivo por medio de un software de monitoreo de red y verificar los puertos de conexión.
Tras adquirir los conocimientos, la información y la data necesaria para el desarrollo del proyecto se realizó la fase de análisis en un tiempo de dos semanas con ejecución de las actividades: conocer, entender y apropiar el protocolo de comunicación y revisar las tramas de comunicación para así lograr la ingeniería inversa.
Posterior al análisis, se efectuó la fase inicial de desarrollo en cuatro semanas donde se ejecutaron las tareas de crear un agente intermedio por medio de Java para extraer la información del dispositivo, crear un servidor por medio de Java para establecer la comunicación con el dispositivo, hacer la conexión del servidor con la base de datos para guardar la información y subir los datos a la página web.
A partir de la semana 8 y al tener el desarrollo inicial del aplicativo empezó el proceso de realizar las fases de pruebas, el análisis de los hallazgos, las correcciones a estos.
Al lograr tener el aplicativo funcionando establemente con el desarrollo inicial se empezó la segunda fase de análisis donde se extrajo el video del servidor nativo, se realizó la segunda fase de desarrollo en el que se embebió el video en la página web y se empezaron a ejecutar las pruebas en un periodo de una semana.
40
Al lograr apropiar los conocimientos de la nueva función, se realizó la tercera fase de desarrollo con el cumplimiento de las siguientes tareas: crear un agente intermedio para extraer el video del dispositivo, crear un servidor por medio de Java para visualizar el video del dispositivo, realizar la visualización del video de forma autónoma y embeber el video en la página WEB de forma autónoma. Estas actividades se ejecutaron en un periodo de tiempo de 5 semanas.
Para la semana 16 se realizó la última fase de pruebas y la fase de implementación donde se midió el funcionamiento del aplicativo con todas las funciones en un automóvil, se identificaron los hallazgos y se realizaron las correcciones que den a lugar. Al cumplir con el objetivo del proyecto en su totalidad se entregó el producto a la empresa para que puedan hacer su salida a producción.
41
4.2 PRODUCTO
De acuerdo al plan de trabajo se entregó un servidor funcional desarrollado en el lenguaje de Java, estable y dinámico para recibir, procesar y responder a las tramas de control entregadas por el dispositivo MDVR. Adicionalmente se entregó un servidor desarrollado de igual forma en el lenguaje Java para direccionar las tramas de video y posteriormente procesarlas por medio del framework FFmpeg, a este framework se le asignaron los comandos necesarios para guardar el video y además distribuirlo gracias al servidor web, desarrollado sobre la plataforma Node.js, de tal forma que se pueda transmitir cada cámara por un puerto distinto y visualizarlo en un archivo php.
42
4.3 IMPACTOS DEL TRABAJO DE GRADO
Como se ha planteado en todo el desarrollo del proyecto el mayor impacto es generar un producto innovador en Colombia, que tiene un gran mercado, puesto que al ser altamente visual y muy práctico para reportar información con respecto a las actividades realizadas dentro del vehículo.
Por otra parte, se generó un producto totalmente autónomo, totalmente maleable y con la capacidad de moldearse a cada usuario dependiendo de las necesidades y cumpliendo así la misión de la empresa Wavecomm Corporation: dar manejo, proyección, información y soporte a la medida.
A nivel personal este trabajo cambio mi perspectiva, al situarme bajo una experiencia nueva y real de la vida laboral, aportándome conocimientos que me hicieron crecer a nivel profesional y académico.
43
CAPÍTULO 5
5.1 EVALUACION Y CUMPLIMIENTO DE LOS OBJETIVOS DE LA
PASANTIA
5.1.1 Cumplimiento del objetivo general
Se insertó el video y los datos de ubicación en la página web de producción de la empresa, entregados por medio de un dispositivo MDVR, para monitorear de forma visual las condiciones de velocidad, aceleración, posición, entre otras, de un automóvil de tal forma que se encuentre disponible para los dueños del activo, haciendo posible la supervisión objetiva y dinámica del trabajo dentro del automóvil.
5.1.2 Cumplimiento de los objetivos específicos
1. Se estudió y se analizó a cabalidad el dispositivo, el protocolo de comunicación de control, de los datos y del video.
2. Se creó el servidor de control con la capacidad de: realizar una comunicación exitosa con el dispositivo, extraer la información de ubicación de forma adecuada y subirla a la base de datos.
3. Se implementó el video de forma adecuada en la plataforma web usando, en un primer desarrollo el servidor nativo.
44
CAPÍTULO 6
6.1 CONCLUSIONES
En la industria del monitoreo vehicular se logró obtener de forma satisfactoria un dispositivo con sus servidores adecuados para suministrar información y video en tiempo real, y de esa forma ayudar a ese mercado y a la empresa a ampliar sus productos y así generar un avance tecnológico.
El proyecto tiene implícito en sí mismo, el obstáculo de la falta de información de los protocolos de comunicación y documentación del producto, sin embargo, el manejo de este por medio de ingeniería inversa fue satisfactorio.
Al desconocer el protocolo de información se debió crear desde los cimientos los servidores y procesamientos necesarios para desarrollar el proyecto, dando así, un manejo profundo y total de la información.
Se requirió adquirir conocimientos profundos en las áreas de telemática y compresión de video para poder manejar toda la comunicación TCP, principalmente para el streaming de video, pues son tramas altamente codificadas y de difícil manejo.
45
6.2 REFERENCIAS
[1] «Codificación H264,» [En línea]. Available: http://www.h264encoder.com/. [2] «Socket UDP y TCP,» [En línea]. Available:
https://www.programacion.com.py/escritorio/java-escritorio/sockets-en-java-udp-y-tcp. [3] «Adobe HDS,» [En línea]. Available:
https://www.wowza.com/forums/content.php?621-Understanding-streaming-protocols-and-output-file-formats.
[4] «Adobe RTMP,» [En línea]. Available: http://www.adobe.com/devnet/rtmp.html. [5] «Definicion MP4,» [En línea]. Available:
https://www.techopedia.com/definition/10713/mp4.
[6] «Definicion FLV,» [En línea]. Available: http://es.leawo.com/knowledge/flvf4v.html. [7] «Manejador NPM,» [En línea]. Available: https://www.npmjs.com/.
[8] «Entorno NodeJs,» [En línea]. Available: https://nodejs.org/es/.
[9] K. Finley, «Readwrite,» 2011. [En línea]. Available: http://readwrite.com/2011/01/25/wait-whats-nodejs-good-for-aga/.
[10] «FFmpeg,» 2017. [En línea]. Available: https://ffmpeg.org/. [11] C. University, «Computer Science,» 2017. [En línea]. Available:
http://www.cs.columbia.edu/~hgs/rtsp/. [12] Adobe, «Adobe,» 2017. [En línea]. Available:
http://www.adobe.com/products/flashruntimes.html.
[13] W. RTC, «Web RTC,» 2017. [En línea]. Available: https://webrtc.org/.
[14] M. P. E. Grupos, «MPEG,» 2017. [En línea]. Available: http://mpeg.chiariglione.org/. [15] I. T. S. Sector, «ITU,» 2017. [En línea]. Available:
http://www.itu.int/en/ITU-T/about/Pages/default.aspx.
46 [17] «Netty Project,» 2017. [En línea]. Available: http://netty.io/.
[18] T. S. Committee, «NodeJs,» 2017. [En línea]. Available: https://nodejs.org/en/.
6.3 PÁGINAS DE CONSULTA
6.3.1 MPEG
http://es.slideshare.net/VijayKumarArya/video-compression-basics-mpeg2
6.3.2 H264
http://www.openh264.org/
https://github.com/cisco/openh264
http://www.mainconcept.com/products/for-developers/codec-sdk/video/h264avc.html http://www.videolan.org/developers/x264.html
https://github.com/buggedcom/phpvideotoolkit-v2/blob/master/src/PHPVideoToolkit/VideoFormat/H264.php
http://www.digital-digest.com/articles/mp4_h264_playback_page2.html
http://stackoverflow.com/questions/2165593/how-to-decode-h-264-video-frame-in-java-environment
https://github.com/jcodec/jcodec http://mediaelementjs.com/
https://www.mozilla-hispano.org/videos-en-html5-y-codecs/ https://github.com/sannies/mp4parser
http://h264.code-shop.com/trac/wiki/WikiStart http://www.video-to-flash.com/f4v-h264-flv/
47
6.3.4 Video estático en JavaScript
48
6.3.9 Recepción y transmisión de video
49 https://bgrins.github.io/videoconverter.js/demo/
http://ffmpeg.org/ffmpeg.html#segment_002c-stream_005fsegment_002c-ssegment https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
6.3.14 FFserver
http://stackoverflow.com/questions/35452737/ffmpeg-convert-rtp-to-mp4http-streaming?rq=1
6.3.15 Node.js
http://www.nodebeginner.org/index-es.html
http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets https://github.com/phoboslab/jsmpeg
