Evaluacion de Servidores de Streaming
-
Upload
edgar-saloma -
Category
Documents
-
view
36 -
download
1
Transcript of Evaluacion de Servidores de Streaming
EVALUACION DE SERVIDORES DE STREAMING DE VIDEO ORIENTADO A
DISPOSITIVOS MOVILES
JUAN PABLO QUINTERO ORTIZ
CRISTIAN ANDREY CASTRO SERNA
Proyecto de grado para optar al título de Ingeniero Electrónico
Asesor
Ph.D José Edinson Aedo
UNIVERSIDAD DE ANTIOQUIA
FACULTAD DE INGENIERÍA
DEPARATAMENTO DE INGENIERÍA ELECTRÓNICA
MEDLLÍN
2006
NOTA DE ACEPTACIÓN
La Universidad de Antioquia, y en nombre el Departamento de Ingeniería
Electrónica, decide aprobar el siguiente proyecto de grado como requisito para
optar el título de Ingeniero Electrónico.
________________________ ________________________
Jurado 1
Jurado 2
Agradecimientos
Agradezco a Dios por brindarme todo
lo que tengo, a mi Madre, a mi Padre,
a mis Hermanos, por ser mi bastión y
mi ejemplo, a mi novia y a mis
amigos, que son los hermanos del
alma.
Juan Pablo Quintero Ortiz.
No Hay palabras en este universo ni
en ningún otro para agradecerles por
todo lo maravilloso que me han dado
mis padres, mi familia y mis amigos.
Cristian Andrey Castro Serna
TABLA DE CONTENIDOS
INTRODUCCIÓN .................................................................................................... 1
OBJETIVOS ............................................................................................................ 4
1. CARACTERISTICAS DE LAS COMUNICACIONES INALÁMBRICAS ............... 5
1.1 Ondas de Radio............................................................................................. 5
1.2 Frecuencias y canales ................................................................................... 8
1.3 Fenómenos que afectan las transmisiones de radiofrecuencia ..................... 9
1.3.1 Absorción ................................................................................................ 9
1.3.2 Reflexión ............................................................................................... 10
1.3.3 Interferencia .......................................................................................... 11
1.4 Estándares de Comunicaciones inalámbricas en redes WLAN................... 12
1.5 Esquemas de modulación usados en 802.11 a/b/g ..................................... 13
1.5.1 DSSS Espectro Ensanchado por Secuencia Directa ............................ 14
1.5.2 FHSS Espectro Ensanchado por Salto de Frecuencia.......................... 15
1.6 Efectos de la movilidad en el desempeño de un servicio de streaming....... 15
2. CONCEPTOS DE VIDEO DIGITAL................................................................... 18
2.1 Captura de video ......................................................................................... 18
2.2 Formatos de video ....................................................................................... 19
2.3 Codificación de video................................................................................... 20
2.4 Estándares de codificación de video ........................................................... 24
2.4.1 Estándares desarrollados por la ITU..................................................... 25
2.4.2 Estándares desarrollados por la ISO/IEC.............................................. 28
3. CONCEPTOS DE STREAMING ....................................................................... 33
3.1 Introducción ................................................................................................. 33
3.2 Distribución de video.................................................................................... 34
3.2.1 Bajo demanda ....................................................................................... 34
3.2.2 En vivo .................................................................................................. 35
3.3 Esquemas de distribución............................................................................ 36
3.3.1 Broadcast .............................................................................................. 36
3.3.2 Unicast .................................................................................................. 37
3.3.3 Multicast ................................................................................................ 38
3.4 Protocolos.................................................................................................... 39
3.4.1 ProtocoloTCP........................................................................................ 40
3.4.2 Protocolo UDP ...................................................................................... 41
3.4.3 Protocolo RTP....................................................................................... 42
3.4.4 Protocolo RTSP..................................................................................... 42
3.4.5 Protocolo SCTP..................................................................................... 43
3.5 Funcionamiento de un servicio de Streaming .............................................. 44
4. SERVIDORES DE STREAMING....................................................................... 47
4.1 VLS Descripción general ............................................................................. 49
4.1.1 Componentes VLS ................................................................................ 50
4.1.2 Arquitectura General ............................................................................. 51
4.1.3 Descripcion de Clases Comunes .......................................................... 52
4.1.4 Como es el proceso de Broadcasting?.................................................. 55
4.2 Darwin Streaming Server............................................................................. 56
4.2.1 Arquitectura del servidor ....................................................................... 56
4.2.2 Modulos................................................................................................. 58
4.2.3 Protocolos ............................................................................................. 59
4.3 Helix Server ................................................................................................. 60
4.3.1 Cliente/Servidor Protocolos soportados ................................................ 61
4.3.2 Plug-ins ................................................................................................. 62
4.3.3 Streaming desde el Helix Universal Server ........................................... 63
4.3.4 Sirviendo múltiples Streams.................................................................. 65
4.3.5 Comunicación mediante HTTP ............................................................. 65
4.3.6 Manejo de memoria............................................................................... 66
4.3.7 Manejo de Sesión.................................................................................. 67
5. PLAN DE PRUEBAS......................................................................................... 69
5.1 Metodología ................................................................................................. 69
5.2 Resultados................................................................................................... 73
5.2.1 Diferentes ratas de compresión para cada servidor .............................. 73
5.2.2 Diferentes servidores para cada rata de compresión............................ 75
5.2.3 Comparación de consumo de corriente con el radio a pagado y un
stream determinado para cada servidor......................................................... 77
5.2.4 Graficas de tráfico de red ...................................................................... 82
CONCLUSIONES.................................................................................................. 87
ANEXO 1. ACPI .................................................................................................... 92
ANEXO 2. PORTAL DE GESTION DE CONTENIDO ........................................... 97
BIBLIOGRAFIA ................................................................................................... 103
LISTA DE FIGURAS
Figura 1. Longitud de onda, Amplitud y Frecuencia de una onda de 2 ciclos por segundo............... 6
Figura 2. Espectro electromagnético ........................................................................................... 7
Figura 3. Canales y frecuencias centrales en el estándar 802.11b ................................................. 8
Figura 4. Cobertura por celdas evitando superposición de canales ................................................ 8
Figura 5. Ángulos de incidencia y reflexión ................................................................................ 10
Figura 6. Fenómeno de reflexión en antenas parabólicas............................................................ 11
Figura 7. Interferencia constructiva y destructiva....................................................................... 11
Figura 8. Transición entre Celdas.............................................................................................. 16
Figura 9. Proceso de captura de video ...................................................................................... 18
Figura 10. Modelo de distribución Bajo demanda ....................................................................... 35
Figura 11. Modelo de distribución en vivo.................................................................................. 36
Figura 12. Modelo de distribución Broadcast.............................................................................. 37
Figura 13. Modelo de distribución Unicast ................................................................................. 37
Figura 14. Modelo de distribución Multicast ............................................................................... 38
Figura 15. Implementación de servicio de streaming.................................................................. 44
Figura 16. Reproducción de contenido almacenado en el buffer de recepción .............................. 46
Figura 17. Estructura general de un servicio implementado con VideoLAN................................... 49
Figura 18. Módulos componentes de VLS .................................................................................. 50
Figura 19. Arquitectura VLS...................................................................................................... 51
Figura 20. Gestión de streaming en el VLS ................................................................................ 52
Figura 21. Clases comunes en el VLS ........................................................................................ 54
Figura 22. Diagrama de inicio de stream en el VLS ................................................................... 55
Figura 23. Esquema de envio del paquete TS en el VLS ............................................................. 55
Figura 24. Relación Clientes, hilos del núcleo del servidor y modulos del Darwin Streaming Server 57
Figura 25. Arquitectura del Helix Universal Server...................................................................... 61
Figura 26. Streaming desde el Helix Server hacia el Real Player.................................................. 63
Figura 27. Distribución de múltiples streams en el Helix Server.................................................. 65
Figura 28. Tunelamiento de Streaming sobre HTTP ................................................................... 66
Figura 29. Control de sesión en el Helix Server .......................................................................... 68
Figura 30. Plataforma de pruebas ............................................................................................. 70
Figura 31. Plataforma de pruebas en el laboratorio de Microelectrónica y control......................... 71
Figura 32. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el VLS. 74
Figura 33. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el Darwin
Streaming Server..................................................................................................................... 74
Figura 34. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el Helix
Server..................................................................................................................................... 75
Figura 35. Consumo de corriente [mA] en el cliente debido al stream de 112Kbit en cada uno de los
servidores ............................................................................................................................... 76
Figura 36. Consumo de corriente [mA] en el cliente debido al stream de 256Kbit en cada uno de los
servidores ............................................................................................................................... 76
Figura 37. Consumo de corriente [mA] en el cliente debido al stream de 512Kbit en cada uno de los
servidores ............................................................................................................................... 77
Figura 38. Comparación de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con
stream de 112Kbit ................................................................................................................... 78
Figura 39. Comparación de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de
112Kbit ................................................................................................................................... 78
Figura 40. Comparación de consumos de corriente [mA] Radio OFF Vs VLS con stream de 112Kbit
.............................................................................................................................................. 79
Figura 41. Comparación de consumos de corriente [mA] Radio OFF Vs VLS con stream de 256Kbit
.............................................................................................................................................. 79
Figura 42. Comparación de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con
stream de 256Kbit ................................................................................................................... 80
Figura 43. Comparación de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de
256Kbit ................................................................................................................................... 80
Figura 44. Comparación de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de
512Kbit ................................................................................................................................... 81
Figura 45. Comparación de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con
stream de 512Kbit ................................................................................................................... 81
Figura 45. Comparación de consumos de corriente [mA] Radio OFF Vs VLS con stream de 512Kbit
.............................................................................................................................................. 82
Figura 46. Tráfico de datos con stream de 112Kbits servidos por el VLS...................................... 82
Figura 47. Tráfico de datos con stream de 256Kbits servidos por el VLS...................................... 83
Figura 48. Tráfico de datos con stream de 512Kbits servidos por el VLS...................................... 83
Figura 49. Tráfico de datos con stream de 112Kbits servidos por el Darwin Streaming Server....... 84
Figura 50. Tráfico de datos con stream de 256Kbits servidos por el Darwin Streaming Server....... 84
Figura 51. Tráfico de datos con stream de 512Kbits servidos por el Darwin Streaming Server....... 85
Figura 52. Tráfico de datos con stream de 112Kbits servidos por el Helix Server.......................... 85
Figura 53. Tráfico de datos con stream de 256Kbits servidos por el Helix server .......................... 86
Figura 54. Tráfico de datos con stream de 512Kbits servidos por el Helix Server.......................... 86
Figura 55. Búsqueda rápida...................................................................................................... 98
Figura 56. Búsqueda por descripción de campo ......................................................................... 99
Figura 57. Búsqueda alfabética................................................................................................101
Figura 58. Grabación de contenido...........................................................................................102
LISTA DE TABLAS
Tabla 1. Características de la familia de estándares inalámbricos 802.11 (Wi-Fi) .......................... 13
Tabla 2. Características del estándar inalámbrico 802.11n.......................................................... 13
Tabla 3. Formatos de video digital ............................................................................................ 20
Tabla 4. Partes MPEG-1 ........................................................................................................... 29
Tabla 5. Partes de MPEG-2....................................................................................................... 30
Tabla 6. Partes de MPEG-4....................................................................................................... 32
Tabla 7. Características de los servidores de streaming en evaluación......................................... 89
Tabla 8. Consumos de corriente [mA] promedio a diferentes ratas de compresión....................... 90
INTRODUCCIÓN
Se puede pensar en la sociedad actual como la sociedad de las comunicaciones,
donde todos y cada uno de nosotros ha tenido que adoptar nuevas y cada vez más
sofisticadas tecnologías que nos han llevado a un mundo donde el estar
comunicados es prerrequisito indispensable para vivir en sociedad. Y es en este
contexto que las nuevas tecnologías imprimen un cambio radical en la concepción
de las posibilidades de los servicios que hasta ahora se habían ofrecido. El auge
cada vez mayor de los dispositivos móviles han hecho de las comunicaciones un
escenario que años atrás era casi impensado.
En la actualidad no basta solo con poder comunicarnos de la manera tradicional,
sino que la aparición de nuevos y revolucionarios servicios han creado un entorno
donde la interactividad y la comunicación no solo por voz sino por video se
convertirá a futuro en la manera tradicional en la cual nos comunicaremos. Dentro
de este nuevo entorno los dispositivos móviles juegan un papel más que
importante. Gracias a ellos el mundo ha sufrido un cambio realmente
sorprendente, donde el estar en continuo contacto con el mundo dejó de ser una
utopía para pasar a convertirse en una realidad que cambió para siempre nuestras
vidas.
No obstante estas ventajas existen inconvenientes y la movilidad trae implícita
retos que aun se están afrontando como la limitada capacidad de almacenamiento,
procesamiento, consumo eficiente de energía y otros que continuarán surgiendo a
medida que se avance en la prestación de diferentes tipos de servicios en
dispositivos móviles, tales como el desarrollo de protocolos de transporte que sean
sensibles a los cambios continuos en los niveles de señal inherentes a los sistemas
2
móviles, estas limitaciones imponen lineamientos claros en pro de suplir tales
carencias o ayudar a sobrellevarlas mas fácilmente.
Es así que han surgido muchas propuestas, no solo en lo que tiene que ver en la
parte de hardware, también con el software, que han permitido que estos
dispositivos tengan prestaciones cada vez mejores.
El desarrollo de hardware y software basados en criterios de bajo consumo de
energía, la implementaron de sistemas de hardware dinámicamente reconfigurable
y la utilización de técnicas de streaming para la optimización en el uso de los
sistemas de almacenamiento, son soluciones que están orientadas a dotar al
dispositivo móvil de características que le permitan estar a la vanguardia de los
esquemas de comunicaciones actuales; en los cuales la interactividad y la difusión
de contenido multimedia ha adquirido una importancia cada vez mayor y se ha
convertido en algo indispensable en la concepción de un dispositivo móvil.
De este entorno tan exigente surge el concepto de streaming de video en tiempo
real, como un servicio que toma cada día mas fuerza y que posibilita la difusión de
contenido multimedia en dispositivos móviles, que seria casi que imposible de otra
manera.
El concepto de streaming nace de la necesidad de difundir contenido multimedia a
través del Internet sin la necesidad de descargar todo el tamaño del archivo, y
permitir un grado de interactividad en tiempo real. Para difundir este tipo de
contenido multimedia se hace necesario de un servidor de streaming, que permita
gestionar las conexiones y anchos de banda que los usuarios conectados al
sistema están solicitando.
3
Aunque el surgimiento de los servidores de streaming ha solucionado en gran
parte el problema de difusión de contenido multimedia en Internet, esta solución
fue orientada en un principio a equipos de escritorio, y no a dispositivos móviles
por lo que aun son precarias las soluciones que se ofrecen en este aspecto.
Es precisamente por dicha carencia que este trabajo se torna realmente
importante, surge en la necesidad de orientar los esquemas actuales de los
servidores de streaming hacia los dispositivos móviles. Primero haciendo una
evaluación de los servidores de streaming mas conocidos, en cuanto al desempeño
que éstos indirectamente le proporcionen al dispositivo y por último haciendo una
evaluación de cuáles criterios cobran mayor importancia en el esquema de un
servidor de streaming de contenido multimedia orientado a dispositivos móviles.
4
OBJETIVOS
Objetivo general:
Evaluar diferentes tipos de servidores de streaming con el fin de sugerir las
características mas adecuadas para ofrecer un servicio orientado a clientes en
dispositivos móviles.
Objetivos específicos:
� Establecer criterios de evaluación para los diferentes servidores de
streaming.
� Definir un plan de pruebas.
� Montaje y puesta a punto de los servidores seleccionados para la
evaluación.
� Implementación de un portal para el acceso de los clientes al material
multimedia por medio de la red.
� Obtención de los resultados mediante el desarrollo del plan de pruebas.
5
1. CARACTERISTICAS DE LAS COMUNICACIONES
INALÁMBRICAS
Las comunicaciones inalámbricas hacen uso de las ondas de radio para transmitir
la información, hablando en términos de los modelos de interconexión de sistemas
abiertos como el modelo OSI [1] o el TCP/IP [1], nos estamos refiriendo al nivel
mas bajo del modelo, el medio físico y el de acceso al medio (MAC) por lo tanto
desde el punto de vista de las aplicaciones no existe ninguna diferencia con una
transmisión por un medio cableado. Pero las ondas de radio poseen propiedades
determinantes en el momento de definir un buen enlace. No es posible saber la
ruta que sigue una onda de radio o evitar total mente que haya interferencia con
otras transmisiones en el entorno, algo que no sucede en una red cableada,
debido al confinamiento de la señal que proporciona el cable, no sucede.
1.1 Ondas de Radio
Una onda es la vibración periódica en el tiempo de un medio o material. Las ondas
de radio son por lo tanto vibraciones del campo electromagnético que están
definidas por características tales como su longitud de onda, frecuencia y
velocidad, una relación matemática de lo anterior está dada por:
Velocidad = Frecuencia * Longitud de Onda
6
Además de las propiedades anteriores, las ondas de radio poseen otra
característica, la amplitud, siendo ésta la distancia desde el centro de la onda
hasta el punto máximo.
Figura 1. Longitud de onda, Amplitud y Frecuencia de una onda de 2 ciclos por segundo.
Las ondas electromagnéticas abarcan un amplio rango de frecuencias, es
denominado espectro electromagnético, está compuesto por diferentes tipos de
radiación, Rayos-X, Ultravioleta, Luz visible, infrarrojo y otras más. El espectro
comprendido entre 3 Hz a 300 GHz, es llamado Radio frecuencias debido a que es
la porción del espectro en el que las ondas pueden ser transmitidas aplicando
corriente alterna a una antena.
7
Figura 2. Espectro electromagnético
Es muy popular el uso de frecuencias pertenecientes a la banda ISM [1], para la
transmisión de datos mediante ondas de radio, existen estándares como el IEEE
802.11 que hace uso de éstas debido a que esta banda se mantiene abierta para
uso general sin necesidad de licenciamiento, al contrario de la mayoría del resto
del espectro que se encuentran altamente controlados y el cual se usa para otro
tipo de comunicaciones como radio y televisión u otras comunicaciones de voz y
datos.
Un concepto que se maneja en relación con el uso de un rango de frecuencias
específico es el de ancho de banda, este es la parte del espectro que un dispositivo
está en capacidad de manejar o para el cual tiene un funcionamiento apropiado. El
ancho de banda está muy relacionado con la cantidad de datos que se pueden
transmitir en un momento dado. Esto es, por una conexión de 1 Mbps es posible
tener un flujo continuo de datos de 1 Mb cada segundo.
8
1.2 Frecuencias y canales
Haciendo énfasis en la banda ISM podemos ejemplificar el uso del espectro en el
estándar IEEE 802.11b, éste hace uso de las frecuencias cercanas a los 2,4 GHz y
se hace una división del espectro en partes iguales ó canales, cada uno con un
ancho de banda de 22 MHz pero separados solamente 5 MHz. Como consecuencia
los canales adyacentes se superponen y pueden interferir unos con otros.
Figura 3. Canales y frecuencias centrales en el estándar 802.11b
Como se visualiza en la figura anterior, los canales 1, 6 y 11 no se superponen, por
lo que son comúnmente usados en los sistemas inalámbricos adyacentes o en
sistemas de cobertura por celdas como se ilustra a continuación.
Figura 4. Cobertura por celdas evitando superposición de canales
9
Hay un hecho claro con respecto a la frecuencia de la onda sobre la cual viaja la
información, ya que afecta directamente la distancia de propagación.
Asumiendo niveles iguales de potencia en la transmisión, se tiene que las ondas de
más baja frecuencia viajan mayores distancias, o sea que un transmisor en los
77MHz emite a distancias mayores que uno a 108MHz.
Otro aspecto muy importante es que las ondas de menor frecuencia rodean los
obstáculos, esto es, si una onda de 4 metros de que viaja en el agua se encuentra
con un obstáculo en la superficie de unos cuantos milímetros ésta no se detiene,
pero si se topa con un barco la onda sufrirá atenuación. La distancia de
propagación de la onda depende también del tamaño de los obstáculos que ésta
se encuentra en su camino.
La sondas electromagnéticas no están exentas de este tipo de fenómenos, por
ejemplo, la radio FM comercial (88 MHz – 108 MHz) puede atravesar edificaciones
y obstáculos de este tipo fácilmente pero los teléfonos GSM (900 MHz),Na aunque
esto también se debe a la diferencia en la potencia de los transmisores de FM y
GSM. La gran ventaja que poseen las ondas radiadas a más altas frecuencias es
que mientras más rápida sea la oscilación, mayor cantidad de información puede
transportar.
1.3 Fenómenos que afectan las transmisiones de
radiofrecuencia
1.3.1 Absorción
Las ondas se debilitan o atenúan cuando atraviesan algún material, la cantidad de
potencia perdida depende del material y de la frecuencia de la onda. Para
10
determinar el impacto de determinado material sobre la onda se hace uso del
coeficiente de absorción.
Los dos materiales más absorbentes para las microondas son el agua y el metal,
en la práctica se consideran estos dos elementos como absorbentes perfectos, por
lo tanto los cambios climáticos que generen niebla, vapor ó lluvia inciden de
manera negativa en el radio enlace.
Para los árboles y la madera la absorción depende de la cantidad de agua que
contengan, para nosotros los humanos y los animales también aplica debido a que
para efectos de la onda de radio, somos básicamente agua.
1.3.2 Reflexión
Dependiendo del ángulo de incidencia de la onda en una superficie determinada se
puede presentar el fenómeno de Reflexión, el ángulo de incidencia de la onda
determina el ángulo de reflexión, ambos son iguales respecto al plano de
incidencia.
Figura 5. Ángulos de incidencia y reflexión
Debido a este fenómeno se presenta el efecto multitrayectoria (multipath), debido
a la reflexión de la onda cuando choca con los elementos que se encuentran en su
11
camino de propagación, esto causa que las señales lleguen al receptor por medio
de diferentes caminos con las implicaciones que esto conlleva en el retardo de las
mismas, este efecto juega un papel muy importante en la planeación y ejecución
de un enlace de radio siendo muchas veces imposible calcular la posible reflexión.
En el diseño de antenas se hace uso de este fenómeno para focalizar las ondas
incidentes.
Figura 6. Fenómeno de reflexión en antenas parabólicas
1.3.3 Interferencia
Existen dos tipos de interferencia, constructiva y destructiva, para que dos ondas
interfieran perfectamente en una de estas dos formas deben tener una relación de
fase fija e igual frecuencia.
Figura 7. Interferencia constructiva y destructiva
12
En la implementación de redes inalámbricas, la interferencia se asocia a todo tipo
de alteraciones causadas por otras redes en el entorno u otras fuentes de
microondas en la misma frecuencia. Siempre que existan ondas que se crucen y
posean las características descritas anteriormente se eliminan o se crean nuevas
ondas de las cuales es imposible leer la información que portan.
Para sobrellevar los problemas causados por la interferencia se hace uso de las
técnicas de modulación y el uso adecuado de los canales.
1.4 Estándares de Comunicaciones inalámbricas en redes
WLAN
En el contexto de las redes LAN [1] el estándar manejado es el IEEE 802.11 [2] ó
comúnmente llamado wi-fi (wíreless fidelity), fue desarrollado por el grupo de
trabajo 11 del comité de estándares de redes LAN/MAN.
El termino 802.11 es usado generalmente para denotar el estándar inicial al que
también se le llama 802.11 Legacy.
La familia 802.11 incluye 6 técnicas de modulación que usan el mismo protocolo,
las técnicas mas populares son las definidas por las enmiendas a, b y g, siendo el
802.11b el primer estándar ampliamente aceptado, seguido de 802.11a y luego
802.11g.
A continuación se muestra una tabla comparativa de las características mas
destacadas de los estándares mencionados.
13
Protocolo Lanzamiento Frecuencia
de operación
Rata de
Transmisión
(Típica)
Rata de
Transmisión
(Maxima)
Alcance en
interiores
Legacy 1997 2.4 GHz 1 Mbit/s 2 Mbit/s *
802.11a 1999 5 GHz 25 Mbit/s 54 Mbit/s ~30 mts
802.11b 1999 2.4 GHz 6.5 Mbit/s 11 Mbit/s ~30 mts
802.11g 2003 2.4 GHz 25 Mbit/s 54 Mbit/s ~30 mts
* No hay un dato estimado.
Tabla 1. Características de la familia de estándares inalámbricos 802.11 (Wi-Fi)
En Enero del 2004 se decidió formar un nuevo grupo de trabajo para desarrollar
una nueva enmienda de 802.11 cuyo nombre es 802.11n, la rata de transmisión
que se busca obtener esta estimada en 540 Mbit/s, la cual es 10 veces más que la
obtenida por los estándares 802.11a y 802.11b.
Para alcanzar esta rata de transferencia se hará uso de la tecnología MIMO
(multiple-input multiple-output), la cual permite el uso de múltiples antenas de
recepción y transmisión con lo que se puede implementar métodos de diversidad
espacial que permitan un incremento en el rango de rata de transferencia.
El objetivo es tener listo el estándar para el año 2008.
Protocolo Lanzamiento Frecuencia
de
operación
Rata de
Transmisión
(Típica)
Rata de
Transmisión
(Maxima)
Alcance en
interiors
802.11n Abril 2008 2.4 ó 5 GHz 200 Mbit/s 540 Mbit/s ~50 mts
Tabla 2. Características del estándar inalámbrico 802.11n
1.5 Esquemas de modulación usados en 802.11 a/b/g
14
1.5.1 DSSS Espectro Ensanchado por Secuencia Directa
En esta técnica de modulación se genera un patrón de bits redundante (señal de
chip) para cada uno de los bits que componen la señal. Cuanto mayor sea esta
señal, mayor será la resistencia de la señal a las interferencias. El estándar IEEE
802.11 recomienda un tamaño de 11 bits, pero el optimo es de 100. En recepción
es necesario realizar el proceso inverso para obtener la información original.
La secuencia de bits utilizada para modular los bits se conoce como codigo de
dispersión o pseudo ruido. Es una secuencia rápida diseñada para que aparezca
aproximadamente la misma cantidad de 1 que de 0. Un ejemplo de esta secuencia
en codificación Manchester es el siguiente. +1-1+1+1-1+1+1+1-1-1-1-1 Solo los
receptores a los que el emisor haya enviado previamente la secuencia podrán
recomponer la señal original. Además, al sustituir cada bit de datos a transmitir,
por una secuencia de 11 bits equivalente, aunque parte de la señal de transmisión
se vea afectada por interferencias, el receptor aún puede reconstruir fácilmente la
información a partir de la señal recibida.
Una vez aplicada la señal de chip, el estándar IEEE 802.11 ha definido dos tipos de
modulación para la técnica de espectro ensanchado por secuencia directa (DSSS),
la modulación DBPSK (Differential Binary Phase Shift Keying) y la modulación
DQPSK (Differential Quadrature Phase Shift Keying), que proporcionan una
velocidad de transferencia de 1 y 2 Mbps respectivamente.
La revisión IEEE 802.11b aumenta esta velocidad hasta los 11Mbps, lo que
incrementó notablemente el rendimiento de este tipo de redes.
15
1.5.2 FHSS Espectro Ensanchado por Salto de Frecuencia
La tecnología de espectro ensanchado por salto en frecuencia (FHSS) consiste en
transmitir una parte de la información en una determinada frecuencia durante un
intervalo de tiempo llamada dwell time e inferior a 400 ms. Pasado este tiempo se
cambia la frecuencia de emisión y se sigue transmitiendo a otra frecuencia. De
esta manera cada tramo de información se va transmitiendo en una frecuencia
distinta durante un intervalo muy corto de tiempo.
El orden en los saltos en frecuencia se determina según una secuencia pseudo
aleatoria almacenada en unas tablas, y que tanto el emisor y el receptor deben
conocer. Si se mantiene la sincronización en los saltos de frecuencias se consigue
que, aunque en le tiempo se cambie de canal físico, a nivel lógico se mantiene un
solo canal por el que se realiza la comunicación.
Esta técnica también utiliza la zona de los 2.4GHz, la cual organiza en 79 canales
con un ancho de banda de 1MHz cada uno. El número de saltos por segundo es
regulado por cada país, así, por ejemplo, Estados Unidos fija una tasa mínima de
saltas de 2.5 por segundo.
El estándar IEEE 802.11 define la modulación aplicable en este caso. Se utiliza la
modulación en frecuencia FSK (Frequency Shift Keying).
1.6 Efectos de la movilidad en el desempeño de un servicio de
streaming
El desempeño de un servicio de streaming se puede ver notablemente afectado en
presencia de un cliente móvil en la red, esto es debido a la inconsistencia en la
16
calidad del canal, intermitencia en la conexión, bloqueos de la señal en el ambiente
que introducen ruidos y ecos, y otros tipos de efectos generados por los
fenómenos que lleva implícita una transmisión por medio de ondas de radio, como
la reflexión, la difracción, la absorción y la interferencia, todos estos efectos
generan menor estabilidad en la conexión, disminución en el ancho de banda
efectivo y tasas de error mas altas.
Por lo general, los servicios de streaming se implementan sobre el protocolo UDP,
en el que no se hace retransmisiones debidas a las perdidas de paquetes, por lo
que la disminución en el rendimiento debido a retransmisiones no se presenta,
ésta situación se presenta cuando se usa el protocolo TCP donde la latencia se
hace notable.
Es claro entonces que los servicios de streaming sobre dispositivos móviles
enfrentan retos como la necesidad de mantener la calidad del servicio y mantener
una operación adecuada en ambientes heterogéneos. Esto ultimo se visualiza de
manera mas explicita cuando un dispositivo móvil sale del alcance de una celda de
radiación perteneciente a un Access Point e ingresa a otra, el la terminología de las
comunicaciones celulares esto se denomina handoff ó handover, esto sucede
cuando el dispositivo móvil detecta un nivel de señal mas fuerte de una de dos
estaciones base ó Access point y empieza a recibir el flujo de datos proveniente de
esta.
Figura 8. Transición entre Celdas
17
18
2. CONCEPTOS DE VIDEO DIGITAL
2.1 Captura de video
El video se captura usando una cámara o sistema de cámaras. La mayoría de los
sistemas digitales actuales utilizan video en 2-D, por lo cual utilizan solo una
cámara. La cámara enfoca una proyección 2-D de la escena de video sobre un
sensor, como por ejemplo un dispositivo de acoplamiento de carga (CCD por sus
siglas en ingles). En el caso de captura de imagen a color, cada componente de
color es filtrado y proyectado en un CCD independiente.
En la generación de una representación digital de una escena de video pueden
considerarse dos etapas:
• Adquisición: convertir una proyección de la escena en una señal eléctrica
por medio de un CCD por ejemplo.
• Digitalización: Muestrear la proyección espacial y temporalmente
convirtiendo cada muestra en un número o conjunto de números.
La digitalización puede llevarse a cabo utilizando una tarjeta o dispositivo
independiente, sin embargo ya muchas cámaras tienen integrada la etapa de
digitalización, por lo cual proporcionan una salida digital.
Figura 9. Proceso de captura de video
Captura PresentaciónProcesamiento/
Almacenamiento/Transmisión
Captura PresentaciónProcesamiento/
Almacenamiento/Transmisión
19
2.2 Formatos de video
Una señal de video tiene una amplia variedad de parámetros – resolución,
entrelazado vs. Progresivo, rata de frames, etc. Debido a la gran diversidad de
aplicaciones que utilizan video digital, se han desarrollado una serie de formatos
de video con los cuales se estandarizan los parámetros de una señal de video para
una aplicación específica. La tabla 1 lista los principales formatos de video digital
con sus respetivas resoluciones.
Formatos Video Digital Resolución Relación ancho/alto
Formatos de Gráficos de computador
VGA 640x480 4:3 Súper VGA (SVGA) 800x600 4:3 WUXGA 1920x1200 16:10 QXGA 2048x1536 4:3 WQXGA 2560x1600 16:10 QSXGA 2560x2048 5:4 QUXGA 3200x2400 4:3 WQUXGA 3840x2400 8:5 HSXGA 5120x4096 5:4 WHSXGA 6400x4096 15.6:10 HUXGA 6400x4800 4:3 UHDTV 7680x4320 16:9 WHUXGA 7680x4800 8:5 Formatos de Video Conferencia QCIF 176x144 4:3 QSIF 166x120 4:3 SIF 320x240 4:3 CIF 352×288 4:3 4SIF 704x480 ó 640x480 4:3 4CIF 704x576 4:3 16CIF 1408 x 1152 4:3 Formatos de Televisión Digital 480i 640x480 interlaced 4:3
20
480p 640x480 progressive 4:3 EDTV NTSC 704x480 480p/60 4:3 DV NTSC 720x480 4:3 EDTV PAL 704x576 576p/50 4:3 D1/DV PAL 720x576 4:3 720p 1280x720 16:9 1080i 1920x1080 16:9 Formatos de Almacenamiento D-1 460 D-2 450 D-3 450 D-5 N/A Digital Betacam 500 16:9 DVC 500 DVCPRO 500 DVCAM 500 Digital S 500 Betacam SX 500 LaserDisk 560x360 4:3
Tabla 3. Formatos de video digital
Los estándares de compresión pueden comprimir una amplia variedad de formatos
de frame. En la práctica, es común capturar o convertir a un conjunto de ‘formatos
intermedios’ antes de comprimir o transmitir una señal de video. El formato CIF
(Common Intermediate Format) es la base de un popular conjunto de formatos
usados en video conferencia. La elección de la resolución del frame y la rata de
frames depende principalmente de la aplicación y de la capacidad disponible de
almacenamiento o transmisión con que cuenta el codificador y decodificador.
2.3 Codificación de video
La compresión de video o codificación de video es el proceso de compactar una
secuencia de video digital en un número menor de bits. El video digital sin
21
comprimir ocupa una enorme cantidad de memoria y la compresión se hace
necesaria para hacer posible su almacenamiento y transmisión.
La compresión involucra dos sistemas complementarios. Por un lado esta el
compresor o codificador (encoder), el cual convierte los datos originales a una
forma comprimida que puede almacenarse o transmitirse. Del otro lado esta el
decodificador (decoder) que se encarga de convertir la forma comprimida de los
datos a su representación original. Este par de sistemas se conocen normalmente
como CODEC.
La compresión de datos se alcanza removiendo redundancias o componentes que
no son necesarios para la reproducción de los datos. Muchos tipos de datos
contienen redundancia estadística y se pueden comprimir en forma efectiva
utilizando compresión sin perdidas, lo que implica que los datos de salida del
decodificador son una copia perfecta de los originales. Desafortunadamente, la
compresión sin perdidas de un video o imagen solo alcanza niveles de compresión
moderados (3 a 4 veces el tamaño original).
La compresión con perdidas es necesaria para alcanzar un porcentaje de
compresión superior. No obstante, en una compresión con perdidas, los datos que
salen del decodificador no son iguales a los datos originales. Se puede alcanzar
mayor compresión pero a expensas de una perdida de calidad de la imagen. La
compresión con perdidas esta basada en el principio de eliminar redundancia
subjetiva, es decir elementos de la imagen o secuencia de video que pueden ser
removidos sin afectar significativamente la percepción de calidad del observador.
La mayoría de métodos de codificación de video explotan la redundancia temporal
y la redundancia espacial para alcanzar una mayor compresión. La redundancia
temporal consiste en la alta similitud entre frames capturados en forma
consecutiva, mientras que la redundancia espacial consiste en una alta correlación
entre los píxeles más cercanos entre si.
22
Un CODEC de video codifica una secuencia de video en una forma comprimida y la
decodifica para producir una copia o aproximación de la secuencia original. El
CODEC representa la secuencia de video original con un modelo. Idealmente,
dicho modelo debería representar la secuencia usando la menor cantidad de bits
posible y al mismo tiempo mantener la mayor fidelidad. Estos dos objetivos entran
en conflicto puesto que una rata de compresión mayor, produce una imagen de
menor calidad en la secuencia reconstruida en el decodificador.
Un codificador de video esta compuesto principalmente de tres bloques
funcionales: un modelo temporal, un modelo espacial y un codificador de entropía.
La entrada del modelo temporal es una secuencia de video sin comprimir. El
modelo temporal intenta reducir la redundancia temporal explotando la similitud
entre frames de video consecutivos, usualmente construyendo una predicción del
frame de video actual, a partir de uno o más frames pasados o futuros (predicción
por compensación de movimiento). La salida del modelo temporal es un frame
residual (resta del frame actual y su predicción), y un conjunto de parámetros del
modelo (conjunto de vectores de movimiento que describen la manera como se
compenso el movimiento).
El frame residual constituye la entrada del modelo espacial, dicho modelo
aprovecha la similitud entre muestras vecinas para reducir la redundancia espacial.
Esto se logra, aplicado una transformada al frame residual que transforma las
muestras altamente correlacionadas del dominio espacial a un dominio diferente
en el que los coeficientes no están correlacionados. Los coeficientes de la
transformada son cuantizados para remover valores insignificantes, dejando una
pequeña cantidad de coeficientes que proporcionan una representación mas
compacta del frame residual. El conjunto de coeficientes cuantizados conforman la
salida del modelo espacial.
23
Los parámetros del modelo temporal y el modelo espacial son comprimidos por el
codificador de entropía. Este remueve la redundancia estadística en los datos y
produce un flujo de bits o archivo que podría ser transmitido o almacenado. Una
secuencia comprimida esta compuesta por: vectores de movimiento comprimidos,
coeficientes residuales comprimidos e información de cabecera.
El decodificador de video reconstruye un frame de video a partir de la secuencia
comprimida. Los coeficientes y vectores de movimiento son decodificados por un
decodificador de entropía, después del cual el modelo espacial es decodificado
para reconstruir la versión residual del frame. El decodificador usa los vectores de
movimiento junto con uno o mas frames decodificados, para crear una predicción
del frame actual, y el frame en si mismo es reconstruido sumando el frame
residual con dicha predicción.
En la mayoría de estándares de codificación de video, los bloques de una imagen o
sus respectivos residuos son comprimidos usando una transformada basada en
bloques seguida por una etapa de cuantización y una etapa de codificación de
entropía. La posibilidad de mejorar el desempeño de compresión en las últimas
etapas de la codificación es bastante limitada (DCT, cuantización y codificación de
entropía), dado que la operación de la DCT y el libro de código para la codificación
de entropía están especificados por los más importantes estándares de codificación
de video. Sin embargo, hay una importante posibilidad de mejorar el desempeño
en la primera etapa del CODEC de video (compensación y estimación de
movimiento). Una estimación de movimiento eficiente reduce la energía en el
frame residual compensado en movimiento y puede mejorar sustancialmente el
desempeño de la compresión. La estimación de movimiento puede ser bastante
exigente computacionalmente, y por esta razón mejorar el desempeño en
compresión siempre implica un incremento en la complejidad computacional.
24
2.4 Estándares de codificación de video
El creciente interés de incorporar video dentro de los servicios de
telecomunicaciones, ambientes corporativos, la industria del entretenimiento, y el
hogar, ha hecho de la tecnología de video digital una necesidad. El problema
asociado a las imágenes y el video digital es la gran cantidad de recursos en
almacenamiento y ancho de banda que este tipo de información consume. Para
contrarrestar esta situación han sido desarrollados varios estándares de
compresión de video, los cuales eliminan la redundancia espacial y temporal,
permitiendo que la información de video sea transmitida y almacenada de una
manera más compacta y eficiente.
En los últimos años la transmisión de datos se ha volcado hacia el mundo digital ya
que supone una serie de ventajas frente a la transmisión analógica. Al verse la
información reducida a un flujo de bits, se consigue una mayor protección contra
posibles fallos ya que se pueden introducir mecanismos de detección de errores, se
elimina el problema de las interferencias, podemos disminuir el efecto del ruido en
los canales de comunicación, conseguir codificaciones más óptimas y encriptado,
mezclar con otros tipos de información a través de un mismo canal, y poder
manipular los datos con ordenadores para comprimirlos, por ejemplo.
A través de los años dos organismos de estandarización han venido desarrollando
en paralelo estándares y algoritmos de compresión de video:
• La ITU (International Telecommunication Union) a través de los estándares
“H”, los cuales tratan sobre sistemas multimedia y audiovisuales, entre los
cuales destacamos H.261, H.263 y H.264 relacionados con codificación de
video.
25
• La ISO/IEC (International Organization for Standarization / International
Electrotechnical Commission) por otro lado ha desarrollado los estándares
conocidos como “MPEG” puesto que fueron desarrollados por el comité
MPEG (Motion Picture Expert Group), entre estos se destacan MPEG1,
MPEG2 y MPEG4.
2.4.1 Estándares desarrollados por la ITU
H.261
H.261 Fue el primer estándar de compresión y descompresión de video publicado
por la ITU en 1990. Fue diseñado para una rata de bits múltiplo de 64 Kbit/s. Lo
cual coincide con las tasas de datos ofrecidas por los servicios ISDN [1]. Se
pueden usar entre 1 y 30 canales ISDN para la transmisión del video, lo que
implica ratas de bits en el rango de los 64 Kbit/s a los 1920 Kbit/s.
H.261 fue desarrollado en una época en la que el desempeño de hardware y
software era limitado y por consiguiente tiene la ventaja de baja complejidad. Sin
embargo, sus desventajas incluyen bajo desempeño de compresión (con pobre
calidad de video a una rata de bits por debajo de 100kbits/s) y ausencia de
flexibilidad.
Aplicaciones que motivaron el diseño de este tipo de estándar son:
videoconferencia, vigilancia y monitoreo, telemedicina, y otros servicios
audiovisuales. H.261 es ahora el requerimiento mínimo en todos estándares de
compresión de video. Fue reemplazado por el estándar H.263
H.263
En un intento por mejorar la compresión alcanzada con H.261, el grupo de trabajo
de la ITU-T denominado VCEG (Video Coding Experts Group) desarrolló el H.263.
Éste estándar soporta nuevos métodos de codificación básicos al igual que cuatro
26
modos de operación opcionales, los cuales proporcionan mejor calidad de imagen
a bajas ratas de bits con un pequeño incremento en la complejidad. Gracias
principalmente a su calidad de imagen superior, H.263 se convirtió en el estándar
de codificación de video predominante en las comunicaciones, y ha sido adoptado
en diversos estándares de transporte sobre redes tales como: ITU-T H.324 (PSTN),
H.320 (ISDN), H.310 (BISDN), H.323, y 3 GPP. La primera versión fue aprobada en
1995.
Después de la adopción de la primera versión, se propusieron nuevas mejoras, las
cuales trajeron con sigo una segunda versión del estándar conocida como H.263+.
Esta segunda versión proporciona 12 modos de operación negociables y
características adicionales que mejoran la calidad de video e incrementan la
robustez y funcionalidad de sistemas de video específicos. La aprobación de la
versión 2 fue realizado en 1998. La versión 3 de H.263 (H.263++) se introdujo
para agregar características tales como: eficiencia de codificación mejorada para
aplicaciones de poco retraso, resiliencia al error mejorada para comunicaciones de
video inalámbricas, y soporte para fuentes de video entrelazado. La versión 3 del
estándar se completó en 2001. Esta última versión de H.263 se convirtió en un
estándar no muy manejable, debido al gran número de opciones y la necesidad de
seguir soportando las funciones básicas del CODEC.
Entre las mejoras introducidas por H.263 se destacan:
• Ofrece mejor calidad de video a una rata de bits más baja (por debajo de
30kbit/s).
• Utiliza vectores de movimiento de medio píxel lo que implica una mejora en
la eficiencia de la compensación de movimiento.
27
• Soporte para más formatos de video como: CIF, QCIF, SQCIF, 4CIF y 16CIF.
El soporte de formatos 4CIF y 16CIF le permite competir con estándares de
ratas de bits altas como los estándares MPEG.
• Modos opcionales de codificación permitiéndole al diseñador mayor
flexibilidad para tratar con requerimientos en diferentes aplicaciones y
escenarios de transmisión.
• Puede operar sobre una amplia variedad de redes.
La base del modelo de codificación de H.263 fue adoptada para crear el núcleo del
Perfil Simple del MPEG-4 visual.
H.264
La compresión de video alcanzada con H.264 permite a los usuarios de video
conferencias, una calidad de video mejorada a la misma rata de bits, o la misma
calidad pero a una rata aproximadamente la mitad de la rata requerida
anteriormente. Por ejemplo, para un video de alta calidad codificado en H.263 los
usuarios están acostumbrados a una rata de 768 Kbit/s, que es equivalente usando
H.264 a una rata de 384 Kbit/s. Esto se traduce en una mayor eficiencia en el uso
de la infraestructura de comunicaciones existente.
Similar a otros estándares de codificación de video, H.264 define unos perfiles
especificando la sintaxis y unos niveles que especifican parámetros tales como
resolución, rata de frames, rata de bits, etc. Hasta el momento se ha definido tres
perfiles:
• Perfil Referencia (Baseline Profile), diseñado para video progresivo en
aplicaciones tales como: video conferencia, video sobre IP y aplicaciones
móviles.
28
• Perfil Principal (Main Profile), diseñado para un amplio rango de aplicaciones
de Broadcast.
• Perfil Extendido (Extended Profile), diseñado para aplicaciones móviles y de
streaming sobre Internet.
2.4.2 Estándares desarrollados por la ISO/IEC
El MPEG (Moving Picture Experts Group) define la sintaxis de las señales digitales
que corresponden al audio y video, regula el funcionamiento de decodificadores
estándar; sin embargo no define los algoritmos de codificación, lo cual permite una
mejora continuada de los codificadores y su adaptación a las aplicaciones
específicas dentro de la norma. Además de la codificación de audio y vídeo, el
MPEG también define sistemas para multiplexar la información de audio y vídeo en
una única señal digital, describe los métodos para verificar que las señales y los
decodificadores se ajusten a la norma, y publica informes técnicos con ejemplos de
funcionamiento de codificadores y decodificadores.
Los estándares MPEG fueron desarrollados para ser independientes de la red
específica, lo que proporciona un punto de interoperabilidad en entornos de red
heterogéneos.
El MPEG trabaja por fases. Las fases se identifican con números (MPEG-1, MPEG-2,
MPEG-4, MPEG-7, MPEG-21). Estas fases no describen diversas versiones de una
única norma, sino que son normas completamente distintas que se encargan de
aspectos diferentes de la comunicación multimedia. Así, las últimas fases NO
reemplazan a las anteriores sino que las complementan.
MPEG-1
El primer estándar que el MPEG introdujo fue MPEG-1, fue desarrollado para
almacenamiento y distribución de audio y video digital. MPEG-1 es la base para los
29
primeros video-CDs, además de ser un estándar popular para videos en Internet,
transmitidos como archivos de extensión “.mpg”.
MPEG-1 usa una baja rata de bits, similar a la resultante de una cinta de vídeo
VHS. Soporta video progresivo con ratas de bits de 1.5 Mbps.
El estándar define implícitamente el bitstream y los algoritmos de descompresión.
Los algoritmos de compresión se dejan a los fabricantes, permitiendo obtener una
ventaja propietaria con el alcance de un estándar internacional.
MPEG 1 consiste de seis partes:
Systems ISO/IEC 11172-1 Video ISO/IEC 11172-2 Audio ISO/IEC 11172-3 low bit rate audio ISO/IEC 13818-3 conformance testing ISO/IEC 11172-4 simulation software ISO/IEC 11172-5
Tabla 4. Partes MPEG-1
La capa III de MPEG1-audio es el estándar más popular para la compresión de
audio y es popularmente conocido como MP3.
MPEG-2
MPEG-2 extiende las capacidades de MPEG-1 para cubrir un amplio rango de
aplicaciones. Las aplicaciones primarias objetivo durante el proceso de definición
estaban enfocadas principalmente a transmisión Broadcasting de video digital de
alta calidad con ratas de bits de 4 a 9Mbps. Sin embargo, MPEG-2 es útil para
muchas otras aplicaciones, entre ellas HDTV y almacenamiento en DVD, y ahora
soporta ratas de bits que van desde los 1.5Mbps hasta los 60 Mbps.
MPEG-2 extiende las técnicas de compresión de MPEG-1, para cubrir imágenes
mas grandes y de más alta calidad, a expensas de una tasa de comprensión mas
baja y por lo tanto un uso de ancho de banda más alto, además permite que
30
muchos canales de diferentes ratas de bits se multiplexen dentro de un mismo
flujo de datos. Además MPEG-2 terminó convirtiéndose en el estándar de facto en
el mundo de la televisión digital ya que arregla muchos de los problemas
inherentes a MPEG-1, tales como la resolución y escalabilidad.
Al igual que MPEG-1, la norma no define explícitamente el método de codificación,
sino únicamente la sintaxis que controla el bitstream a la salida del codificador, lo
cual deja gran libertad a los diseñadores.
MPEG-2 consta de 11 partes:
Systems ISO/IEC 13818–1 Video ISO/IEC 13818–2 Audio ISO/IEC 13818–3 conformance testing ISO/IEC 13818–4 software simulation ISO/IEC 13818–5 DSM-CC extensions ISO/IEC 13818–6 advanced audio coding ISO/IEC 13818–7 RTI extension ISO/IEC 13818–9 DSM-CC conformance ISO/IEC 13818–10 IPMP ISO/IEC 13818–11
Tabla 5. Partes de MPEG-2
MPEG-4
Los estándares de compresión de video MPEG1 y MPEG2, aunque perfectamente
adecuados para las aplicaciones para los que fueron diseñados, no eran los
suficientemente flexibles para atender los requerimientos de las aplicaciones
multimedia. Por esta razón el MPEG decidió desarrollar el estándar MPEG-4, el cual
proporciona una plataforma común a un amplio rango de aplicaciones multimedia.
Entre las aplicaciones de MPEG-4 podemos contar la TV Digital, Multimedia Móvil,
Producción de TV, Juegos, Streaming de Video, etc.
Para los autores, MPEG-4 da la posibilidad de crear contenido re-usable y flexible,
con mejores capacidades de protección. Para los usuarios, MPEG-4 puede ofrecer
31
más interactividad y, debido a las bajas ratas de bits, la posibilidad de disfrutar su
contenido sobre nuevas redes y productos móviles.
Las características más importantes que cubren el estándar MPEG-4 pueden
agruparse en 3 categorías:
• Eficiencia en Compresión: la eficiencia en compresión ha sido el principio
número 1 para MPEG-1 y MPEG-2, dicha eficiencia ha hecho posible
aplicaciones como la Televisión Digital y el DVD. Con un incremento en la
eficiencia de codificación y con la posibilidad de codificar múltiples data
streams simultáneamente, MPEG-4 supera sus predecesores y se convierte
en una alternativa excepcional para nuevas aplicaciones.
• Interactividad Basada en Contenido: MPEG-4 posibilita aplicaciones basadas
en contenido permitiendo la codificación y representación de objetos
multimedia (audio, video o imágenes fijas, etc.) en lugar de los tradicionales
frames. Un objeto multimedia puede ser natural o sintético y puede
representarse en forma independiente de sus alrededores o fondo. El
estándar también describe como organizar múltiples objetos para crear una
escena. En lugar de enviar los bits de cada cuadro, los objetos multimedia
se envían en forma independiente, y el receptor realiza la composición de la
escena. Esta es una de las más importantes novedades ofrecidas por MPEG-
4.
• Acceso Universal: La robustez en ambientes ruidosos le permite a MPEG-4
codificar contenido que puede ser accedido desde una amplia variedad de
medios, tales como redes móviles, redes inalámbricas y redes cableadas.
Además la escalabilidad temporal y espacial hacen posible administrar los
recursos de ancho de banda, la capacidad computacional y el consumo de
potencia.
32
Es importante anotar que no es necesario que todas las características que
conforman el estándar MPEG-4 tengan que estar disponibles en todas las
implementaciones, al punto que es posible que no existan implementaciones
completas del estándar. Para manejar esta diversidad, el estándar incluye los
conceptos de perfil y nivel, lo que permite definir conjuntos específicos de
capacidades que pueden ser implementados para cumplir con objetivos
particulares.
Actualmente MPEG-4 consiste de 19 partes:
systems ISO/IEC 14496–1 visual ISO/IEC 14496–2 audio ISO/IEC 14496–3 conformance testing ISO/IEC 14496–4 reference software ISO/IEC 14496–5 DMIF ISO/IEC 14496–6 reference software ISO/IEC 14496–7 carriage over IP networks ISO/IEC 14496–8 reference hardware ISO/IEC 14496–9 advanced video ISO/IEC 14496–10 (H.264) scene description ISO/IEC 14496–11 ISO file format ISO/IEC 14496–12 IPMP extensions ISO/IEC 14496–13 MP4 file format ISO/IEC 14496–14 H.264 file format ISO/IEC 14496–15 animation extension ISO/IEC 14496–16 streaming text format ISO/IEC 14496–17 font compression ISO/IEC 14496–18 synthesize texture stream ISO/IEC 14496–19
Tabla 6. Partes de MPEG-4.
33
3. CONCEPTOS DE STREAMING
3.1 Introducción
Se entiende por streaming la capacidad de distribución de contenido multimedia,
con la característica de poder visualizar estos contenidos en el cliente mientras la
información está siendo trasmitida por la red, no es necesario descargar
completamente el contenido multimedia para comenzar su visualización, esta se va
almacenando en un buffer y se va ejecutando al mismo tiempo que se desarrolla la
transmisión.
En general, los sistemas de difusión de medios han trabajado con señales
análogas, las cuales de alguna forma implican la degradación del contenido a
medida que se realizan copias o cada vez que se repiten [1]. Es aquí donde la
invención de la computadora ha permitido la manipulación y conversión de las
señales de manera digital permitiendo el desarrollo de diferentes formatos de
contenido multimedia que son compatibles con las nuevas redes de
comunicaciones como Internet, esto abre las puertas a una cantidad sin limite de
posibles aplicaciones que aprovechen esta infraestructura a nivel mundial, de esta
forma es posible tener acceso a servicios como videoconferencia, video bajo
demanda ó transmisión de eventos en vivo.
La distribución de contenido multimedia sobre Internet utilizando técnicas de
streaming, implica el uso de los protocolos propios de la pila TCP/IP y teniendo en
cuenta la naturaleza del contenido es necesario definir los mas adecuados para su
34
distribución, el conocimiento de los recursos necesarios de la red, el tipo de
distribución (Unicast ó Multicast) y los formatos de codificación de video a utilizar.
3.2 Distribución de video
3.2.1 Bajo demanda
La tecnología de Streaming multimedia permite la visualización del contenido en el
momento que uno desee. Cuando el video esta disponible para la transmisión, este
es almacenado en un servidor de Streaming, en este momento el servidor esta en
la capacidad de manejar conexiones individuales provenientes de maquinas cliente
que hagan la petición de visualización del contenido, en este momento el servidor
comienza la entrega del flujo de bits para ser visualizado en el reproductor del
cliente al otro lado de la conexión, en este punto el usuario tiene la posibilidad de
controlar el flujo debido a que en cualquier momento puede detener su ejecución,
realizar un retroceso, una pausa, pasar a otra escena, etc.
Una de las propiedades del video bajo demanda es que este puede permanecer en
el servidor indefinidamente hasta que alguien desee verlo, no es necesario tener
una programación de emisión establecida, esto también trae implicaciones en el
uso del ancho de banda ya que cada cliente que realice la petición de visualización
del contenido tiene un flujo independiente desde el servidor por lo que el numero
posible de clientes conectados en un mismo instante depende directamente del
ancho de banda disponible en la red.
35
Figura 10. Modelo de distribución Bajo demanda
3.2.2 En vivo
Streaming en vivo se refiere al flujo de contenido multimedia en tiempo real. En
este caso es necesario el uso de un software de producción que permita codificar y
editar el contenido y que tenga la capacidad de transmitirlo a un servidor desde el
cual generar el flujo hacia los clientes.
La diferencia con la distribución bajo demanda es que en este caso el cliente debe
“escuchar” el canal por el cual fluye el contenido, en este caso es común el uso de
grupos Multicast como destino, siendo el cliente el que demuestra la intención de
recibir el flujo.
36
Figura 11. Modelo de distribución en vivo
3.3 Esquemas de distribución
3.3.1 Broadcast
En la terminología de redes de computadoras, Broadcasting se refiere a la
transmisión de paquetes de información que serán recibidas por cualquier
dispositivo que pertenezca a la red, el alcance de esta definición esta limitado a un
dominio de Broadcast.
Generalmente un dominio de Broadcast esa limitado por los routers asociados a
esa red, debido a que estos no envían tramas Broadcast, por esta razón la mayoría
de las redes que soportan Broadcasting están asociadas a redes de área local.
37
Figura 12. Modelo de distribución Broadcast
3.3.2 Unicast
En la terminología de redes de computadoras, se dice que una transmisión es
Unicast cuando el destino de los paquetes de información es uno solo, esto es todo
lo contrario a una transmisión Broadcast, esto implica que cada transmisión
Unicast desde el servidor hacia el cliente requiere un flujo independiente.
Figura 13. Modelo de distribución Unicast
38
3.3.3 Multicast
Cuando la información es distribuida a un grupo determinado de usuarios
simultáneamente, se esta usando el esquema de distribución Multicast.
El servidor envía un solo flujo para todos los miembros del grupo, esto significa
que se usa el mismo ancho de banda para enviar el contenido a uno o a 100
clientes. El flujo enviado esta dirigido a una dirección de grupo, cada cliente debe
estar configurado de forma tal que “escuche” la información enviada a tal grupo.
Para hacer Multicast, sin embargo, todos los Routers en el trayecto entre el
servidor y el grupo Multicast, deben estar deben estar habilitados para distribución
Multicast, debido a esto la distribución Multicast se realiza en redes privadas,
intranets y en general en redes de área local (LAN).
Figura 14. Modelo de distribución Multicast
39
3.4 Protocolos
El funcionamiento de Internet esta basado en la pila de protocolos TCP/IP [1],
llamada así debido a que son estos dos protocolos los mas representativos,
además de estos dos hay alrededor de 100 protocolos diferentes, entre los cuales
se destacan HTTP, SMTP, FTP, TCP, UDP, IP, ICMP, etc.
Cada uno de los anteriores protocolos poseen características muy bien definidas de
funcionamiento, haciendo que unos protocolos sean mas adecuados que otros
para soportar contenido multimedia.
El hecho que posibilitó la implementación de servicios basados en streaming, fue la
adopción del protocolo de Internet UDP (User Datagram Protocol) junto con las
técnicas de codificación y compresión desarrolladas en los últimos años. El
protocolo UDP hace factible el streaming de contenido multimedia permitiendo la
transmisión de datos de una manera mas eficiente que los demás protocolos
comúnmente utilizados en Internet. Algunos otros protocolos mas recientes como
el RTSP (Real Time Streaming Protocol) hacen aun mas eficiente este tipo de
transmisiones.
Los protocolos UDP y RTSP son ideales para la difusión de contenido multimedia
debido a que estos dan una mayor prioridad a la transmisión continua del flujo que
a la incorruptibilidad de la información, al contrario de las transmisiones basadas
en TCP y HTTP. Cuando un paquete UDP se pierde, el servidor mantiene el flujo
continuo de información obteniendo como resultado en el cliente un salto en la
secuencia de reproducción en lugar de detenerse la ejecución hasta obtener el
paquete faltante, con TCP en cambio se trata de reenviar el paquete antes de
enviar cualquier otra información adicional lo cual causa grandes retardos y
40
rupturas en la reproducción del contenido, características indeseables en la
transmisión de audio y video.
Antes de usarse los protocolos UDP y RTSP, la transmisión de datos se hacia
mediante TCP, este protocolo está diseñado para transmisiones confiables,
tratando en minimizar la perdida de información mas que en entregas puntuales.
Debido a que HTTP está basado en TCP, tampoco es apropiado para transmisiones
multimedia en las cuales es necesaria la operación basada en entregas a tiempo.
Debido a lo anterior, HTTP-streaming es llamado pseudo-streaming, ya que
técnicamente es posible hacerlo aunque no pueda soportar el la cantidad de
transmisión de flujos independientes que se alcanza con UDP y RTSP.
3.4.1 ProtocoloTCP
TCP [3] es el Protocolo de Control de Transmisión de Internet, es un protocolo de
comunicación fiable y orientado a la conexión [1], esta ubicado en la capa
intermedia entre el protocolo de Internet (IP) y la aplicación.
Las conexiones TCP se componen de tres etapas:
• Establecimiento de la conexión
• Transferencia de datos
• Finalizar la conexión
Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y, dado
que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP
añade las funciones necesarias para prestar un servicio libre de errores, en orden,
sin perdida de paquetes y sin duplicaciones.
Cuando una aplicación hace uso del protocolo TCP para transportar sus datos, este
le asigna un puerto por el cual establecer la transmisión, esto hace posible que
41
varias aplicaciones puedan estar transfiriendo datos por la red al mismo tiempo,
cada una de las conexiones estaría entonces identificada por la dirección IP de la
maquina mas el numero del puerto por la cual se realiza la transferencia, a esto se
le llama socket.
El protocolo TCP se encarga de asegurar que ningún segmento de la información
se pierda, asignándole un numero de secuencia a cada uno, con este numero de
secuencia es posible determinar al otro lado de la conexión la perdida de paquetes
y de esta forma pedir la retransmisión de los mismos, así mismo es posible
organizar los paquetes entrantes en el orden correspondiente. TCP retorna un
reconocimiento (ACK) del número de bytes recibidos correctamente; la entidad
origen de los datos inicializa una variable llamada timeout, si el reconocimiento no
es recibido cuando la variable llega a cero, el paquete es reenviado. TCP también
revisa que la información en cada paquete no esté dañada, esto lo hace por medio
de una suma de verificación checksum que se incluye en la cabecera del protocolo,
con esto se busca que cada paquete aceptado tenga la información en buen
estado, de no ser así, se pide retransmisión del paquete.
3.4.2 Protocolo UDP
El Protocolo de Datagramas de Usuario UDP [4], es un protocolo de nivel de
transporte que proporciona una interfaz entre la capa de red y la capa de
aplicación. Permite el envío de datagramas a través de la red sin que se haya
establecido antes una conexión, tampoco se requiere de confirmación ya que no se
hace retransmisión de paquetes, por lo tanto UDP no garantiza la entrega de los
mensajes enviados, esto se debe implementar en las capas superiores.
Este protocolo es muy utilizado cuando se necesita transmitir voz o video.
42
3.4.3 Protocolo RTP
Las comunicaciones basadas en RTP (Real Time Protocol) [5] están orientadas a la
transmisión de datos con características de ejecución en tiempo real, como video
y audio interactivo, en estos casos es muy común el uso en conjunto de RTP y
RTSP.
El Tráfico generado por RTP se transporta en el protocolo UDP, esto es debido a
que las aplicaciones que usan RTP por lo general son menos sensibles a la perdida
de paquetes, pero muy sensibles a los retardos, es por eso que se prefiere UDP
sobre TCP.
Los servicios que provee RTP incluyen:
• Identificación del tipo de carga portada
• Numeramiento de secuencia – PDU Numbering
• Sincronización de Tiempo – tiempo de presentación del contenido portado
• Monitoreo de Entrega
El protocolo en si mismo no provee mecanismos para asegurar la entrega a
tiempo, tampoco se garantiza calidad de servicio (QoS), esto se debe establecer
por medio de otro medio.
3.4.4 Protocolo RTSP
El protocolo RTSP (Real Time Streaming Protocol) [6] es usado para transmitir
contenido multimedia en tiempo real y permite hacer un control directo en el
cliente de la reproducción del contenido enviado desde el servidor por medio de
comandos como PLAY y PAUSE.
La mayoría de los servicios basados en RTSP hacen uso del protocolo RTP para la
transmisión del contenido, el cual a su vez hace uso del protocolo UDP.
43
3.4.5 Protocolo SCTP
El protocolo SCTP (Stream Control Transmision Protocol) [7] es un protocolo de
Internet, en un nivel equivalente al UDP y TCP, el cual la funcionalidad en la capa
de transporte a muchas aplicaciones de Internet.
Así como TCP, SCTP provee un servicio de transporte confiable, también es un
mecanismo orientado a sesión, esto quiere decir que mientras la transmisión no
haya sido completada se mantiene la sesión.
Algunas de las características mas importantes de SCTP:
Es un protocolo Unicast, provee un mecanismo de transmisión confiable,
detectando cuando un paquete de información esta corrupto, duplicado o perdido
y retransmitiéndolo en caso de ser necesario, es un protocolo orientado a la
transmisión de mensajes y no de bytes, como TCP, conservando así la estructura
original del paquete.
Provee una funcionalidad multi-streaming, la cual permite que los datos sean
particionados en múltiples stream, que poseen la propiedad de poder ser
entregados en secuencias independientes, por lo tanto una perdida de algún
paquete solo afecta el stream al cual pertenece y no a los otros. En contraste, TCP
asume un solo stream de datos y asegura que ese stream sea entregado en la
secuencia de bytes correcta. Esto es deseable cuando se entrega un archivo en los
cuales una perdida de datos causa un retardo adicional mientras se restablece la
secuencia original.
44
Para determinadas aplicaciones como la telefonía sobre IP la entrega de datos en
la secuencia original puede no ser tan necesaria como la fluidez en el tráfico de los
datos.
3.5 Funcionamiento de un servicio de Streaming
Un esquema general de un servicio de streaming se compone de tres partes, la
generación del contenido, la disposición y administración del contenido en un
servidor y la distribución del contenido, cada una se apoya en la anterior y ofrece
los recursos requeridos por la siguiente.
Una disposición del esquema anterior seria la siguiente:
Figura 15. Implementación de servicio de streaming
45
La información generada por la fuente de contenido multimedia es procesada por
un software de producción, en caso de que la fuente proporcione el contenido de
forma analógica, este debe ser digitalizado antes de la producción, en esta etapa
se realiza la edición y codificación con el fin de adecuar la señal a las condiciones
de la red, la capacidad de reproducción en los clientes, anchos de banda,
capacidad de almacenamiento en el servidor, etc.
Un estimativo del tamaño que ocupara el recurso multimedia en el servidor se
hace de la siguiente forma:
( )
=
bytes
MB
bits
byte
kbit
bit
s
kbitbitsdeRatasDuraciónMBTamaño
576.048.1
1*
8
1*
1
1000*..*)(
Respecto al esquema anterior, es posible tener en un mismo equipo el servidor de
streaming así como el software de codificación en tiempo real, en este caso el
número de clientes asociados al servidor no debe ser grande, esto es debido a la
gran demanda de procesamiento en la que se incurriría, de lo contrario se debe
tener disponibles dos equipos, uno para cada función.
Después de tener el contenido multimedia a disposición para ser transmitido en
vivo ó bajo demanda, se entra en la etapa de distribución, es aquí donde el
concepto de streaming se hace mas importante ya que es en la reproducción del
contenido en donde radica su funcionalidad.
Desde que el servidor responde con el flujo del contenido a la petición del cliente,
se comienza la ejecución del mismo, esto es, en el cliente se dispone un buffer de
recepción del que se lee para comenzar la visualización del contenido sin
necesidad de que la transferencia se haya hecho completamente.
46
Figura 16. Reproducción de contenido almacenado en el buffer de recepción
Esto es posible gracias al desarrollo de protocolos de tiempo real, como es el caso
del protocolo RTP, además de esto, el uso de un buffer para la ejecución del
contenido en el mismo instante en que se recibe, también le brinda cierta
característica de robustez en la conexión ya que si el canal se afecta por alguna
circunstancia la ejecución del contenido permanece hasta que el buffer este
totalmente vacío, dando así un margen de error en el tiempo mientras se
reestablecen las condiciones del canal.
Esta característica es la que le da la versatilidad a los servicios de streaming
permitiendo que dispositivos terminales con limitados recursos de memoria, como
es el caso de la mayoría de dispositivos móviles, puedan reproducir contenido
multimedia sin generar demandas grandes en la capacidad de almacenamiento.
47
4. SERVIDORES DE STREAMING
La elección de un servidor de streaming debe estar enmarcada por una de serie de
criterios técnicos orientados a satisfacer ciertos requerimientos concernientes al
tipo de audiencia que se quiera satisfacer y al tipo de contenido que se vaya a
distribuir.
En nuestro caso estos criterios estarán orientados a un ambiente académico y mas
específicamente a la distribución de contenido multimedia orientada a dispositivos
móviles.
Como se ha mencionado en capítulos precedentes un servidor de streaming tiene
ciertas características que le permiten distribuir el contenido multimedia de la
mejor manera.
En nuestra selección de servidores de video streaming a evaluar tuvimos en cuenta
los siguientes aspectos:
Soporte Unicast
Todos los servidores de streaming tienen soporte Unicast, pero lo que diferencia a
uno de otro es la cantidad de conexiones simultaneas que pueda manejar.
Soporte Multicast
El soporte Multicast es quizás uno de los mas importantes aspectos en la
transmisión de streaming en redes privadas, y mas en redes educativas donde el
48
número de usuarios y la utilización de ancho de banda de la red son tan
prioritarios.
Codificación de video MPEG-4
El estándar MPEG-4 se ha establecido como una de las técnicas mas convenientes
en la generaron de streaming.
Modularidad en la arquitectura
Se busca un servidor con una arquitectura modular en la cual, sea fácil agregar
módulos propios al servidor y brindarle así características extras.
Documentación
Servidores con una documentación que permita conocer a cabalidad el
funcionamiento interno el servidor y la manera como podemos interactuar con
este.
Open source
Servidores con código abierto y una comunidad de desarrolladores amplia seria lo
ideal.
Con base a los ítems mencionados anteriormente encontramos que los servidores
que cumplen con la mayoría de los requerimientos son:
VLS Server, Darwin streaming server y Helix Universal Server .
En este capitulo daremos un bosquejo general de estos tres servidores y
mostraremos sus principales características, hacienda hincapié en las criterios
mencionados anteriormente.
49
4.1 VLS Descripción general
VideoLAN es una solución completa de software para video streaming, desarrollada
por estudiantes del Ecole Centrale Paris, bajo el licenciamiento GNU General Public
License. VideoLAN esta diseñado para servir videos MPEG en redes que soporten
grandes anchos de banda.
VideoLAN incluye:
• VLS (VideoLAN Server), el cual puede servir archivos MPEG-1, MPEG-2 y MPEG-4,
DVDs, canales satelitales, televisión digital y videos en vivo sobre una red ya sea
Unicast o Multicast.
• VLC (initially VideoLAN Client), el cual puede ser usado como servidor para
archivos MPEG-1, MPEG-2 y MPEG-4 files, DVDs y videos en vivo sobre redes
Unicast o Multicast; o ser usado como cliente para recibir, decodificar y mostrar
MPEG streams, en diversos sistemas operativos.
Figura 17. Estructura general de un servicio implementado con VideoLAN
50
4.1.1 Componentes VLS
El Servidor VideoLAN se programa en C++, con un framework completamente
independiente. Esto significa que VLS no usa las Bibliotecas de Clases estándar
tales como iostreams o vectors. El framework interno del VLS es completamente
autosuficiente, y fue diseñado para que nada deba ser escrito fuera de el (excepto
quizás para portar VLS a otros sistemas operativos).
VLS consta de tres partes principales: Framework (localizado en el src/core), las
clases comunes (en el src/Server y src/mpeg) y las clases optativas llamadas los
módulos (en el src/modules). Los Módulos realmente son las clases heredadas de
las clases comunes. Algunas clases que son consideradas como clases comunes en
cualquier momento pueden convertirse en módulos en el futuro.
Figura 18. Módulos componentes de VLS
51
4.1.2 Arquitectura General
La arquitectura general del VLS es mostrada en la siguiente figura:
Figura 19. Arquitectura VLS
En la figura podemos identificar 3 partes principales: el hilo de la fuente (Reader y
MpegConverter), el hilo del cliente (TsStreamer y Output) y la parte de manejo
(Input, Admin y el Manager).
El Manager esta encargado de proveer todo lo necesario y de gestionar los
módulos, cuando el VLS es inicializado o cuando un nuevo streaming comienza.
El hilo de la fuente lee los datos a través del Reader tan rápido como sea posible
para llenar el SyncFifo.
Entonces, el hilo del consumidor recibe los paquetes del SyncFifo y los vierte. El
tiempo de este streaming se maneja por el TsStreamer que les da el módulo de
salida. El m_cFifo delTS_IN_ETHER es la longitud del paquete y se usa para
52
recoger varios Paquetes de TS antes de enviarlos juntos en un paquete UDP (para
el módulo de NetOutput).
Para mejorar la eficacia y evitar demasiadas asignaciones de memoria, una piscina
de Paquete de TS se asigna de una vez: es el TsProvider. Eso significa que al
principio de la cadena, un nuevo TsPacket es llamado por el conversor (TsProvider-
>GetPacket ()), lleno con los bytes del Reader, pasa por el TsStreamer y la salda.
Después de que se comienza a enviar, el TsPacket se resetea en el TsProvider
(TsProvider->ReleasePacket ()).
Figura 20. Gestión de streaming en el VLS
4.1.3 Descripcion de Clases Comunes
C_Vls
Es la clase principal del Servidor de VideoLAN. Su papel es cargar los módulos,
iniciar el Admin y el Manager, y gestionar mensajes entre ellos.
53
C_Admin
Es la clase de administración principal cuyo papel es controlar las distintas
interfaces de administración, y analizar y ocuparse de las órdenes enviadas a estas
interfaces.
C_Telnet
Ésta es la interfaz de administración de telnet, la única soportada por el momento.
C_Manage
El Manager es una de las clases más importantes de VLS. Lanza varias entradas y
canales según el archivo de configuración vls.cfg, este contiene una lista de todos
los programas disponibles y una lista de los programas actualmente transmitidos.
Es esta clase la que interpreta las órdenes enviadas al Admin, y puede decir a las
entradas que empiecen, se detengan, se suspendan o reanude el streaming.
C_Channel
Ésta es la clase padre de todos los módulos de canales (es decir las salidas). Los
canales actualmente implementados son el de red y el de archivo.
C_PgrmDirectory
Es la lista de todos los programas disponible en las varias entradas.
C_Broadcast
Una " transmisión " se define por una combinación del input/program/channel.
Representa un stream que es actualmente transmitido por VLS.
54
C_Input
Ésta es la clase del padre de todos los módulos de la entrada. Una entrada
consigue un stream de MPEG básicamente de un la fuente (gracias a un "Reader")
y lo envía a un conversor. Cada entrada contiene una lista de programas
disponibles que pueden ser proporcionados.
C_MpegReader
MpegReader lee los datos de una fuente (el archivo, DVD,...) y entrega un
continuo MPEG (PS o TS) stream.
C_MpegConverter
Un MpegConverter convierte el stream proporcionado por el Lector en un stream
de MPEG-TS válido.
C_TsStreamer
El Streamer lee los datos de un Conversor y lo envía a un canal a la velocidad
apropiada.
Figura 21. Clases comunes en el VLS
55
4.1.4 Como es el proceso de Broadcasting?
Que ocurre cuando un stream es iniciado?
A continuación se muestra un diagrama simplificado para mostrar lo que ocurre
cuando un comando start es enviado a través de la interfaz telnet:
Figura 22. Diagrama de inicio de stream en el VLS
Como es enviado un paquete TS?
El manejador de paquete (C_SyncFifo) es compartido entre dos hilos: en uno de
ellos el convertidor coloca los paquetes TS en la fifo, y en el otro hilo el Streamer
los sirve a ellos.
Figura 23. Esquema de envio del paquete TS en el VLS
56
4.2 Darwin Streaming Server
4.2.1 Arquitectura del servidor
El Darwin streaming server consiste en un proceso padre que se divide varios
procesos hijos, los cuales constituyen el núcleo del servidor. Si en las salidas del
proceso hijo hay un error, el padre crea un nuevo proceso hijo.
El núcleo del servidor actúa como una interfaz entre clientes de la red que usan
RTP y RTSP para enviar las peticiones y recibir las respuestas, y módulos del
servidor, los cuales procesan las peticiones y envían los paquetes al cliente.
El núcleo del servidor hace su trabajo creando cuatro tipos de hilos:
1. El hilo Principal del propio servidor. El hilo principal chequea para ver si el
servidor necesita reiniciarse, muestra información del estado de loggeo, o imprime
estadísticas.
2. El Idle hilo de Tarea. El Idle hilo de Tarea maneja una cola de tareas que
ocurren periódicamente. Allí hay dos tipos de colas de tarea: tareas de timeout y
tareas de socket.
3. El hilo de Evento. El hilo de Evento escucha por eventos de socket tales como
una petición RTSP recibida o un paquete RTP y los envía a un hilo de Tarea.
4. Uno o más hilos de tarea. Los hilos de tareas reciben peticiones RTSP y RTP
desde el hilo de Evento. Los hilos de tarea envían peticiones al módulo del
servidor apropiado para procesar y enviar los paquetes al cliente. Por defecto, el
núcleo del servidor crea un hilo de Tarea por proceso.
57
Figura 24. Relación Clientes, hilos del núcleo del servidor y modulos del Darwin Streaming Server
Debido a que el servidor es principalmente asíncrono, se necesita un mecanismo
de comunicación para los eventos.
Por ejemplo, cuando un socket es usado para una conexión de RTSP, algunas
cosas han de ser notificadas de manera que los datos pueden ser procesados.
Una Tarea objeto es un mecanismo generalizado para realizar esta comunicación.
Cada objeto de la Tarea tiene dos métodos principales: Signal y Run. Signal es
llamado por el servidor para enviar un evento a una Tarea objeto. Run es llamado
para dar tiempo a la Tarea para procesar el evento. La meta de cada Tarea objeto
es implementar funcionalidad en el servidor usando pequeños slots de tiempo.
58
Run es puramente una función virtual que se llama cuando una Tarea Objeto tiene
eventos para procesar. Dentro de la función Run, la tarea objeto puede llamar
GetEvents para recibir automáticamente las cabeceras de todas los streams y
previas señales de eventos. En la función Run no se re-entra nunca: si una Tarea
Objeto llama GetEvents en su función Run, y es entonces activada antes de que la
función Run este completa, la función Run será llamada de nuevo sólo después de
haber terminado la función. De hecho, la función Run de Tarea será llamada
repetidamente hasta que todos los eventos de la Tarea objeto se hayan atendido
con GetEvents.
Este concepto de núcleo de tareas evento-activadas se integra en casi cada
subsistema del Servidor de streaming.
Por ejemplo, un objeto de la Tarea puede asociarse con un objeto de Socket. Si el
socket consigue un evento de notificación a través del Evento de Cola, la Tarea
objeto correspondiente será activada. En este caso, el cuerpo de la función Run
contendrá el código por procesar de cualquier evento que se halla recibido en ese
socket.
Las tareas objeto hacen posible al Servidor de streaming usar un solo hilo para
ejecutar todas las conexiones con un solo proceso.
4.2.2 Modulos
El Darwin streaming server se vale de módulos para responder a las peticiones y
completar tareas. Hay tres tipos de módulos:
Content-Managing Modules
Los Content-Managing modules manejan peticiones de RTSP y las respuestas
relacionadas a fuentes multimedia, tal, como un archivo o una transmisión. Cada
módulo es responsable de interpretar las peticiones del cliente, leer y analizar sus
59
archivos soportados o fuente de red, y responder con RTSP y RTP. En algunos
casos, como el mp3 streaming módulo, el módulo usa HTTP.
Los Content-Managing modules son QTSSFileModule, QTSSReflectorModule,
QTSSRelayModule, y QTSSMP3StreamingModule.
Server-Support modules
Los Server-Support modules recogen datos del servidor y realizan las funciones de
logging. El Server-Support modules son QTSSErrorLogModule,
QTSSAccessLogModule, QTSSWebStatsModule, QTSSWebDebugModule,
QTSSAdminModule, y QTSSPOSIXFileSystemModule.
Módulos de Control de acceso
Los módulos de control de acceso proporcionan las funciones de autenticación y de
autorización. Los módulos de control de acceso son QTSSAccessModule,
QTSSHomeDirectoryModule, QTSSHttpFileModule, y QTSSSpamDefenseModule.
4.2.3 Protocolos
El Darwin streaming server soporta los siguientes protocolos:
■ RTSP sobre TCP.
■ RTP sobre UDP.
■ RTP sobre Apple’s Reliable UDP.
■ RTSP/RTP en HTTP (tunneled).
■ RTP sobre RTSP (RTP sobre TCP).
60
4.3 Helix Server
Helix DNA Components
La tecnología de Helix proporciona una plataforma completa para los tipos de
datos streaming y los usos constructivos para las aplicaciones de streaming
multimedia. Helix puede generar stream virtualmente para cualquier tipo de datos,
incluyendo audio, video, imágenes, texto, y animación. Desde cualquier fuente de
datos, un sistema de ficheros local, una base de datos, o una difusión en vivo.
Helix Components
La plataforma Helix incluye el servidor universal Helix y el motor del cliente Helix,
que es la base para RealPlayer. La arquitectura Helix le permite desarrollar los
plug-ins que amplían las capacidades del Helix universal Server o de un cliente de
Helix. Los clientes universales del servidor Helix también soportan los protocolos
de streaming abiertos, haciendo posible para ellos interoperar con otro sistemas
datos.
Helix Universal Server
El Helix universal server funciona bajo sistemas operativos 32-bit de UNIX o de
Windows. Soporta Multicast o Unicast, usando TCP/IP o UDP/IP. La arquitectura
abierta de Helix Universal Server proporciona características útiles tales como las
siguientes:
• El archivo de configuración basado en XML le permite controlar las
características básicas del Helix Universal Server y crear sus propias
características modificadas para requisitos particulares.
61
• La autentificación permite modificar el Helix Universal Server para verificar
alguna conexión o el archivo de peticiones cifrado en una lista de
passwords.
Figura 25. Arquitectura del Helix Universal Server
4.3.1 Cliente/Servidor Protocolos soportados
Al comunicarse con RealPlayer, el Helix universal server por defecto utiliza el Real
time protocol (RTSP) como su protocolo de control y RealNetworks RDP como su
protocolo propietario de paquete. Helix también soporta el protocolo estándar RTP
packet protocol, permitiendo a clientes de Helix Universal Server interactuar con
servidores o clientes basados en RTP.
62
4.3.2 Plug-ins
El corazón de Helix es la arquitectura plug-in que permite al Helix Universal Server
servir cualquier tipo de datos. También le permite personalizar las características
del Helix Universal Server. En Windows, Helix plug-ins son archivos DLL’s de 16-
bit o 32-bit. En UNIX y Macintosh, son bibliotecas compartidas. Helix Universal
Server puede construir los tipos siguientes de pluguins-ins:
plug-in formato de archivo
Este plug-in convierte un cierto tipo de dato a paquetes que Helix Universal Server
puede servir. Aunque Helix Universal Server usa el plug-in de formato de archivo
principalmente para streaming, los clientes Helix también los usan para reproducir
archivos locales.
Plug-in Rendering
Este plug-in recibe los paquetes de streaming y los deja listo para que sean
reproducidos en la computadora del cliente.
Broadcast plug-in
Broadcast plug-in convierte una fuente de datos en vivo en un paquete de
streaming. Aunque usted puede construir su propio Broadcast plug-in, Helix incluye
bibliotecas remotas Broadcast que condiciona una aplicación encoder a un
standard Broadcast plug-in del Helix Universal Server. De esta manera, usted
puede transmitir fácilmente audio en vivo o datos de video.
Monitor plug-in
Un monitor plug-in puede recuperar información del sistema desde el registro del
Helix Universal Server. Por ejemplo, esto incluye el número de clientes conectado
63
actualmente y el URL solicitado por cada cliente. Usted también puede definir
nuevas propiedades guardadas en el registro del Helix Universal Server.
4.3.3 Streaming desde el Helix Universal Server
El ejemplo más común del Helix Universal Server es el streaming de archivos
desde el Helix Universal Server a un cliente, cuando el usuario hace clic en un link
de una página del Web.
La ilustración siguiente explica los pasos que ocurren para que esto pueda ocurrir.
Figura 26. Streaming desde el Helix Server hacia el Real Player
1. En una pagina Web, un usuario hace click en un link a un enlace
multimedia. El autor de la página Web ha configurado el link para que
apunte al Helix Universal Server, la comunicación se establece por medio de
la utilidad Ramgen y se comunica a través de HTTP.
2. La utilidad Ramgen del Helix Universal Server genera un archivo Ram con
extension .ram o .rpm. El archivo Ram especifica la localización del clip
multimedia.
64
3. El archivo Ram es pasado de regreso a el navegador Web.
4. El archivo Ram causa que el navegador web abra el reproductor RealPlayer
en este caso.
5. RealPlayer usa el URL en el archivo Ram para establecer la conexión con el
clip multimedia desde el Helix Universal Server.
6. Basado en las URLs de las peticiones de los archivos multimedia, Helix
Universal Server determina cual plug-ins del sistema de archivo se va a
usar. En muchos casos, los archivos están en un disco duro local y el Helix
Universal Server usa sus plug-in de archivo estándar. Si una fila esta en
una fuente de datos tal como una base de datos, Helix Universal Server
puede servir fácilmente archivos almacenados en cualquier tipo de fuente
de datos en cualquier localización.
7. El plug-in de archivo de sistema atiende las peticiones del click multimedia.
8. El plug-in de archivo de sistema crea objetos de archivo que pueden leer los
datos de los archivos.
9. Helix Universal Server determina el plug-in del formato del archivo a usar.
Cada plug-in del formato del archive esta diseñado para crear paquetes de
streaming para un especifico tipo de datos.
10. El plug-in de formato de archive interactúa con los objetos archivos para
conseguir los datos del archive, pasando las cabezas del los streams y los
paquetes streams al Helix Universal Server.
11. Helix Universal Server sirve los paquetes a RealPlayer usando RTSP/RDP.
65
4.3.4 Sirviendo múltiples Streams
Las presentaciones multimedia distribuidas por el Helix Universal Server consisten
típicamente de más de un tipo de datos. Cada tipo de datos puede tener más de
un stream. El formato AVI, por ejemplo, usa diferentes streams para datos de
video y audio.
La siguiente ilustración muestra tres archivos que generan presentaciones
multimedia. Los archivos A y C contienen cada uno datos de video almacenándose
en un cliente Windows. El archivo B contiene datos de audio reproduciéndose en el
sistema de sonido del cliente. El Helix Universal Server abre un plug-in separado
para cada tipo de datos, asegurando que las tres partes permanezcan
sincronizadas con su línea de tiempo durante la reproducción.
Figura 27. Distribución de múltiples streams en el Helix Server
4.3.5 Comunicación mediante HTTP
Los clientes de Helix pueden recibir archivos desde un servidor Web. Según lo
mostrado en la ilustración siguiente, los clientes tienen un plug-in del sistema de
ficheros del HTTP que les permita comunicarse con los servidores Web. Los
clientes también utilizan el plug-in del formato del archivo para el tipo de datos
servido.
66
Figura 28. Tunelamiento de Streaming sobre HTTP
La entrega del HTTP proporciona un método razonable de descargar los clips
cortos de un servidor del Web usando el protocolo HTTP. No es tan robusta como
el streaming del Helix Universal Server, sin embargo, carece de características
avanzadas de reproducción. Cuando el usuario desea colocar en un lugar mas
adelante en la línea de tiempo de la presentación, la reproducción en el cliente se
detiene pero continua procesando los datos de streaming que le llegan a la rata
normal que lo venia haciendo. La reproducción continúa solo hasta cuando se
alcanza la posición de la línea de tiempo que el usuario haba elegido.
4.3.6 Manejo de memoria
El núcleo proporciona el manejo de memoria que, en la mayoría de las
plataformas, suprime el manejo de memoria proporcionado por el sistema
operativo. Llevando a cabo su propio manejo de memoria el núcleo tiene la
habilidad de soportar memoria compartida en un procesado basado en el servidor,
mejorando capacidades de depuración, e incrementando el desempeño de
memoria, además un pre-procesamiento de memoria caché se lleva a cabo para
reducir la disputa de memoria compartida en múltiples procesos.
67
4.3.7 Manejo de Sesión
Las sesiones son administradas en el núcleo central por el objeto Player. Las
sesiones consisten de una fuente, un manejador de flujo de datos, un destino, y
una entidad de protocolo de control. La sesión se maneja en conjunto por un
objeto de Sesión. Cuando este objeto es parte del Player, este objeto se llama
normalmente un Player Session. Las fuentes pueden ser plugins en el caso de
video bajo demanda, o Broadcast plugins en el caso de video en vivo. El
manejador de flujo de datos en general es un componente que ordena los datos
entre la fuente y el destino a una rata específica. Los destinos pueden ser
implementaciones de protocolos de transporte de datos, o paquetes que puede
guardar simplemente paquetes de datos o puede reflejar los datos de alguna otra
manera. El componente de protocolo de control convierte las señales del protocolo
en acciones para una sesión determinada. Por ejemplo, la señal RTSP PLAY es
convertida por el componente de control protocolar a un evento que empieza el
playback de la sesión.
68
Figura 29. Control de sesión en el Helix Server
69
5. PLAN DE PRUEBAS
5.1 Metodología
Para la realización de las medidas se hizo uso de los recursos disponibles en el
laboratorio de Microelectrónica y control de la Universidad de Antioquia, teniendo
en cuenta esto, se monto una plataforma de pruebas consistente en:
Servidor de Streaming
Computadora de escritorio encargada del almacenamiento del contenido
multimedia de la distribución a los clientes del contenido por medio del servicio de
streaming.
La conectividad inalámbrica se realiza por medio del punto de acceso, conectado al
servidor a través de una interfaz ethernet.
Punto de Acceso
Equipo que permite realizar la conexión inalámbrica entre el servidor y los clientes
inalámbricos. Debe cumplir con el estándar que se desea evaluar, en nuestro caso
el IEEE 802.11a/b/g.
Cliente
Equipo portátil bajo prueba, sobre el cual se ejecuta el reproductor de contenido
streaming multimedia, además de las aplicaciones de diagnóstico que se requieren
para determinar las condiciones de funcionamiento en el equipo cliente.
70
Sniffer
Computadora de escritorio, sobre el cual se ejecutan las aplicaciones de evaluación
de desempeño sobre el canal inalámbrico, con el fin de no afectar el
funcionamiento del equipo cliente.
Figura 30. Plataforma de pruebas
El servidor es un DELL DIMENSION 8300, con procesador Intel Pentium IV 24GHz,
512MB RAM, corriendo un Debian sarge, Kernel 2.6.8, sobre el cual se hacen
pruebas con los servidores DARWIN STREAMING SERVER [8], HELIX SERVER [9],
y VLS (VideoLAN Server) [10]. Para el punto de acceso se ha usado un ARIES
5354, con chipset ATHEROS 5004, que trabaja en banda dual WLAN 802.11a/b/g.
Como equipo SNIFFER se emplea un DELL DIMENSION XPSR400, con procesador
Intel Pentium II, 400MHz, 256 MB RAM, ejecutando un Kubuntu 6.06, Kernel
2.6.15, sobre el cual se ejecuta la aplicación KISMET v 3.01, con el cual se
capturan los paquetes comunicados a través del canal inalámbrico en el que se
encuentra la red.
Para el equipo cliente, se hace uso de una computadora portátil DELL INSPIRON
1300, con procesador Intel Celeron, 1.4GHz y 512MB RAM, ejecutando un
71
MANDRIVA 2006, Kernel 2.6. En este cliente se ejecuta el VLC como reproductor
de video streaming y se ejecuta un script desarrollado en el grupo de investigación
que permite iniciar el reproductor automáticamente luego de cinco segundos de
iniciada la toma de datos, entre los que se incluyen el nivel de la batería
(capacidad restante), consumo instantáneo de corriente en la batería, voltaje
instantáneo de alimentación en la batería, y algunos parámetros de operación de
la comunicación inalámbrica tales como el nivel de señal, nivel de ruido y la calidad
del enlace.
Figura 31. Plataforma de pruebas en el laboratorio de Microelectrónica y control.
El contenido multimedia con el que se desarrollaron las pruebas fue editado
anteriormente, el estándar de codificación, el tamaño del frame y demás
características relativas a la edición. Luego de tener el contenido preparado, se
almacena en el servidor, estableciendo así, un servicio de video bajo demanda.
72
El contenido almacenado en el servidor es un video de 10 minutos de duración
codificado en mp4 a distintas ratas, 112Kbps, 256Kbps y 512Kbps, con un tamaño
de frame de 320x240.
Se pretende caracterizar las aplicaciones de video streaming sobre redes
inalámbricas, considerando el impacto del servidor streaming así como de los
niveles de compresión en el comportamiento de éstas. Para ello, se reprodujo en el
VLC Player cada uno de estos videos con cada uno de los servidores mencionados
para evaluar los resultados. Así mismo, se midió el consumo de energía sobre el
equipo cuando no se reproduce nada, con el radio encendido y con el radio
apagado.
La descripción del desarrollo de las pruebas es como sigue:
Una vez encendidos todos los equipos, se configura la red inalámbrica (con
direcciones de red apropiadas), se asegura que la batería este a plena carga, se
terminan los procesos adicionales en los equipos y se desconectan los periféricos
no esenciales del equipo cliente.
Para continuar se desconecta el cargador, se inician las aplicaciones en los equipos
y se inicia la toma de datos por medio del Script. Paralelamente se hace la captura
de paquetes del tráfico entre el servidor y el cliente por medio del sniffer. Una vez
iniciada la reproducción, se asegura que ésta se realiza sin inconvenientes. Al
finalizar cada medición, se recarga completamente la batería y se inicia la
siguiente.
Funcionamiento del script
El script desarrollado, hace uso del ACPI (Advanced Configuration & Power
Interface), el cual permite obtener los datos de administración de energía usados
por el sistema operativo directamente desde el sistema de archivos, en la ruta
/proc/acpi/battery.
73
El script recibe como argumentos la duración del video en segundos y la ruta URL
del recurso, la ejecución del script consiste en realizar lecturas del cada segundo
de las variables mencionadas anteriormente y almacenarlas en un archivo de texto
durante la reproducción del video, los datos arrojados se procesan posteriormente
con un programa desarrollado en C, el cual extrae cada tipo de dato
independientemente para luego ser graficados.
5.2 Resultados
Utilizando la plataforma y los recursos mencionados anteriormente se establecieron
las medidas a realizar que nos dieran la oportunidad de hacer las comparaciones
entre los servidores.
Cada una de las medidas esta representada en una función del tiempo con el fin
de realizar las comparaciones de una manera visual y mas intuitiva, en todas la
pruebas se utilizo el mismo
5.2.1 Diferentes ratas de compresión para cada servidor
Estas graficas corresponden al consumo de corriente del cliente para los stream de
112Kbit, 256Kbit y 512Kbit servidos por cada uno de los servidores evaluados.
74
Figura 32. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el VLS
Figura 33. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el Darwin Streaming Server
75
Figura 34. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el Helix Server
En las graficas anteriores se observa la diferencia en el consumo de corriente en el
cliente debido a diferentes ratas de compresión en el stream.
5.2.2 Diferentes servidores para cada rata de compresión
Las graficas siguientes muestran el consumo de corriente del cliente para cada uno
de los servidores debido a una rata de compresión específica.
76
Figura 35. Consumo de corriente [mA] en el cliente debido al stream de 112Kbit en cada uno de los servidores
Figura 36. Consumo de corriente [mA] en el cliente debido al stream de 256Kbit en cada uno de los servidores
77
Figura 37. Consumo de corriente [mA] en el cliente debido al stream de 512Kbit en cada uno de los servidores
En las graficas anteriores es posible visualizar la diferencia en el consumo de
corriente en el cliente generado por el stream a una rata de compresión fija,
enviado por cada uno de los servidores.
5.2.3 Comparación de consumo de corriente con el radio a pagado y un
stream determinado para cada servidor
En las graficas siguientes se compara el consumo de corriente en el cliente debido
a un stream determinado y el consumo de corriente del equipo portátil con el radio
apagado.
78
Figura 38. Comparación de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 112Kbit
Figura 39. Comparación de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 112Kbit
79
Figura 40. Comparación de consumos de corriente [mA] Radio OFF Vs VLS con stream de 112Kbit
Figura 41. Comparación de consumos de corriente [mA] Radio OFF Vs VLS con stream de 256Kbit
80
Figura 42. Comparación de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 256Kbit
Figura 43. Comparación de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 256Kbit
81
Figura 44. Comparación de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 512Kbit
Figura 45. Comparación de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 512Kbit
82
Figura 45. Comparación de consumos de corriente [mA] Radio OFF Vs VLS con stream de 512Kbit
5.2.4 Graficas de tráfico de red
Figura 46. Tráfico de datos con stream de 112Kbits servidos por el VLS
83
Figura 47. Tráfico de datos con stream de 256Kbits servidos por el VLS
Figura 48. Tráfico de datos con stream de 512Kbits servidos por el VLS
84
Figura 49. Tráfico de datos con stream de 112Kbits servidos por el Darwin Streaming Server
Figura 50. Tráfico de datos con stream de 256Kbits servidos por el Darwin Streaming Server
85
Figura 51. Tráfico de datos con stream de 512Kbits servidos por el Darwin Streaming Server
Figura 52. Tráfico de datos con stream de 112Kbits servidos por el Helix Server
86
Figura 53. Tráfico de datos con stream de 256Kbits servidos por el Helix server
Figura 54. Tráfico de datos con stream de 512Kbits servidos por el Helix Server
87
CONCLUSIONES
A lo largo de todo este trabajo se discutieron las principales características que
debe tener un servidor de streaming, hemos analizado el consumo de corriente
generado en el cliente debido al stream enviado por cada servidor y el flujo de
datos de alguno de ellos. Ahora resta poner todos los conceptos en común para
dar una visión clara que ayude a determinar cual de ellos es apropiado en la
generación de streaming de video para dispositivos móviles.
En primer lugar nos concentramos en comparar las características de arquitectura
de cada servidor y las diferencias de una con respecto a la otra, los diferentes
protocolos que cada servidor emplea, los formatos que maneja, etc. Para después
determinar cual de ellos presenta mejores prestaciones.
En segundo lugar hicimos un análisis mas enfocado al objetivo del trabajo como tal
y mostraremos el comportamiento en potencia y el flujo de datos que cada
servidor genera sobre el dispositivo móvil.
La arquitectura de los tres servidores analizados está diseñada bajo un esquema
modular, lo que permite adicionar nuevas características y modificar algunas ya
preexistentes sin tener que modificar el núcleo central del servidor, lo cual es una
gran ventaja.
La programación del Darwin streaming Server y la del Helix Server están basadas
en el lenguaje C++ que a excepción del VideoLAN Server utilizan las bibliotecas
88
estándar de este lenguaje. El VideLAN server por su parte tiene un framework, en
el cual crea un entorno propio de desarrollo para éste, utilizando librerías propias
desarrolladas para este fin.
En la parte de protocolos todos ellos utilizan los protocolos estándar para
generación de streaming, con excepción del Darwin y del Helix que utilizan algunos
protocolos propietarios, sin dejar de interoperar con sistemas basados en
protocolos estándar.
En la parte de soporte, documentación y código abierto se debe hacer hincapié en
lo siguiente. Todos los servidores analizados tienen muy buen soporte en
documentación, quizás el Helix tenga una documentación mucho mas estructurada
y un soporte mas completo puesto que dispone de una versión comercial de
servidor, pero en cuanto a código abierto el Darwin y el VideoLAN Server se
caracterizan por tener una comunidad de desarrollo muy grande debido a que son
open source e implementan muchas características de la cual carece la versión
libre del Helix DNA Server.
Entre esta características podemos mencionar como la más importante la
incapacidad que tiene la versión libre del Helix Server para servir videos en
formato MPEG4, ya que esta característica es propia de la versión comercial. La
versión libre del Helix Server es muy limitada respecto a la versión del Darwin
streaming server.
En cuanto a la gestión del servidor, el VideoLAN Server es quizás el más limitado
de todos, además es limitado en cuanto al numero de flujos diferentes que se
pueden establecer en un instante de tiempo. Esto es debido a que el VideoLAN
Server está pensado para trabajar en ambientes LAN y orientado a transmisiones
Multicast. En parte esto se debe a la incapacidad de obtener una realimentación
89
por parte del receptor en el control del stream que se presenta en las
transmisiones basadas en el protocolo UDP.
Tabla 7. Características de los servidores de streaming en evaluación
En las Figuras 32, 33 y 34 se observa una gran similitud entre el Darwin streaming
server y el Helix Server. Ambos servidores tiene valores muy similares en cuanto al
consumo de potencia en el cliente se refiere y muestran poca variación de
consumo entre los diferentes tipos de streaming servidos. Contrario al VideoLAN
Server que marca una clara diferencia en consumo a medida que la rata de
compresión de datos varía (como se indica en la tabla). El que no se presente este
tipo de comportamiento en el Helix Server y en el Darwin tiene que ver con el tipo
de encapsulamiento usado y los protocolos de control y gestión empleados. En el
siguiente cuadro se resume los diferentes consumos de corriente generados por
cada servidor.
Servidor Modularidad MPEG4 Unicast Multicast
soporte y codigo
abierto
VLC * * * *
Darwin Streaming Server * * * * *
Helix Dna Server * *(version comercial) * *
*(limitado repecto a
la comercial)
90
Servidor
Power streaming
112k(mA)
Power streaming
256k(mA)
Power streaming
512k(mA)
VLC 1350 1385 1400
Darwin Streaming Server 1375 1365 1360
Helix Dna Server 1377 1363 1361
Tabla 8. Consumos de corriente [mA] promedio a diferentes ratas de compresión
Los valores de corriente mostrados en la tabla corresponden a valores promedio.
Algo muy importante que cabe resaltar es la prioridad que se tiene en cuanto a las
necesidades en el cliente, al momento de implementar un servicio de streaming.
De las graficas 35, 36 y 37, es posible deducir que en el caso en que los
requerimientos de calidad de video en el cliente no sean más exigentes que los
obtenidos con un stream de 112Kbps, es más viable, desde el punto de vista del
consumo de potencia, el uso del VideoLAN Server, debido a que presenta la mejor
respuesta en cuanto a esta variable que los otros dos servidores. Si el caso del
requerimiento en el cliente fuera de una calidad superior, es evidente que la
solución a implementar debería tener en cuenta alguno de los otros dos servidores,
los cuales presentan un comportamiento más uniforme en el consumo de potencia
en el cliente respecto al VideoLAN Server.
El flujo de datos entre los diferentes servidores mostró diferencias significativas.
El hecho de que en ninguna de las Figuras 46, 47 y 48 aparezca Tráfico RTP es
debido a que VLC envía todos sus datos sobre UDP y de ahí el hecho de que solo
este diseñado para redes LAN donde este tipo de encapsulamiento es muy eficaz.
91
También podemos notar que el tráfico en cada una de las pruebas es mucho
mayor del esperado, respecto a la rata de compresión y esto quizás sea la razón
por la cual este servidor genera un consumo de potencia mucho mayor en el
dispositivo móvil.
En las graficas 49, 50 y 51 correspondientes al Darwin streaming Server se
observaron dos tipos de tráfico principales, Tráfico RTP y Tráfico TCP. Eso nos da
una idea del tipo de gestión que el servidor esta estableciendo. La ausencia de
tráfico UDP es debido a que el Darwin streaming Server encapsula este tipo de
Tráfico sobre RTP. En lo concerniente al tráfico de red como tal, notamos algunos
cambios bruscos originados por el tipo de implementación de MPEG4 que utiliza
Darwin streaming Server.
Observando las Figuras 52, 53 y 54 pertenecientes al Helix Server se nota que es
el que presenta tráfico con variaciones mas suaves, llevándonos a pensar en que
la arquitectura interna y el plug-in de MPEG4 usado por este servidor están
debidamente sincronizados en la línea de tiempo y hacen una implementación
bastante óptima del estándar. Igual que el Darwin streaming Server, Helix usa RTP
como protocolo de streaming.
ANEXO 1. ACPI
ACPI significa Advanced Configuration and Power Interface. La función de ACPI es
permitir al sistema operativo configurar y controlar cada componente de hardware
por separado. De este modo, ACPI sustituye tanto a Plug and Play como a APM.
Asimismo, ACPI proporciona diversos datos sobre la batería, interfaz de red,
temperatura y ventilador e informa de acontecimientos en el sistema como “Cerrar
la cubierta” o “Baterías poco cargadas”.
La BIOS dispone de tablas donde se recoge información sobre cada componente y
sobre los métodos para acceder al hardware. El sistema operativo utiliza esta
información, por ejemplo, para asignar Interrupciones o para activar y desactivar
componentes de hardware. No obstante, debido a que el sistema operativo sigue
las instrucciones almacenadas en la BIOS, aquí también se está supeditado a la
implementación de la BIOS. Los mensajes producidos durante el arranque se
almacenan en /var/log/boot.msg. Allí, ACPI informa de qué tablas ha encontrado y
evaluado con éxito.
ACPI en la práctica
Cuando el kernel reconoce una BIOS ACPI durante el arranque, ACPI es activado
automáticamente (y APM desactivado). El parámetro de arranque acpi=on podría
ser necesario, como máximo, en máquinas antiguas. No obstante, el ordenador
tiene que soportar ACPI 2.0 o superior. Para comprobar si ACPI está activado,
consulte los mensajes de arranque del kernel en /var/log/boot.msg.
A continuación es necesario cargar una serie de módulos, de lo que se ocupa el
script de inicio del daemon ACPI. Si alguno de estos módulos causa problemas,
puede impedirse su carga o descarga en /etc/sysconfig/powersave/common. En el
registro del sistema (/var/log/messages) se encuentran los mensajes del módulo y
puede observarse qué componentes han sido detectados.
93
En /proc/acpi aparecen ahora varios archivos que informan sobre el estado del
sistema o permiten modificar algunos de estos estados. No todas las funciones se
soportan completamente ya que algunas se encuentran todavía en desarrollo y el
soporte de otras depende en gran medida de la implementación del fabricante.
Para lograr una mejor comprensión de ACPI a continuación se describen los
archivos más importantes:
/proc/acpi/info
Información general sobre ACPI
/proc/acpi/alarm
Aquí puede definirse cuándo el sistema despierta de un estado de sueño. El
soporte actual de esta función es insuficiente.
/proc/acpi/sleep
Proporciona información sobre los posibles estados de sueño.
/proc/acpi/event
Aquí se registran los eventos del sistema. Estos son procesados por el
daemon Powersave (powersaved). Un ejemplo de evento es pulsar el
interruptor principal o cerrar la cubierta del portátil.
/proc/acpi/dsdt y /proc/acpi/fadt
Aquí se almacenan las tablas ACPI DSDT (Differentiated System Description
Table) y FADT (Fixed ACPI Description Table).
/proc/acpi/ac_adapter/AC/state
¿Está conectado el adaptador de red?
/proc/acpi/battery/BAT*/{alarm,info,state}
Contienen abundante información sobre el estado de la batería. Para
comprobar el nivel de carga es necesario comparar last full capacity de info con
94
remaining capacity de state. En alarm se puede introducir qué nivel de carga
provocará un evento en la batería.
/proc/acpi/button
Este directorio contiene información sobre diversos interruptores.
/proc/acpi/fan/FAN/state
Muestra si el ventilador está funcionando en ese momento. También puede
encenderse o apagarse manualmente escribiendo en el archivo 0
(=encender) ó 3 (=apagar). No obstante, hay que tener en cuenta que
tanto el código ACPI del kernel como el hardware (o la BIOS) sobrescriben
estos valores cuando la temperatura es demasiado elevada.
/proc/acpi/processor/CPU*/info
Información sobre las posibilidades de ahorro de energía del procesador.
/proc/acpi/processor/CPU*/power
Información sobre el estado actual del procesador. Un asterisco en C2
significa inactividad y es el estado más frecuente, como puede apreciarse en
el número usage.
/proc/acpi/processor/CPU*/throttling
Aquí se puede configurar la suspensión del reloj de la CPU. Normalmente es
posible reducirlo en ocho fases. Esta opción es independiente del control de
frecuencia de la CPU.
/proc/acpi/processor/CPU*/limit
Si un daemon se encarga de regular automáticamente el rendimiento
(obsoleto) y el throttling, aquí se pueden definir los límites que no se deben
sobrepasar en ningún caso. Existen algunos límites que fija el sistema y
otros que fija el usuario.
95
/proc/acpi/thermal_zone/
Aquí se encuentra un subdirectorio para cada zona térmica. Una zona
térmica es una sección con características térmicas semejantes, cuyo
número y nombre de fabricante de hardware puede ser seleccionado.
Muchas de las posibilidades ofrecidas por ACPI se implementan rara vez. En
su lugar, la BIOS se ocupa normalmente de controlar la temperatura sin que
el sistema operativo intervenga, ya que aquí se trata nada menos que de la
duración del hardware. Por lo tanto, las descripciones siguientes son en
parte puramente teóricas.
/proc/acpi/thermal_zone/*/temperature
La temperatura actual de la zona térmica.
/proc/acpi/thermal_zone/*/state
El estado indica si todo está en orden (ok) o si (ACPI) refrigera de forma
activa o pasiva. En los casos donde el control del ventilador no depende de
ACPI, el estado es siempre ok.
/proc/acpi/thermal_zone/*/cooling_mode
Aquí se puede seleccionar el método de refrigeración preferido controlado
por ACPI: pasivo (menor rendimiento pero mayor ahorro) o activo (siempre
máximo rendimiento pero con el ruido del ventilador a toda potencia).
/proc/acpi/thermal_zone/*/trip_points
Aquí se puede definir la temperatura a partir de la cual se emprende alguna
acción. Esta acción puede abarcar desde la refrigeración activa o pasiva
hasta apagar el ordenador (critical), pasando por suspend (hot). Las acciones
posibles se encuentran definidas en DSDT en función del dispositivo. Los trip
points definidos en la especificación ACPI son: critical, hot, passive, active1 y
96
active2. Aunque no siempre estén implementados todos, han de introducirse
en este orden cuando se escriba en el archivo trip_points.
/proc/acpi/thermal_zone/*/polling_frequency
Si el valor de temperature no se actualiza automáticamente cuando se
modifica la temperatura, se puede cambiar aquí al modo polling. El
comando echo X > /proc/acpi/thermal_zone/*/polling_frequency hace que cada X
segundos se pregunte la temperatura. El modo polling se desconecta con
X=0.
Los datos, opciones de configuración y eventos mencionados en las líneas
superiores no tienen que editarse manualmente. Para ello cuenta con el daemon
Powersave (powersaved) y con diversos programas como powersave, kpowersave
y wmpowersave.
ANEXO 2. PORTAL DE GESTION DE CONTENIDO
Uno de los aspectos más importantes después de tener un servidor de video
instalado y corriendo, es la etapa de gestión del contenido del servidor. Como
gestión de contenido nos referíamos a la capacidad que se le da al usuario del
servidor para incluir contenido multimedia dentro de este. Fue con este fin
que se diseño un portal de administración de contenido multimedia para el
servidor.
El portal cuanta con las siguientes características:
Sistema de búsqueda rápida
Con esta herramienta un usuario puede acceder al portal y realizar una búsqueda
rápida por titulo de archivos multimedia dentro del servidor.
98
Figura 55. Búsqueda rápida
Sistema de Búsqueda por descripción de campo
La búsqueda por medio de esta herramienta es mucho más personalizada, y se
puede hacer teniendo en cuenta los siguientes campos:
99
Figura 56. Búsqueda por descripción de campo
Titulo
El titulo del archivo, donde se puede especificar por que letra comienza el nombre
del archivo, en el caso de no tener conocimiento del nombre completo de este.
Descripción
En este campo se esboza de manera sucinta el tema que le concierne al archivo
multimedia como puede ser el caso de especificar un área del conocimiento en
específico.
Palabras claves
100
Es una búsqueda que se utiliza cuando no se tiene información ni muy detallada ni
muy somera de lo que se quiere buscar, se utiliza cuando se quiere obtener
resultados de algún nombre en especial como puede ser el caso de alguien que
desee buscar algo relacionado con el mar, entonces esta campote búsqueda seria
lo ideal.
Gente
Especifica el tipo de personas a las cuales esta dirigido el archivo multimedia, por
ejemplo, se puede colocar a estudiantes, o a candidatos para doctorados, o a
ingenieros electrónicos, etc.
Dificultad
Es una valoración que se le hace al contenido del archivo de acuerdo al grado de
complejidad que este posea.
Edad mínima y Edad máxima
En estos campos se puede especificar el rango de edades para el cuales están
orientados la información.
La Búsqueda por campos, basta con uno solo de ellos si así se desea y le mostrara
información concerniente a este. En caso de elegir varios campos la búsqueda se
vuelve más selectiva y detallada.
101
Búsqueda por fólder
El usuario por medio de esta herramienta puede ir a todos los fólderes de
contenido multimedia del servidor y realizar una búsqueda por su propia cuenta, es
algo así como un explorador.
Búsqueda alfabética
El usuario tiene la opción de buscar por orden alfabético el archivo que el desee.
Figura 57. Búsqueda alfabética
Grabación de contenido
En este punto el usuario coloca nuevo contenido dentro del servidor, no de una
manera directa sino indirecta. Lo anterior significa que solo coloca el titulo del
102
contenido, la descripción, el público al que va dirigido y la edad de la audiencia. El
usuario especifica también la dirección URL del archivo.
Figura 58. Grabación de contenido
El portal fue escrito utilizando php, mysql y perl. Con php se realizo todo lo
concerniente a la administración de contenido del servidor y de la base de
datos y con perl a la generación de contenido dinámico del servidor como es el
embebido de contenido multimedia dentro de la página Web para reproducir los
archivos multimedia.
BIBLIOGRAFIA
[1] Andrew S. Tanenbaum , Redes de computadoras 4ª edición, 1997.
ISBN: 9702601622. 4ª edición (2003).
[2] ANSI/IEEE Std 802.11, Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifcations, 1999 Edition (R2003)
[3] IETF, RFC 793 TRANSMISSION CONTROL PROTOCOL, Septiembre 1981, http://www.ietf.org/rfc/rfc793.txt
[4] IETF, RFC 768 User Datagram Protocol, 28 August 1980, http://www.ietf.org/rfc/rfc768.txt
[5] IETF, RFC 1889 Transport Protocol for Real-Time Applications, 1996,
http://www.ietf.org/rfc/rfc1889.txt
[6] IETF, RFC 2326 Real Time Streaming Protocol, Abril 1998,
http://www.ietf.org/rfc/rfc2326.txt
[7] IETF, RFC 2960 Stream Control Transmision Protocol, Octubre 2000,
http://www.ietf.org/rfc/rfc2960.txt
[8] Darwin Streaming Server,
http://developer.apple.com/opensource/server/streaming/index.html
[9] Helix Server,
http://www.realnetworks.com/products/media_delivery.html
[10] VideoLAN Streaming Server,
http://www.videolan.org/