Embed Size (px)
Citation preview
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.
2017
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.
2017
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á.
4
A mis padres, mi hermana,
a cada persona que han aportado
su granito para ser quien soy.
Para Dios.
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 MARCO TEÓRICO ................................................................................................................. 12
2.1.1 MPEG ............................................................................................................................ 12
2.1.2 H264 .............................................................................................................................. 12
2.1.3 RTP ................................................................................................................................ 13
2.1.4 HLS ................................................................................................................................ 14
2.1.5 Node.js .......................................................................................................................... 14
2.1.6 WebRTC......................................................................................................................... 14
2.1.7 Flash .............................................................................................................................. 14
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
2.1.14 FFmpeg ....................................................................................................................... 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
1.3 OBJETIVOS
1.3.1 Objetivo general.
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.
Por otra parte, Wavecomm Corporation busca ser innovadora en el mercado de monitoreo e
implícitamente de desarrollo de software y ofrecer un producto que cumpla las necesidades de
control y vigilancia de cada una de las empresas que tienen recursos físicos como vehículos.
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.
El estándar H.264 es un códec diseñado en conjunto por VCEG (Visual Coding Experts Group) y
MPEG de tal forma que reduce la cantidad de información necesaria para reproducir y transmitir
un vídeo. Este codificador procesa cada fotograma, subdividiendo la imagen en una cuadrícula
de bloques y buscando fotogramas anteriores o futuros para cada bloque con el fin de encontrar
una textura coincidente, una técnica denominada estimación del movimiento. Cuando se
encuentra una textura adecuada, un decodificador puede reproducir la textura del bloque en el
fotograma actual usando sólo un vector que apunta a la textura de referencia coincidente con
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.
A pesar de ser el protocolo que se usa
en el mercado de forma general, el
dispositivo que manejamos no lo usa,
pues envía las tramas por medio del
protocolo TCP.
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.
Sin embargo, esta instancia está siendo retirada de los navegadores por diferentes razones, entre
ellas las futuras prebendas que se puedan generar ya que flash player pertenece a una empresa
privada, además de que no es amigable con los dispositivos móviles, mientras que su
contraparte hmtl5 que es totalmente abierto y se puede ver en dispositivos móviles, aunque aún
está en desarrollo.
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.
El manejo del socket como servidor se remite a crear el socket, indicar porque puerto se escucha
y se espera a la llamada de un cliente para aceptar la conexión, en cambio de cliente creará el
socket e indicará dónde se encuentra y por qué puerto quiere conectarse, de esta forma Cliente
y Servidor crearán una conexión.
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
Una forma de transmisión de streaming de video es transmitir contenido de video a pedido por
VOD al programa Adobe Flash Player, mediante el protocolo adobe HTTP Dynamic Streaming
(Adobe HDS), este protocolo usa un archivo XML para describir la lista de tramas disponibles
para su transmisión. [3]
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
Es un protocolo que controla uno o más flujos multimedia, ya sea video o audio. Ya que este
actúa como un mando a distancia mediante la red para servidores multimedia, por medio de
protocolo HTTP. El protocolo RTSP es no orientado a la conexión, sin embargo, para el manejo
del control multimedia maneja el protocolo TCP, para el manejo de los paquetes de video por
lo general se maneja UDP pues pueden perderse los datos sin afectar la transmisión completa,
sin embargo, también se puede manejar multimedia transmitida por TCP.
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
Es el Framework líder en multimedia, capaz de decodificar, codificar, transcodificar,
multiplexar, demultiplexar, transmitir y filtrar los archivos multimedia creados de forma digital
o análoga y posteriormente digitalizada, soporta desde los formatos más antiguos hasta la
vanguardia. Una de las grandes características es su gran portabilidad.
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
Es un entorno de ejecución para JavaScript construido con el motor de JavaScript V8 de
Chrome. Node.js usa un modelo de operaciones E/S sin bloqueo y orientado a eventos, que lo
hace liviano y eficiente. El ecosistema de paquetes de Node.js, npm [7], que es su manejador
de paquetes, es el ecosistema más grande de librerías de código abierto en el mundo. [8]
Node.js es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa
del servidor basado en el lenguaje de programación ECMAScript, asíncrono, con entradas y
salidas de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google.
Fue creado con el enfoque de ser útil en la creación de programas de red altamente escalables,
como, por ejemplo, servidores web. [9]
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:
Para iniciar el proceso de conocimiento del
dispositivo se instaló el servidor nativo, el
cual maneja servicios internos como el
servicio de control, también llamado
Gateway, el servicio de video o multimedia
y el servicio web, como se puede observar
en la siguiente figura.
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.
Configuración general
22
Configuración ID dispositivo
Configuración dirección IP y puertos del servidor
Configuración APN de SIMCARD avantel
23
Configuración visualización del video y tiempos de grabación
Configuración transmisión de video
Configuración alarma de movimiento
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
La entrada del dispositivo acepta voltajes en el rango de 8 a 36 voltios DC, si no se cumple este
rango entrará a un modo de protección, dicho modo no ha sido probado.
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
En las pruebas se obtuvo que, bajo condiciones básicas, sin transmisión de video, la corriente
rodea 1 A. Sin haber activado los leds de la cámara para zonas oscuras, al activar dichos leds
se eleva la corriente en 200mA.
26
Corriente sin activar led de zonas oscuras ni transmisión de video:
Corriente con los leds de zonas oscuras activados, pero sin 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.
Adicionalmente, se conoce la estructura de la trama de control para que en la fase de desarrollo
se haga el parseo y la respuesta de forma adecuada.
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:
193,<Número serial>,X123,,<fecha y hora>,<Longitud>,<Latitud>,<velocidad
>,<…>,<odómetro >,<…>,<Ip>,<puerto>,<…>
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:
031,<Número serial>,X345,,<fecha y hora>
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:
171,<Número serial>,X456,,<fecha y hora>,<Longitud>,<Latitud>,,<Velocidad
>,<…>,<odómetro>,<…>, Y654,<fecha y hora de la solicitud>,0,1
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.
Al hacer esa revisión, se conoce que manejan la visualización por medio de contenido flash y
usando la librería swfObject.
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
Se implementó y se dejó funcionando desde la plataforma web Wavetrack, finalmente se
encontró que su trabajo se desarrolló de forma correcta. Se puede observar la implementación
en la siguiente imagen.
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
El streaming de video es comprimido por medio del protocolo h264 para transmisión de video,
al analizar esa información por medio del software de monitoreo de red, Wireshark, se ven tramas
de longitud extensa y sin algún patrón reconocible dentro de las mismas, pero del cual se puede
ver que cada 30 tramas envían el mensaje con la bandera PSH activa. Con lo cual por falta de
más información se asumió que cada mensaje es un cuadro del video y que al completar los 30
cuadros se debe responder al dispositivo para continuar la conversación, de lo contrario el mdvr
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).
Filtro gráfico: modificando la escala a 352x240 (-vf scale=).
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.
Este servidor consta de una conexión por socket TCP en el modo de servidor por la cual recibe
las tramas de video el cual transmite por medio una conexión web a un puerto fijo y
determinado previamente al cual se conectará la interfaz de la plataforma web de la empresa.
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
Finalmente, la página web se incorporó en la plataforma web Wavetrack y se puso en
funcionamiento para ver su comportamiento en el tiempo, siendo un resultado satisfactorio y
cumpliendo los objetivos.
37
La página final se muestra a continuación.
Reproduciendo video
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.
La mayor dificultad del proyecto, fue la falta de información de los protocolos de
comunicación, en especial de la transmisión de streaming de video. Sin embargo, este
inconveniente fue superado en forma satisfactoria logrando la ejecución total de los objetivos,
de esta forma no se hace necesaria una acción parcial del servidor nativo para obtener el video
y poder generar el monitoreo de forma adecuada.
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.
Para la semana 10 se inició la tercera fase de análisis donde se realizaron las actividades de
analizar la trama de video y conocer, entender y apropiar el protocolo de transmisión del
mismo, para poder incluir esta función en el aplicativo.
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.
Cabe resaltar que durante las 16 semanas se realizó la documentación del proyecto, incluyendo
conocimientos adquiridos, hallazgos en las pruebas y la descripción de cómo se realizó el ajuste
a las mismas, el proceso de desarrolló con su código y protocolos. Al finalizar el proyecto se
entregó junto al aplicativo toda la documentación para que se pueda desplegar por la
organización y sus diferentes miembros.
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.
De esta forma se entrega un producto de posicionamiento global y de video en tiempo real con
su respectiva documentación, procesamiento y visualización sobre la plataforma web
empresarial llamada Wavetrack.
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.
4. Se insertó a la plataforma web de la empresa, Wavetrack, el video de forma
autónoma con base a las tramas del video suministradas por el dispositivo. Se
implementó el dispositivo en un automóvil con la visualización en tiempo real, además
de los datos de ubicación.
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.
En el desarrollo de un proyecto de producción se debe tener en cuenta todos los aspectos
de los equipos que se vayan a manejar, pues, aunque el proyecto se enfocó en el manejo de
las tramas e información procedentes, también se debió conocer y analizar los aspectos
físicos del dispositivo
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.
[16] Cisco, «OpenH264,» 2017. [En línea]. Available: http://www.openh264.org/.
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/
https://docs.oracle.com/javase/tutorial/essential/io/buffers.html
47
http://lists.live555.com/pipermail/live-devel/2014-November/018891.html
https://github.com/volvet/h264extractor
http://gregorio.stanford.edu/sliang/rtm.pdf
http://www.ti.com.cn/cn/lit/an/sprab88/sprab88.pdf
6.3.3 RTP
http://stackoverflow.com/questions/18857737/decoding-h264-frames-from-rtp-stream
http://www.ehowenespanol.com/rtmp-vs-rtsp-info_194194/
6.3.4 Video estático en JavaScript
https://librosweb.es/libro/javascript/capitulo_1.html
https://msdn.microsoft.com/en-us/library/hh924823(v=vs.85).aspx
http://www.w3schools.com/tags/av_met_play.asp
https://msdn.microsoft.com/en-us/library/hh924822(v=vs.85).aspx
6.3.5 Node.js
http://binaryjs.com/
https://github.com/binaryjs/binaryjs/blob/master/doc/start.md
http://html5facil.com/tutoriales/streaming-de-video-con-html5/
6.3.6 WebRTC
https://bitbucket.org/webrtc/codelab
https://webrtc.github.io/samples/
http://foro.syscom.mx/index.php?p=/discussion/128/agregar-un-dvr-o-una-camara-ip-a-
mi-sitio-web
http://www.html5rocks.com/en/tutorials/webrtc/basics/
https://developers.google.com/web/updates/2012/12/Screensharing-with-WebRTC
6.3.7 Flash
http://blog.deconcept.com/swfobject/
https://azure.microsoft.com/en-us/documentation/articles/media-services-use-osmf-
smooth-streaming-client-plugin/
48
6.3.8 Comunicación TCP
http://www.programacion.com.py/escritorio/java-escritorio/sockets-en-java-udp-y-tcp
http://www.redeszone.net/2010/11/20/taller-de-practicas-cliente-y-servidor-tcp-en-java/
https://en.wikipedia.org/wiki/Differentiated_services
https://tools.ietf.org/html/rfc2597
https://tools.ietf.org/html/rfc3260
http://stackoverflow.com/questions/14267923/reading-and-writing-tcp-header-options-in-
java
6.3.9 Recepción y transmisión de video
http://blog.rolandopalermo.com/2010/08/transmision-de-video-usando-sockets-en.html
http://blog.rolandopalermo.com/2010/06/procesamiento-de-video-en-tiempo-real.html
6.3.10 Adobe HDS
https://www.wowza.com/forums/content.php?621-Understanding-streaming-protocols-
and-output-file-formats
6.3.11 RTSP
http://lists.live555.com/pipermail/live-devel/2014-November/018891.html
http://lists.live555.com/liveMedia/
http://stackoverflow.com/questions/18936051/how-can-i-force-wireshark-to-decipher-
some-types-of-protocols-if-it-doesnt-reco
http://www.csee.umbc.edu/~pmundur/courses/CMSC691C/lab5-kurose-ross.html
6.3.12 Netty
http://netty.io/index.html
https://netty.io/4.0/api/io/netty/handler/codec/rtsp/package-summary.html
http://flazr.com/
http://www.xuggle.com/xuggler
http://netty.io/4.1/api/index.html
6.3.13 FFmpeg
http://unick-soft.ru/article.php?id=14
https://trac.ffmpeg.org/wiki/StreamingGuide
https://www.ffmpeg.org/
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
https://carlosazaustre.es/blog/websockets-como-utilizar-socket-io-en-tu-aplicacion-web/
