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


servidores ............................................................................................................................... 76


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


.............................................................................................................................................. 79


stream de 256Kbit ................................................................................................................... 80


256Kbit ................................................................................................................................... 80


512Kbit ................................................................................................................................... 81


stream de 512Kbit ................................................................................................................... 81


.............................................................................................................................................. 82

Figura 46. Tráfico de datos con stream de 112Kbits servidos por el VLS...................................... 82



Figura 49. Tráfico de datos con stream de 112Kbits servidos por el Darwin Streaming Server....... 84



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

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


77


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



80



81



82


5.2.4 Graficas de tráfico de red

Figura 46. Tráfico de datos con stream de 112Kbits servidos por el VLS

83



84

Figura 49. Tráfico de datos con stream de 112Kbits servidos por el Darwin Streaming Server


85


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,


[7] IETF, RFC 2960 Stream Control Transmision Protocol, Octubre 2000,


[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/

Evaluacion de Servidores de Streaming

Documents

Transcript of Evaluacion de Servidores de Streaming