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 ttulo de Ingeniero Electrnico

Asesor Ph.D Jos Edinson Aedo

UNIVERSIDAD DE ANTIOQUIA FACULTAD DE INGENIERA DEPARATAMENTO DE INGENIERA ELECTRNICA MEDLLN 2006

NOTA DE ACEPTACIN

La Universidad de Antioquia, y en nombre el Departamento de Ingeniera Electrnica, decide aprobar el siguiente proyecto de grado como requisito para optar el ttulo de Ingeniero Electrnico.

________________________

________________________

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 bastin 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 ningn 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 INTRODUCCIN .................................................................................................... 1 OBJETIVOS ............................................................................................................ 4 1. CARACTERISTICAS DE LAS COMUNICACIONES INALMBRICAS ............... 5 1.1 Ondas de Radio............................................................................................. 5 1.2 Frecuencias y canales ................................................................................... 8 1.3 Fenmenos que afectan las transmisiones de radiofrecuencia ..................... 9 1.3.1 Absorcin ................................................................................................ 9 1.3.2 Reflexin ............................................................................................... 10 1.3.3 Interferencia .......................................................................................... 11 1.4 Estndares de Comunicaciones inalmbricas en redes WLAN ................... 12 1.5 Esquemas de modulacin 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 desempeo 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 Codificacin de video................................................................................... 20 2.4 Estndares de codificacin de video ........................................................... 24 2.4.1 Estndares desarrollados por la ITU ..................................................... 25 2.4.2 Estndares desarrollados por la ISO/IEC.............................................. 28 3. CONCEPTOS DE STREAMING ....................................................................... 33 3.1 Introduccin ................................................................................................. 33 3.2 Distribucin de video.................................................................................... 34 3.2.1 Bajo demanda ....................................................................................... 34 3.2.2 En vivo .................................................................................................. 35

3.3 Esquemas de distribucin............................................................................ 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 Descripcin 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 mltiples Streams.................................................................. 65 4.3.5 Comunicacin mediante HTTP ............................................................. 65 4.3.6 Manejo de memoria............................................................................... 66 4.3.7 Manejo de Sesin.................................................................................. 67

5. PLAN DE PRUEBAS ......................................................................................... 69 5.1 Metodologa ................................................................................................. 69 5.2 Resultados................................................................................................... 73 5.2.1 Diferentes ratas de compresin para cada servidor .............................. 73 5.2.2 Diferentes servidores para cada rata de compresin ............................ 75 5.2.3 Comparacin de consumo de corriente con el radio a pagado y un stream determinado para cada servidor......................................................... 77 5.2.4 Graficas de trfico 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 electromagntico ........................................................................................... 7 Figura 3. Canales y frecuencias centrales en el estndar 802.11b ................................................. 8 Figura 4. Cobertura por celdas evitando superposicin de canales ................................................ 8 Figura 5. ngulos de incidencia y reflexin ................................................................................ 10 Figura 6. Fenmeno de reflexin en antenas parablicas............................................................ 11 Figura 7. Interferencia constructiva y destructiva....................................................................... 11 Figura 8. Transicin entre Celdas.............................................................................................. 16 Figura 9. Proceso de captura de video ...................................................................................... 18 Figura 10. Modelo de distribucin Bajo demanda ....................................................................... 35 Figura 11. Modelo de distribucin en vivo.................................................................................. 36 Figura 12. Modelo de distribucin Broadcast.............................................................................. 37 Figura 13. Modelo de distribucin Unicast ................................................................................. 37 Figura 14. Modelo de distribucin Multicast ............................................................................... 38 Figura 15. Implementacin de servicio de streaming.................................................................. 44 Figura 16. Reproduccin de contenido almacenado en el buffer de recepcin .............................. 46 Figura 17. Estructura general de un servicio implementado con VideoLAN................................... 49 Figura 18. Mdulos componentes de VLS .................................................................................. 50 Figura 19. Arquitectura VLS...................................................................................................... 51 Figura 20. Gestin 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. Relacin Clientes, hilos del ncleo 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. Distribucin de mltiples streams en el Helix Server.................................................. 65 Figura 28. Tunelamiento de Streaming sobre HTTP ................................................................... 66 Figura 29. Control de sesin en el Helix Server .......................................................................... 68 Figura 30. Plataforma de pruebas ............................................................................................. 70

Figura 31. Plataforma de pruebas en el laboratorio de Microelectrnica y control......................... 71 Figura 32. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el VLS . 74 Figura 33. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el Darwin Streaming Server..................................................................................................................... 74 Figura 34. Consumo de corriente [mA] en el cliente con diferentes stream servidos desde el Helix Server..................................................................................................................................... 75 Figura 35. Consumo de corriente [mA] en el cliente debido al stream de 112Kbit en cada uno de los servidores ............................................................................................................................... 76 Figura 36. Consumo de corriente [mA] en el cliente debido al stream de 256Kbit en cada uno de los servidores ............................................................................................................................... 76 Figura 37. Consumo de corriente [mA] en el cliente debido al stream de 512Kbit en cada uno de los servidores ............................................................................................................................... 77 Figura 38. Comparacin de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 112Kbit ................................................................................................................... 78 Figura 39. Comparacin de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 112Kbit ................................................................................................................................... 78 Figura 40. Comparacin de consumos de corriente [mA] Radio OFF Vs VLS con stream de 112Kbit .............................................................................................................................................. 79 Figura 41. Comparacin de consumos de corriente [mA] Radio OFF Vs VLS con stream de 256Kbit .............................................................................................................................................. 79 Figura 42. Comparacin de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 256Kbit ................................................................................................................... 80 Figura 43. Comparacin de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 256Kbit ................................................................................................................................... 80 Figura 44. Comparacin de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 512Kbit ................................................................................................................................... 81 Figura 45. Comparacin de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 512Kbit ................................................................................................................... 81 Figura 45. Comparacin de consumos de corriente [mA] Radio OFF Vs VLS con stream de 512Kbit .............................................................................................................................................. 82 Figura 46. Trfico de datos con stream de 112Kbits servidos por el VLS...................................... 82 Figura 47. Trfico de datos con stream de 256Kbits servidos por el VLS...................................... 83 Figura 48. Trfico de datos con stream de 512Kbits servidos por el VLS...................................... 83

Figura 49. Trfico de datos con stream de 112Kbits servidos por el Darwin Streaming Server....... 84 Figura 50. Trfico de datos con stream de 256Kbits servidos por el Darwin Streaming Server....... 84 Figura 51. Trfico de datos con stream de 512Kbits servidos por el Darwin Streaming Server....... 85 Figura 52. Trfico de datos con stream de 112Kbits servidos por el Helix Server.......................... 85 Figura 53. Trfico de datos con stream de 256Kbits servidos por el Helix server .......................... 86 Figura 54. Trfico de datos con stream de 512Kbits servidos por el Helix Server.......................... 86 Figura 55. Bsqueda rpida...................................................................................................... 98 Figura 56. Bsqueda por descripcin de campo ......................................................................... 99 Figura 57. Bsqueda alfabtica................................................................................................101 Figura 58. Grabacin de contenido...........................................................................................102

LISTA DE TABLAS

Tabla 1. Caractersticas de la familia de estndares inalmbricos 802.11 (Wi-Fi) .......................... 13 Tabla 2. Caractersticas del estndar inalmbrico 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. Caractersticas de los servidores de streaming en evaluacin......................................... 89 Tabla 8. Consumos de corriente [mA] promedio a diferentes ratas de compresin....................... 90

INTRODUCCIN
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 ms sofisticadas tecnologas 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 tecnologas imprimen un cambio radical en la concepcin de las posibilidades de los servicios que hasta ahora se haban ofrecido. El auge cada vez mayor de los dispositivos mviles han hecho de las comunicaciones un escenario que aos atrs era casi impensado.

En la actualidad no basta solo con poder comunicarnos de la manera tradicional, sino que la aparicin de nuevos y revolucionarios servicios han creado un entorno donde la interactividad y la comunicacin 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 mviles juegan un papel ms 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 utopa para pasar a convertirse en una realidad que cambi para siempre nuestras vidas.

No obstante estas ventajas existen inconvenientes y la movilidad trae implcita retos que aun se estn afrontando como la limitada capacidad de almacenamiento, procesamiento, consumo eficiente de energa y otros que continuarn surgiendo a medida que se avance en la prestacin de diferentes tipos de servicios en dispositivos mviles, tales como el desarrollo de protocolos de transporte que sean sensibles a los cambios continuos en los niveles de seal inherentes a los sistemas

mviles, estas limitaciones imponen lineamientos claros en pro de suplir tales carencias o ayudar a sobrellevarlas mas fcilmente.

Es as que han surgido muchas propuestas, no solo en lo que tiene que ver en la parte de hardware, tambin 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 energa, la implementaron de sistemas de hardware dinmicamente reconfigurable y la utilizacin de tcnicas de streaming para la optimizacin en el uso de los sistemas de almacenamiento, son soluciones que estn orientadas a dotar al dispositivo mvil de caractersticas que le permitan estar a la vanguardia de los esquemas de comunicaciones actuales; en los cuales la interactividad y la difusin de contenido multimedia ha adquirido una importancia cada vez mayor y se ha convertido en algo indispensable en la concepcin de un dispositivo mvil.

De este entorno tan exigente surge el concepto de streaming de video en tiempo real, como un servicio que toma cada da mas fuerza y que posibilita la difusin de contenido multimedia en dispositivos mviles, que seria casi que imposible de otra manera.

El concepto de streaming nace de la necesidad de difundir contenido multimedia a travs del Internet sin la necesidad de descargar todo el tamao 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 estn solicitando.

Aunque el surgimiento de los servidores de streaming ha solucionado en gran parte el problema de difusin de contenido multimedia en Internet, esta solucin fue orientada en un principio a equipos de escritorio, y no a dispositivos mviles 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 mviles. Primero haciendo una evaluacin de los servidores de streaming mas conocidos, en cuanto al desempeo que stos indirectamente le proporcionen al dispositivo y por ltimo haciendo una evaluacin de cules criterios cobran mayor importancia en el esquema de un servidor de streaming de contenido multimedia orientado a dispositivos mviles.

OBJETIVOS
Objetivo general:
Evaluar diferentes tipos de servidores de streaming con el fin de sugerir las caractersticas mas adecuadas para ofrecer un servicio orientado a clientes en dispositivos mviles.

Objetivos especficos:
Establecer criterios de evaluacin para los diferentes servidores de

streaming.
Definir un plan de pruebas. Montaje y puesta a punto de los servidores seleccionados para la evaluacin. Implementacin de un portal para el acceso de los clientes al material multimedia por medio de la red. Obtencin de los resultados mediante el desarrollo del plan de pruebas.

1. CARACTERISTICAS DE LAS COMUNICACIONES INALMBRICAS

Las comunicaciones inalmbricas hacen uso de las ondas de radio para transmitir la informacin, hablando en trminos de los modelos de interconexin de sistemas abiertos como el modelo OSI [1] o el TCP/IP [1], nos estamos refiriendo al nivel mas bajo del modelo, el medio fsico y el de acceso al medio (MAC) por lo tanto desde el punto de vista de las aplicaciones no existe ninguna diferencia con una transmisin 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 seal que proporciona el cable, no sucede.

1.1 Ondas de Radio

Una onda es la vibracin peridica en el tiempo de un medio o material. Las ondas de radio son por lo tanto vibraciones del campo electromagntico que estn definidas por caractersticas tales como su longitud de onda, frecuencia y velocidad, una relacin matemtica de lo anterior est dada por:

Velocidad = Frecuencia * Longitud de Onda

Adems de las propiedades anteriores, las ondas de radio poseen otra caracterstica, la amplitud, siendo sta la distancia desde el centro de la onda hasta el punto mximo.

Figura 1. Longitud de onda, Amplitud y Frecuencia de una onda de 2 ciclos por segundo.

Las ondas electromagnticas abarcan un amplio rango de frecuencias, es denominado espectro electromagntico, est compuesto por diferentes tipos de radiacin, Rayos-X, Ultravioleta, Luz visible, infrarrojo y otras ms. El espectro comprendido entre 3 Hz a 300 GHz, es llamado Radio frecuencias debido a que es la porcin del espectro en el que las ondas pueden ser transmitidas aplicando corriente alterna a una antena.

Figura 2. Espectro electromagntico

Es muy popular el uso de frecuencias pertenecientes a la banda ISM [1], para la transmisin de datos mediante ondas de radio, existen estndares 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 mayora del resto del espectro que se encuentran altamente controlados y el cual se usa para otro tipo de comunicaciones como radio y televisin u otras comunicaciones de voz y datos. Un concepto que se maneja en relacin con el uso de un rango de frecuencias especfico 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 conexin de 1 Mbps es posible tener un flujo continuo de datos de 1 Mb cada segundo.

1.2 Frecuencias y canales

Haciendo nfasis en la banda ISM podemos ejemplificar el uso del espectro en el estndar IEEE 802.11b, ste hace uso de las frecuencias cercanas a los 2,4 GHz y se hace una divisin 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 estndar 802.11b

Como se visualiza en la figura anterior, los canales 1, 6 y 11 no se superponen, por lo que son comnmente usados en los sistemas inalmbricos adyacentes o en sistemas de cobertura por celdas como se ilustra a continuacin.

Figura 4. Cobertura por celdas evitando superposicin de canales

Hay un hecho claro con respecto a la frecuencia de la onda sobre la cual viaja la informacin, ya que afecta directamente la distancia de propagacin. Asumiendo niveles iguales de potencia en la transmisin, se tiene que las ondas de ms 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 obstculos, esto es, si una onda de 4 metros de que viaja en el agua se encuentra con un obstculo en la superficie de unos cuantos milmetros sta no se detiene, pero si se topa con un barco la onda sufrir atenuacin. La distancia de propagacin de la onda depende tambin del tamao de los obstculos que sta se encuentra en su camino. La sondas electromagnticas no estn exentas de este tipo de fenmenos, por ejemplo, la radio FM comercial (88 MHz 108 MHz) puede atravesar edificaciones y obstculos de este tipo fcilmente pero los telfonos GSM (900 MHz),Na aunque esto tambin se debe a la diferencia en la potencia de los transmisores de FM y GSM. La gran ventaja que poseen las ondas radiadas a ms altas frecuencias es que mientras ms rpida sea la oscilacin, mayor cantidad de informacin puede transportar.

1.3

Fenmenos

que

afectan

las

transmisiones

de

radiofrecuencia
1.3.1 Absorcin
Las ondas se debilitan o atenan cuando atraviesan algn material, la cantidad de potencia perdida depende del material y de la frecuencia de la onda. Para

determinar el impacto de determinado material sobre la onda se hace uso del coeficiente de absorcin. Los dos materiales ms absorbentes para las microondas son el agua y el metal, en la prctica se consideran estos dos elementos como absorbentes perfectos, por lo tanto los cambios climticos que generen niebla, vapor lluvia inciden de manera negativa en el radio enlace. Para los rboles y la madera la absorcin depende de la cantidad de agua que contengan, para nosotros los humanos y los animales tambin aplica debido a que para efectos de la onda de radio, somos bsicamente agua.

1.3.2 Reflexin
Dependiendo del ngulo de incidencia de la onda en una superficie determinada se puede presentar el fenmeno de Reflexin, el ngulo de incidencia de la onda determina el ngulo de reflexin, ambos son iguales respecto al plano de incidencia.

Figura 5. ngulos de incidencia y reflexin

Debido a este fenmeno se presenta el efecto multitrayectoria (multipath), debido a la reflexin de la onda cuando choca con los elementos que se encuentran en su

10

camino de propagacin, esto causa que las seales 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 planeacin y ejecucin de un enlace de radio siendo muchas veces imposible calcular la posible reflexin. En el diseo de antenas se hace uso de este fenmeno para focalizar las ondas incidentes.

Figura 6. Fenmeno de reflexin en antenas parablicas

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 relacin de fase fija e igual frecuencia.

Figura 7. Interferencia constructiva y destructiva

11

En la implementacin de redes inalmbricas, 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 caractersticas descritas anteriormente se eliminan o se crean nuevas ondas de las cuales es imposible leer la informacin que portan. Para sobrellevar los problemas causados por la interferencia se hace uso de las tcnicas de modulacin y el uso adecuado de los canales.

1.4 Estndares de Comunicaciones inalmbricas en redes WLAN

En el contexto de las redes LAN [1] el estndar manejado es el IEEE 802.11 [2] comnmente llamado wi-fi (wreless fidelity), fue desarrollado por el grupo de trabajo 11 del comit de estndares de redes LAN/MAN. El termino 802.11 es usado generalmente para denotar el estndar inicial al que tambin se le llama 802.11 Legacy. La familia 802.11 incluye 6 tcnicas de modulacin que usan el mismo protocolo, las tcnicas mas populares son las definidas por las enmiendas a, b y g, siendo el 802.11b el primer estndar ampliamente aceptado, seguido de 802.11a y luego 802.11g.

A continuacin se muestra una tabla comparativa de las caractersticas mas destacadas de los estndares mencionados.

12

Protocolo

Lanzamiento

Frecuencia de operacin

Rata de Transmisin (Tpica)

Rata de Transmisin (Maxima) 2 Mbit/s 54 Mbit/s 11 Mbit/s 54 Mbit/s

Alcance en interiores

Legacy 802.11a 802.11b 802.11g

1997 1999 1999 2003

2.4 GHz 5 GHz 2.4 GHz 2.4 GHz

1 Mbit/s 25 Mbit/s 6.5 Mbit/s 25 Mbit/s

* ~30 mts ~30 mts ~30 mts

* No hay un dato estimado.

Tabla 1. Caractersticas de la familia de estndares inalmbricos 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 transmisin que se busca obtener esta estimada en 540 Mbit/s, la cual es 10 veces ms que la obtenida por los estndares 802.11a y 802.11b. Para alcanzar esta rata de transferencia se har uso de la tecnologa MIMO (multiple-input multiple-output), la cual permite el uso de mltiples antenas de recepcin y transmisin con lo que se puede implementar mtodos de diversidad espacial que permitan un incremento en el rango de rata de transferencia. El objetivo es tener listo el estndar para el ao 2008.

Protocolo

Lanzamiento

Frecuencia de operacin

Rata de Transmisin (Tpica) 200 Mbit/s

Rata de Transmisin (Maxima) 540 Mbit/s

Alcance en interiors

802.11n

Abril 2008

2.4 5 GHz

~50 mts

Tabla 2. Caractersticas del estndar inalmbrico 802.11n

1.5 Esquemas de modulacin usados en 802.11 a/b/g

13

1.5.1 DSSS Espectro Ensanchado por Secuencia Directa

En esta tcnica de modulacin se genera un patrn de bits redundante (seal de chip) para cada uno de los bits que componen la seal. Cuanto mayor sea esta seal, mayor ser la resistencia de la seal a las interferencias. El estndar IEEE 802.11 recomienda un tamao de 11 bits, pero el optimo es de 100. En recepcin es necesario realizar el proceso inverso para obtener la informacin original. La secuencia de bits utilizada para modular los bits se conoce como codigo de dispersin o pseudo ruido. Es una secuencia rpida diseada para que aparezca aproximadamente la misma cantidad de 1 que de 0. Un ejemplo de esta secuencia en codificacin 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 podrn recomponer la seal original. Adems, al sustituir cada bit de datos a transmitir, por una secuencia de 11 bits equivalente, aunque parte de la seal de transmisin se vea afectada por interferencias, el receptor an puede reconstruir fcilmente la informacin a partir de la seal recibida. Una vez aplicada la seal de chip, el estndar IEEE 802.11 ha definido dos tipos de modulacin para la tcnica de espectro ensanchado por secuencia directa (DSSS), la modulacin DBPSK (Differential Binary Phase Shift Keying) y la modulacin DQPSK (Differential Quadrature Phase Shift Keying), que proporcionan una velocidad de transferencia de 1 y 2 Mbps respectivamente. La revisin IEEE 802.11b aumenta esta velocidad hasta los 11Mbps, lo que increment notablemente el rendimiento de este tipo de redes.

14

1.5.2 FHSS Espectro Ensanchado por Salto de Frecuencia

La tecnologa de espectro ensanchado por salto en frecuencia (FHSS) consiste en transmitir una parte de la informacin 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 emisin y se sigue transmitiendo a otra frecuencia. De esta manera cada tramo de informacin se va transmitiendo en una frecuencia distinta durante un intervalo muy corto de tiempo. El orden en los saltos en frecuencia se determina segn una secuencia pseudo

aleatoria almacenada en unas tablas, y que tanto el emisor y el receptor deben

conocer. Si se mantiene la sincronizacin en los saltos de frecuencias se consigue que, aunque en le tiempo se cambie de canal fsico, a nivel lgico se mantiene un solo canal por el que se realiza la comunicacin. Esta tcnica tambin utiliza la zona de los 2.4GHz, la cual organiza en 79 canales con un ancho de banda de 1MHz cada uno. El nmero de saltos por segundo es regulado por cada pas, as, por ejemplo, Estados Unidos fija una tasa mnima de saltas de 2.5 por segundo. El estndar IEEE 802.11 define la modulacin aplicable en este caso. Se utiliza la modulacin en frecuencia FSK (Frequency Shift Keying).

1.6 Efectos de la movilidad en el desempeo de un servicio de streaming

El desempeo de un servicio de streaming se puede ver notablemente afectado en presencia de un cliente mvil en la red, esto es debido a la inconsistencia en la

15

calidad del canal, intermitencia en la conexin, bloqueos de la seal en el ambiente que introducen ruidos y ecos, y otros tipos de efectos generados por los fenmenos que lleva implcita una transmisin por medio de ondas de radio, como la reflexin, la difraccin, la absorcin y la interferencia, todos estos efectos generan menor estabilidad en la conexin, disminucin 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 disminucin en el rendimiento debido a retransmisiones no se presenta, sta situacin se presenta cuando se usa el protocolo TCP donde la latencia se hace notable. Es claro entonces que los servicios de streaming sobre dispositivos mviles enfrentan retos como la necesidad de mantener la calidad del servicio y mantener una operacin adecuada en ambientes heterogneos. Esto ultimo se visualiza de manera mas explicita cuando un dispositivo mvil sale del alcance de una celda de radiacin perteneciente a un Access Point e ingresa a otra, el la terminologa de las comunicaciones celulares esto se denomina handoff handover, esto sucede cuando el dispositivo mvil detecta un nivel de seal mas fuerte de una de dos estaciones base Access point y empieza a recibir el flujo de datos proveniente de esta.

Figura 8. Transicin entre Celdas

16

17

2. CONCEPTOS DE VIDEO DIGITAL

2.1 Captura de video
El video se captura usando una cmara o sistema de cmaras. La mayora de los sistemas digitales actuales utilizan video en 2-D, por lo cual utilizan solo una cmara. La cmara enfoca una proyeccin 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 generacin de una representacin digital de una escena de video pueden considerarse dos etapas:

Adquisicin: convertir una proyeccin de la escena en una seal elctrica

por medio de un CCD por ejemplo.

Digitalizacin:

Muestrear

la

proyeccin

espacial

temporalmente

convirtiendo cada muestra en un nmero o conjunto de nmeros. La digitalizacin puede llevarse a cabo utilizando una tarjeta o dispositivo independiente, sin embargo ya muchas cmaras tienen integrada la etapa de digitalizacin, por lo cual proporcionan una salida digital.

Captura

Procesamiento/ Almacenamiento/ Transmisin

Presentacin

Figura 9. Proceso de captura de video

18

2.2 Formatos de video

Una seal de video tiene una amplia variedad de parmetros resolucin, 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 parmetros de una seal de video para una aplicacin especfica. La tabla 1 lista los principales formatos de video digital con sus respetivas resoluciones.

Formatos Video Digital

Resolucin

Relacin ancho/alto 4:3 4:3 16:10 4:3 16:10 5:4 4:3 8:5 5:4 15.6:10 4:3 16:9 8:5 4:3 4:3 4:3 4:3 4:3 4:3 4:3 4:3

Formatos de Grficos de computador VGA Sper VGA (SVGA) WUXGA QXGA WQXGA QSXGA QUXGA WQUXGA HSXGA WHSXGA HUXGA UHDTV WHUXGA Formatos de Video Conferencia QCIF QSIF SIF CIF 4SIF 4CIF 16CIF Formatos de Televisin Digital 480i 640x480 800x600 1920x1200 2048x1536 2560x1600 2560x2048 3200x2400 3840x2400 5120x4096 6400x4096 6400x4800 7680x4320 7680x4800 176x144 166x120 320x240 352288 704x480 640x480 704x576 1408 x 1152 640x480 interlaced

19

480p EDTV NTSC DV NTSC EDTV PAL D1/DV PAL 720p 1080i Formatos de Almacenamiento D-1 D-2 D-3 D-5 Digital Betacam DVC DVCPRO DVCAM Digital S Betacam SX LaserDisk

640x480 progressive 704x480 480p/60 720x480 704x576 576p/50 720x576 1280x720 1920x1080 460 450 450 N/A 500 500 500 500 500 500 560x360

4:3 4:3 4:3 4:3 4:3 16:9 16:9

16:9

4:3

Tabla 3. Formatos de video digital

Los estndares de compresin pueden comprimir una amplia variedad de formatos de frame. En la prctica, es comn capturar o convertir a un conjunto de formatos intermedios antes de comprimir o transmitir una seal de video. El formato CIF (Common Intermediate Format) es la base de un popular conjunto de formatos usados en video conferencia. La eleccin de la resolucin del frame y la rata de

frames depende principalmente de la aplicacin y de la capacidad disponible de

almacenamiento o transmisin con que cuenta el codificador y decodificador.

2.3 Codificacin de video

La compresin de video o codificacin de video es el proceso de compactar una secuencia de video digital en un nmero menor de bits. El video digital sin

20

comprimir ocupa una enorme cantidad de memoria y la compresin se hace necesaria para hacer posible su almacenamiento y transmisin. La compresin 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 representacin original. Este par de sistemas se conocen normalmente como CODEC. La compresin de datos se alcanza removiendo redundancias o componentes que no son necesarios para la reproduccin de los datos. Muchos tipos de datos contienen redundancia estadstica y se pueden comprimir en forma efectiva utilizando compresin sin perdidas, lo que implica que los datos de salida del decodificador son una copia perfecta de los originales. Desafortunadamente, la compresin sin perdidas de un video o imagen solo alcanza niveles de compresin moderados (3 a 4 veces el tamao original). La compresin con perdidas es necesaria para alcanzar un porcentaje de compresin superior. No obstante, en una compresin con perdidas, los datos que salen del decodificador no son iguales a los datos originales. Se puede alcanzar mayor compresin pero a expensas de una perdida de calidad de la imagen. La compresin 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 percepcin de calidad del observador. La mayora de mtodos de codificacin de video explotan la redundancia temporal y la redundancia espacial para alcanzar una mayor compresin. La redundancia temporal consiste en la alta similitud entre frames capturados en forma consecutiva, mientras que la redundancia espacial consiste en una alta correlacin entre los pxeles ms cercanos entre si.

21

Un CODEC de video codifica una secuencia de video en una forma comprimida y la decodifica para producir una copia o aproximacin de la secuencia original. El CODEC representa la secuencia de video original con un modelo. Idealmente, dicho modelo debera 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 compresin 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 entropa. 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 prediccin del

frame de video actual, a partir de uno o ms frames pasados o futuros (prediccin

por compensacin de movimiento). La salida del modelo temporal es un frame residual (resta del frame actual y su prediccin), y un conjunto de parmetros 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 estn correlacionados. Los coeficientes de la transformada son cuantizados para remover valores insignificantes, dejando una pequea cantidad de coeficientes que proporcionan una representacin mas compacta del frame residual. El conjunto de coeficientes cuantizados conforman la salida del modelo espacial.

22

Los parmetros del modelo temporal y el modelo espacial son comprimidos por el codificador de entropa. Este remueve la redundancia estadstica en los datos y produce un flujo de bits o archivo que podra ser transmitido o almacenado. Una secuencia comprimida esta compuesta por: vectores de movimiento comprimidos, coeficientes residuales comprimidos e informacin 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 entropa, despus del cual el modelo espacial es decodificado para reconstruir la versin residual del frame. El decodificador usa los vectores de movimiento junto con uno o mas frames decodificados, para crear una prediccin del frame actual, y el frame en si mismo es reconstruido sumando el frame residual con dicha prediccin. En la mayora de estndares de codificacin de video, los bloques de una imagen o sus respectivos residuos son comprimidos usando una transformada basada en bloques seguida por una etapa de cuantizacin y una etapa de codificacin de entropa. La posibilidad de mejorar el desempeo de compresin en las ltimas etapas de la codificacin es bastante limitada (DCT, cuantizacin y codificacin de entropa), dado que la operacin de la DCT y el libro de cdigo para la codificacin de entropa estn especificados por los ms importantes estndares de codificacin de video. Sin embargo, hay una importante posibilidad de mejorar el desempeo en la primera etapa del CODEC de video (compensacin y estimacin de movimiento). Una estimacin de movimiento eficiente reduce la energa en el

frame residual compensado en movimiento y puede mejorar sustancialmente el

desempeo de la compresin. La estimacin de movimiento puede ser bastante exigente computacionalmente, y por esta razn mejorar el desempeo en compresin siempre implica un incremento en la complejidad computacional.

23

2.4 Estndares de codificacin de video

El creciente inters de incorporar video dentro de los servicios de

telecomunicaciones, ambientes corporativos, la industria del entretenimiento, y el hogar, ha hecho de la tecnologa de video digital una necesidad. El problema asociado a las imgenes y el video digital es la gran cantidad de recursos en almacenamiento y ancho de banda que este tipo de informacin consume. Para contrarrestar esta situacin han sido desarrollados varios estndares de compresin de video, los cuales eliminan la redundancia espacial y temporal, permitiendo que la informacin de video sea transmitida y almacenada de una manera ms compacta y eficiente. En los ltimos aos la transmisin de datos se ha volcado hacia el mundo digital ya que supone una serie de ventajas frente a la transmisin analgica. Al verse la informacin reducida a un flujo de bits, se consigue una mayor proteccin contra posibles fallos ya que se pueden introducir mecanismos de deteccin de errores, se elimina el problema de las interferencias, podemos disminuir el efecto del ruido en los canales de comunicacin, conseguir codificaciones ms ptimas y encriptado, mezclar con otros tipos de informacin a travs de un mismo canal, y poder manipular los datos con ordenadores para comprimirlos, por ejemplo. A travs de los aos dos organismos de estandarizacin han venido desarrollando en paralelo estndares y algoritmos de compresin de video:

La ITU (International Telecommunication Union) a travs de los estndares H, los cuales tratan sobre sistemas multimedia y audiovisuales, entre los cuales destacamos H.261, H.263 y H.264 relacionados con codificacin de video.

24

La ISO/IEC (International Organization for Standarization / International

Electrotechnical Commission) por otro lado ha desarrollado los estndares

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 Estndares desarrollados por la ITU H.261

H.261 Fue el primer estndar de compresin y descompresin de video publicado por la ITU en 1990. Fue diseado para una rata de bits mltiplo 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 transmisin 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 desempeo de hardware y

software era limitado y por consiguiente tiene la ventaja de baja complejidad. Sin
embargo, sus desventajas incluyen bajo desempeo de compresin (con pobre calidad de video a una rata de bits por debajo de 100kbits/s) y ausencia de flexibilidad. Aplicaciones que motivaron vigilancia y el diseo de este tipo de y estndar otros son:

videoconferencia,

monitoreo,

telemedicina,

servicios

audiovisuales. H.261 es ahora el requerimiento mnimo en todos estndares de compresin de video. Fue reemplazado por el estndar H.263

H.263
En un intento por mejorar la compresin alcanzada con H.261, el grupo de trabajo de la ITU-T denominado VCEG (Video Coding Experts Group) desarroll el H.263. ste estndar soporta nuevos mtodos de codificacin bsicos al igual que cuatro

25

modos de operacin opcionales, los cuales proporcionan mejor calidad de imagen a bajas ratas de bits con un pequeo incremento en la complejidad. Gracias principalmente a su calidad de imagen superior, H.263 se convirti en el estndar de codificacin de video predominante en las comunicaciones, y ha sido adoptado en diversos estndares de transporte sobre redes tales como: ITU-T H.324 (PSTN), H.320 (ISDN), H.310 (BISDN), H.323, y 3 GPP. La primera versin fue aprobada en 1995. Despus de la adopcin de la primera versin, se propusieron nuevas mejoras, las cuales trajeron con sigo una segunda versin del estndar conocida como H.263+. Esta segunda versin proporciona 12 modos de operacin negociables y caractersticas adicionales que mejoran la calidad de video e incrementan la robustez y funcionalidad de sistemas de video especficos. La aprobacin de la versin 2 fue realizado en 1998. La versin 3 de H.263 (H.263++) se introdujo para agregar caractersticas tales como: eficiencia de codificacin mejorada para aplicaciones de poco retraso, resiliencia al error mejorada para comunicaciones de video inalmbricas, y soporte para fuentes de video entrelazado. La versin 3 del estndar se complet en 2001. Esta ltima versin de H.263 se convirti en un estndar no muy manejable, debido al gran nmero de opciones y la necesidad de seguir soportando las funciones bsicas del CODEC. Entre las mejoras introducidas por H.263 se destacan: Ofrece mejor calidad de video a una rata de bits ms baja (por debajo de 30kbit/s). Utiliza vectores de movimiento de medio pxel lo que implica una mejora en la eficiencia de la compensacin de movimiento.

26

Soporte para ms formatos de video como: CIF, QCIF, SQCIF, 4CIF y 16CIF. El soporte de formatos 4CIF y 16CIF le permite competir con estndares de ratas de bits altas como los estndares MPEG.

Modos opcionales de codificacin permitindole al diseador

mayor

flexibilidad para tratar con requerimientos en diferentes aplicaciones y escenarios de transmisin. Puede operar sobre una amplia variedad de redes.

La base del modelo de codificacin de H.263 fue adoptada para crear el ncleo del Perfil Simple del MPEG-4 visual.

H.264
La compresin 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 estn 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 estndares de codificacin de video, H.264 define unos perfiles especificando la sintaxis y unos niveles que especifican parmetros tales como resolucin, rata de frames, rata de bits, etc. Hasta el momento se ha definido tres perfiles: Perfil Referencia (Baseline Profile), diseado para video progresivo en aplicaciones tales como: video conferencia, video sobre IP y aplicaciones mviles.

27

Perfil Principal (Main Profile), diseado para un amplio rango de aplicaciones de Broadcast.

Perfil Extendido (Extended Profile), diseado para aplicaciones mviles y de

streaming sobre Internet.

2.4.2 Estndares desarrollados por la ISO/IEC

El MPEG (Moving Picture Experts Group) define la sintaxis de las seales digitales que corresponden al audio y video, regula el funcionamiento de decodificadores estndar; sin embargo no define los algoritmos de codificacin, lo cual permite una mejora continuada de los codificadores y su adaptacin a las aplicaciones especficas dentro de la norma. Adems de la codificacin de audio y vdeo, el MPEG tambin define sistemas para multiplexar la informacin de audio y vdeo en una nica seal digital, describe los mtodos para verificar que las seales y los decodificadores se ajusten a la norma, y publica informes tcnicos con ejemplos de funcionamiento de codificadores y decodificadores. Los estndares MPEG fueron desarrollados para ser independientes de la red especfica, lo que proporciona un punto de interoperabilidad en entornos de red heterogneos. El MPEG trabaja por fases. Las fases se identifican con nmeros (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 comunicacin multimedia. As, las ltimas fases NO reemplazan a las anteriores sino que las complementan.

MPEG-1
El primer estndar que el MPEG introdujo fue MPEG-1, fue desarrollado para almacenamiento y distribucin de audio y video digital. MPEG-1 es la base para los

28

primeros video-CDs, adems de ser un estndar popular para videos en Internet, transmitidos como archivos de extensin .mpg. MPEG-1 usa una baja rata de bits, similar a la resultante de una cinta de vdeo VHS. Soporta video progresivo con ratas de bits de 1.5 Mbps. El estndar define implcitamente el bitstream y los algoritmos de descompresin. Los algoritmos de compresin se dejan a los fabricantes, permitiendo obtener una ventaja propietaria con el alcance de un estndar internacional. MPEG 1 consiste de seis partes:

Systems Video Audio low bit rate audio conformance testing simulation software

ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC

11172-1 11172-2 11172-3 13818-3 11172-4 11172-5

Tabla 4. Partes MPEG-1

La capa III de MPEG1-audio es el estndar ms popular para la compresin 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 definicin estaban enfocadas principalmente a transmisin 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 tcnicas de compresin de MPEG-1, para cubrir imgenes mas grandes y de ms alta calidad, a expensas de una tasa de comprensin mas baja y por lo tanto un uso de ancho de banda ms alto, adems permite que

29

muchos canales de diferentes ratas de bits se multiplexen dentro de un mismo flujo de datos. Adems MPEG-2 termin convirtindose en el estndar de facto en el mundo de la televisin digital ya que arregla muchos de los problemas inherentes a MPEG-1, tales como la resolucin y escalabilidad. Al igual que MPEG-1, la norma no define explcitamente el mtodo de codificacin, sino nicamente la sintaxis que controla el bitstream a la salida del codificador, lo cual deja gran libertad a los diseadores. MPEG-2 consta de 11 partes:

Systems Video Audio conformance testing software simulation DSM-CC extensions advanced audio coding RTI extension DSM-CC conformance IPMP

ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC

138181 138182 138183 138184 138185 138186 138187 138189 1381810 1381811

Tabla 5. Partes de MPEG-2

MPEG-4
Los estndares de compresin de video MPEG1 y MPEG2, aunque perfectamente adecuados para las aplicaciones para los que fueron diseados, no eran los suficientemente flexibles para atender los requerimientos de las aplicaciones multimedia. Por esta razn el MPEG decidi desarrollar el estndar MPEG-4, el cual proporciona una plataforma comn a un amplio rango de aplicaciones multimedia. Entre las aplicaciones de MPEG-4 podemos contar la TV Digital, Multimedia Mvil, Produccin 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 proteccin. Para los usuarios, MPEG-4 puede ofrecer

30

ms interactividad y, debido a las bajas ratas de bits, la posibilidad de disfrutar su contenido sobre nuevas redes y productos mviles. Las caractersticas ms importantes que cubren el estndar MPEG-4 pueden agruparse en 3 categoras: Eficiencia en Compresin: la eficiencia en compresin ha sido el principio nmero 1 para MPEG-1 y MPEG-2, dicha eficiencia ha hecho posible aplicaciones como la Televisin Digital y el DVD. Con un incremento en la eficiencia de codificacin y con la posibilidad de codificar mltiples data

streams simultneamente, 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 codificacin y representacin de objetos multimedia (audio, video o imgenes fijas, etc.) en lugar de los tradicionales

frames. Un objeto multimedia puede ser natural o sinttico y puede

representarse en forma independiente de sus alrededores o fondo. El estndar tambin describe como organizar mltiples objetos para crear una escena. En lugar de enviar los bits de cada cuadro, los objetos multimedia se envan en forma independiente, y el receptor realiza la composicin de la escena. Esta es una de las ms importantes novedades ofrecidas por MPEG4. 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 mviles, redes inalmbricas y redes cableadas. Adems la escalabilidad temporal y espacial hacen posible administrar los recursos de ancho de banda, la capacidad computacional y el consumo de potencia.

31

Es importante anotar que no es necesario que todas las caractersticas que conforman el estndar MPEG-4 tengan que estar disponibles en todas las implementaciones, al punto que es posible que no existan implementaciones completas del estndar. Para manejar esta diversidad, el estndar incluye los conceptos de perfil y nivel, lo que permite definir conjuntos especficos de capacidades que pueden ser implementados para cumplir con objetivos particulares. Actualmente MPEG-4 consiste de 19 partes:

systems visual audio conformance testing reference software DMIF reference software carriage over IP networks reference hardware advanced video scene description ISO file format IPMP extensions MP4 file format H.264 file format animation extension streaming text format font compression synthesize texture stream

ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC

144961 144962 144963 144964 144965 144966 144967 144968 144969 1449610 (H.264) 1449611 1449612 1449613 1449614 1449615 1449616 1449617 1449618 1449619

Tabla 6. Partes de MPEG-4.

32

3. CONCEPTOS DE STREAMING

3.1 Introduccin
Se entiende por streaming la capacidad de distribucin de contenido multimedia, con la caracterstica de poder visualizar estos contenidos en el cliente mientras la informacin est siendo trasmitida por la red, no es necesario descargar completamente el contenido multimedia para comenzar su visualizacin, esta se va almacenando en un buffer y se va ejecutando al mismo tiempo que se desarrolla la transmisin.

En general, los sistemas de difusin de medios han trabajado con seales anlogas, las cuales de alguna forma implican la degradacin del contenido a medida que se realizan copias o cada vez que se repiten [1]. Es aqu donde la invencin de la computadora ha permitido la manipulacin y conversin de las seales 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 transmisin de eventos en vivo. La distribucin de contenido multimedia sobre Internet utilizando tcnicas 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

33

distribucin, el conocimiento de los recursos necesarios de la red, el tipo de distribucin (Unicast Multicast) y los formatos de codificacin de video a utilizar.

3.2 Distribucin de video

3.2.1 Bajo demanda
La tecnologa de Streaming multimedia permite la visualizacin del contenido en el momento que uno desee. Cuando el video esta disponible para la transmisin, 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 peticin de visualizacin 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 conexin, en este punto el usuario tiene la posibilidad de controlar el flujo debido a que en cualquier momento puede detener su ejecucin, 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 programacin de emisin establecida, esto tambin trae implicaciones en el uso del ancho de banda ya que cada cliente que realice la peticin de visualizacin 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.

34

Figura 10. Modelo de distribucin 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 produccin 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 distribucin bajo demanda es que en este caso el cliente debe escuchar el canal por el cual fluye el contenido, en este caso es comn el uso de grupos Multicast como destino, siendo el cliente el que demuestra la intencin de recibir el flujo.

35

Figura 11. Modelo de distribucin en vivo

3.3 Esquemas de distribucin

3.3.1 Broadcast
En la terminologa de redes de computadoras, Broadcasting se refiere a la transmisin de paquetes de informacin que sern recibidas por cualquier dispositivo que pertenezca a la red, el alcance de esta definicin 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 envan tramas Broadcast, por esta razn la mayora de las redes que soportan Broadcasting estn asociadas a redes de rea local.

36

Figura 12. Modelo de distribucin Broadcast

3.3.2 Unicast
En la terminologa de redes de computadoras, se dice que una transmisin es

Unicast cuando el destino de los paquetes de informacin es uno solo, esto es todo
lo contrario a una transmisin Broadcast, esto implica que cada transmisin

Unicast desde el servidor hacia el cliente requiere un flujo independiente.

Figura 13. Modelo de distribucin Unicast

37

3.3.3 Multicast
Cuando la informacin es distribuida a un grupo determinado de usuarios simultneamente, se esta usando el esquema de distribucin Multicast. El servidor enva 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 direccin de grupo, cada cliente debe estar configurado de forma tal que escuche la informacin 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 distribucin

Multicast, debido a esto la distribucin Multicast se realiza en redes privadas,

intranets y en general en redes de rea local (LAN).

Figura 14. Modelo de distribucin Multicast

38

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, adems 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 caractersticas muy bien definidas de funcionamiento, haciendo que unos protocolos sean mas adecuados que otros para soportar contenido multimedia.

El hecho que posibilit la implementacin de servicios basados en streaming, fue la adopcin del protocolo de Internet UDP (User Datagram Protocol) junto con las tcnicas de codificacin y compresin desarrolladas en los ltimos aos. El protocolo UDP hace factible el streaming de contenido multimedia permitiendo la transmisin de datos de una manera mas eficiente que los dems protocolos comnmente 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 difusin de contenido multimedia debido a que estos dan una mayor prioridad a la transmisin continua del flujo que a la incorruptibilidad de la informacin, al contrario de las transmisiones basadas en TCP y HTTP. Cuando un paquete UDP se pierde, el servidor mantiene el flujo continuo de informacin obteniendo como resultado en el cliente un salto en la secuencia de reproduccin en lugar de detenerse la ejecucin hasta obtener el paquete faltante, con TCP en cambio se trata de reenviar el paquete antes de enviar cualquier otra informacin adicional lo cual causa grandes retardos y

39

rupturas en la reproduccin del contenido, caractersticas indeseables en la transmisin de audio y video.

Antes de usarse los protocolos UDP y RTSP, la transmisin de datos se hacia mediante TCP, este protocolo est diseado para transmisiones confiables, tratando en minimizar la perdida de informacin 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 operacin basada en entregas a tiempo. Debido a lo anterior, HTTP-streaming es llamado pseudo-streaming, ya que

tcnicamente es posible hacerlo aunque no pueda soportar el la cantidad de transmisin de flujos independientes que se alcanza con UDP y RTSP.

3.4.1 ProtocoloTCP
TCP [3] es el Protocolo de Control de Transmisin de Internet, es un protocolo de comunicacin fiable y orientado a la conexin [1], esta ubicado en la capa intermedia entre el protocolo de Internet (IP) y la aplicacin. Las conexiones TCP se componen de tres etapas: Establecimiento de la conexin Transferencia de datos Finalizar la conexin

Habitualmente, las aplicaciones necesitan que la comunicacin sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmacin), TCP aade las funciones necesarias para prestar un servicio libre de errores, en orden, sin perdida de paquetes y sin duplicaciones. Cuando una aplicacin hace uso del protocolo TCP para transportar sus datos, este le asigna un puerto por el cual establecer la transmisin, esto hace posible que

40

varias aplicaciones puedan estar transfiriendo datos por la red al mismo tiempo, cada una de las conexiones estara entonces identificada por la direccin 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 ningn segmento de la informacin se pierda, asignndole un numero de secuencia a cada uno, con este numero de secuencia es posible determinar al otro lado de la conexin la perdida de paquetes y de esta forma pedir la retransmisin de los mismos, as mismo es posible organizar los paquetes entrantes en el orden correspondiente. TCP retorna un reconocimiento (ACK) del nmero 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 tambin revisa que la informacin en cada paquete no est daada, esto lo hace por medio de una suma de verificacin checksum que se incluye en la cabecera del protocolo, con esto se busca que cada paquete aceptado tenga la informacin en buen estado, de no ser as, se pide retransmisin 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 aplicacin. Permite el envo de datagramas a travs de la red sin que se haya establecido antes una conexin, tampoco se requiere de confirmacin ya que no se hace retransmisin 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.

41

3.4.3 Protocolo RTP

Las comunicaciones basadas en RTP (Real Time Protocol) [5] estn orientadas a la transmisin de datos con caractersticas de ejecucin en tiempo real, como video y audio interactivo, en estos casos es muy comn el uso en conjunto de RTP y RTSP. El Trfico 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: Identificacin del tipo de carga portada Numeramiento de secuencia PDU Numbering Sincronizacin de Tiempo tiempo de presentacin 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 reproduccin del contenido enviado desde el servidor por medio de comandos como PLAY y PAUSE. La mayora de los servicios basados en RTSP hacen uso del protocolo RTP para la transmisin del contenido, el cual a su vez hace uso del protocolo UDP.

42

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, tambin es un mecanismo orientado a sesin, esto quiere decir que mientras la transmisin no haya sido completada se mantiene la sesin.

Algunas de las caractersticas mas importantes de SCTP:

Es un protocolo Unicast, provee un mecanismo de transmisin confiable, detectando cuando un paquete de informacin esta corrupto, duplicado o perdido y retransmitindolo en caso de ser necesario, es un protocolo orientado a la transmisin 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 mltiples stream, que poseen la propiedad de poder ser entregados en secuencias independientes, por lo tanto una perdida de algn 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.

43

Para determinadas aplicaciones como la telefona sobre IP la entrega de datos en la secuencia original puede no ser tan necesaria como la fluidez en el trfico 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 generacin del contenido, la disposicin y administracin del contenido en un servidor y la distribucin del contenido, cada una se apoya en la anterior y ofrece los recursos requeridos por la siguiente.

Una disposicin del esquema anterior seria la siguiente:

Figura 15. Implementacin de servicio de streaming

44

La informacin generada por la fuente de contenido multimedia es procesada por un software de produccin, en caso de que la fuente proporcione el contenido de forma analgica, este debe ser digitalizado antes de la produccin, en esta etapa se realiza la edicin y codificacin con el fin de adecuar la seal a las condiciones de la red, la capacidad de reproduccin en los clientes, anchos de banda, capacidad de almacenamiento en el servidor, etc. Un estimativo del tamao que ocupara el recurso multimedia en el servidor se hace de la siguiente forma: 1MB kbit 1000bit 1byte Tamao( MB) = Duracin(s ) * Rata.de.bits s * 1kbit * 8bits * 1.048.576bytes Respecto al esquema anterior, es posible tener en un mismo equipo el servidor de

streaming as como el software de codificacin en tiempo real, en este caso el

nmero de clientes asociados al servidor no debe ser grande, esto es debido a la gran demanda de procesamiento en la que se incurrira, de lo contrario se debe tener disponibles dos equipos, uno para cada funcin.

Despus de tener el contenido multimedia a disposicin para ser transmitido en vivo bajo demanda, se entra en la etapa de distribucin, es aqu donde el concepto de streaming se hace mas importante ya que es en la reproduccin del contenido en donde radica su funcionalidad. Desde que el servidor responde con el flujo del contenido a la peticin del cliente, se comienza la ejecucin del mismo, esto es, en el cliente se dispone un buffer de recepcin del que se lee para comenzar la visualizacin del contenido sin necesidad de que la transferencia se haya hecho completamente.

45

Figura 16. Reproduccin de contenido almacenado en el buffer de recepcin

Esto es posible gracias al desarrollo de protocolos de tiempo real, como es el caso del protocolo RTP, adems de esto, el uso de un buffer para la ejecucin del contenido en el mismo instante en que se recibe, tambin le brinda cierta caracterstica de robustez en la conexin ya que si el canal se afecta por alguna circunstancia la ejecucin del contenido permanece hasta que el buffer este totalmente vaco, dando as un margen de error en el tiempo mientras se reestablecen las condiciones del canal.

Esta caracterstica 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 mayora de dispositivos mviles, puedan reproducir contenido multimedia sin generar demandas grandes en la capacidad de almacenamiento.

46

4. SERVIDORES DE STREAMING
La eleccin de un servidor de streaming debe estar enmarcada por una de serie de criterios tcnicos 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 estarn orientados a un ambiente acadmico y mas especficamente a la distribucin de contenido multimedia orientada a dispositivos mviles.

Como se ha mencionado en captulos precedentes un servidor de streaming tiene ciertas caractersticas que le permiten distribuir el contenido multimedia de la mejor manera.

En nuestra seleccin 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 quizs uno de los mas importantes aspectos en la transmisin de streaming en redes privadas, y mas en redes educativas donde el

47

nmero de usuarios y la utilizacin de ancho de banda de la red son tan prioritarios.

Codificacin de video MPEG-4

El estndar MPEG-4 se ha establecido como una de las tcnicas mas convenientes en la generaron de streaming.

Modularidad en la arquitectura
Se busca un servidor con una arquitectura modular en la cual, sea fcil agregar mdulos propios al servidor y brindarle as caractersticas extras.

Documentacin
Servidores con una documentacin que permita conocer a cabalidad el funcionamiento interno el servidor y la manera como podemos interactuar con este.

Open source
Servidores con cdigo 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 mayora 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 caractersticas, hacienda hincapi en las criterios mencionados anteriormente.

48

4.1 VLS Descripcin general

VideoLAN es una solucin completa de software para video streaming, desarrollada por estudiantes del Ecole Centrale Paris, bajo el licenciamiento GNU General Public

License. VideoLAN esta diseado 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, televisin 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

49

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 estndar tales como iostreams o vectors. El framework interno del VLS es completamente autosuficiente, y fue diseado para que nada deba ser escrito fuera de el (excepto quizs 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 mdulos (en el src/modules). Los Mdulos realmente son las clases heredadas de las clases comunes. Algunas clases que son consideradas como clases comunes en cualquier momento pueden convertirse en mdulos en el futuro.

Figura 18. Mdulos componentes de VLS

50

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 mdulos, cuando el VLS es inicializado o cuando un nuevo streaming comienza.

El hilo de la fuente lee los datos a travs del Reader tan rpido 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 mdulo de salida. El m_cFifo delTS_IN_ETHER es la longitud del paquete y se usa para

51

recoger varios Paquetes de TS antes de enviarlos juntos en un paquete UDP (para el mdulo 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. Despus de que se comienza a enviar, el TsPacket se resetea en el TsProvider (TsProvider->ReleasePacket ()).

Figura 20. Gestin 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 mdulos, iniciar el Admin y el Manager, y gestionar mensajes entre ellos.

52

C_Admin
Es la clase de administracin principal cuyo papel es controlar las distintas interfaces de administracin, y analizar y ocuparse de las rdenes enviadas a estas interfaces.

C_Telnet
sta es la interfaz de administracin de telnet, la nica soportada por el momento.

C_Manage
El Manager es una de las clases ms importantes de VLS. Lanza varias entradas y canales segn el archivo de configuracin 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 mdulos 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 " transmisin " se define por una combinacin del input/program/channel. Representa un stream que es actualmente transmitido por VLS.

53

C_Input
sta es la clase del padre de todos los mdulos de la entrada. Una entrada consigue un stream de MPEG bsicamente de un la fuente (gracias a un "Reader") y lo enva 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 vlido.

C_TsStreamer
El Streamer lee los datos de un Conversor y lo enva a un canal a la velocidad apropiada.

Figura 21. Clases comunes en el VLS

54

4.1.4 Como es el proceso de Broadcasting? Que ocurre cuando un stream es iniciado?

A continuacin se muestra un diagrama simplificado para mostrar lo que ocurre cuando un comando start es enviado a travs 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

55

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 ncleo del servidor. Si en las salidas del proceso hijo hay un error, el padre crea un nuevo proceso hijo.

El ncleo del servidor acta como una interfaz entre clientes de la red que usan RTP y RTSP para enviar las peticiones y recibir las respuestas, y mdulos del servidor, los cuales procesan las peticiones y envan los paquetes al cliente.

El ncleo 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 informacin del estado de loggeo, o imprime estadsticas. 2. El Idle hilo de Tarea. El Idle hilo de Tarea maneja una cola de tareas que ocurren peridicamente. 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 peticin RTSP recibida o un paquete RTP y los enva a un hilo de Tarea. 4. Uno o ms hilos de tarea. Los hilos de tareas reciben peticiones RTSP y RTP desde el hilo de Evento. Los hilos de tarea envan peticiones al mdulo del

servidor apropiado para procesar y enviar los paquetes al cliente. Por defecto, el ncleo del servidor crea un hilo de Tarea por proceso.

56

Figura 24. Relacin Clientes, hilos del ncleo del servidor y modulos del Darwin Streaming Server

Debido a que el servidor es principalmente asncrono, se necesita un mecanismo de comunicacin para los eventos. Por ejemplo, cuando un socket es usado para una conexin 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 comunicacin.

Cada objeto de la Tarea tiene dos mtodos 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 pequeos slots de tiempo.

57

Run es puramente una funcin virtual que se llama cuando una Tarea Objeto tiene
eventos para procesar. Dentro de la funcin Run, la tarea objeto puede llamar

GetEvents para recibir

automticamente las cabeceras de todas los streams y

previas seales de eventos. En la funcin Run no se re-entra nunca: si una Tarea Objeto llama GetEvents en su funcin Run, y es entonces activada antes de que la funcin Run este completa, la funcin Run ser llamada de nuevo slo despus de haber terminado la funcin. De hecho, la funcin Run de Tarea ser llamada repetidamente hasta que todos los eventos de la Tarea objeto se hayan atendido con GetEvents. Este concepto de ncleo 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 notificacin a travs del Evento de Cola, la Tarea

objeto correspondiente ser activada. En este caso, el cuerpo de la funcin Run contendr el cdigo 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 mdulos para responder a las peticiones y completar tareas. Hay tres tipos de mdulos:

Content-Managing Modules
Los Content-Managing modules manejan peticiones de RTSP y las respuestas relacionadas a fuentes multimedia, tal, como un archivo o una transmisin. Cada mdulo es responsable de interpretar las peticiones del cliente, leer y analizar sus

58

archivos soportados o fuente de red, y responder con RTSP y RTP. En algunos casos, como el mp3 streaming mdulo, el mdulo 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, QTSSWebDebugModule,

QTSSAccessLogModule,

QTSSWebStatsModule,

QTSSAdminModule, y QTSSPOSIXFileSystemModule. Mdulos de Control de acceso

Los mdulos de control de acceso proporcionan las funciones de autenticacin y de autorizacin. Los mdulos 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 Apples Reliable UDP. RTSP/RTP en HTTP (tunneled). RTP sobre RTSP (RTP sobre TCP).

59

4.3 Helix Server

Helix DNA Components
La tecnologa 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, imgenes, texto, y animacin. Desde cualquier fuente de datos, un sistema de ficheros local, una base de datos, o una difusin 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 amplan las capacidades del Helix universal Server o de un cliente de Helix. Los clientes universales del servidor Helix tambin 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 caractersticas tiles tales como las siguientes: El archivo de configuracin basado en XML le permite controlar las caractersticas bsicas del Helix Universal Server y crear sus propias

caractersticas modificadas para requisitos particulares.

60

La autentificacin permite modificar el Helix Universal Server para verificar alguna conexin 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 tambin soporta el protocolo estndar RTP

packet protocol, permitiendo a clientes de Helix Universal Server interactuar con

servidores o clientes basados en RTP.

61

4.3.2 Plug-ins
El corazn de Helix es la arquitectura plug-in que permite al Helix Universal Server servir cualquier tipo de datos. Tambin le permite personalizar las caractersticas del Helix Universal Server. En Windows, Helix plug-ins son archivos DLLs de 16bit 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 tambin 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 aplicacin encoder a un

standard Broadcast plug-in del Helix Universal Server. De esta manera, usted
puede transmitir fcilmente audio en vivo o datos de video.

Monitor plug-in
Un monitor plug-in puede recuperar informacin del sistema desde el registro del

Helix Universal Server. Por ejemplo, esto incluye el nmero de clientes conectado

62

actualmente y el URL solicitado por cada cliente. Usted tambin puede definir nuevas propiedades guardadas en el registro del Helix Universal Server.

4.3.3 Streaming desde el Helix Universal Server

El ejemplo ms comn 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 pgina del Web. La ilustracin 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 pgina Web ha configurado el link para que apunte al Helix Universal Server, la comunicacin se establece por medio de la utilidad Ramgen y se comunica a travs de HTTP. 2. La utilidad Ramgen del Helix Universal Server genera un archivo Ram con extension .ram o .rpm. El archivo Ram especifica la localizacin del clip multimedia.

63

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 conexin 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 estn en un disco duro local y el Helix

Universal Server usa sus plug-in de archivo estndar. Si una fila esta en
una fuente de datos tal como una base de datos, Helix Universal Server puede servir fcilmente archivos almacenados en cualquier tipo de fuente de datos en cualquier localizacin. 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 diseado para crear paquetes de

streaming para un especifico tipo de datos.

10. El plug-in de formato de archive interacta 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.

64

4.3.4 Sirviendo mltiples Streams

Las presentaciones multimedia distribuidas por el Helix Universal Server consisten tpicamente de ms de un tipo de datos. Cada tipo de datos puede tener ms de un stream. El formato AVI, por ejemplo, usa diferentes streams para datos de video y audio. La siguiente ilustracin muestra tres archivos que generan presentaciones multimedia. Los archivos A y C contienen cada uno datos de video almacenndose en un cliente Windows. El archivo B contiene datos de audio reproducindose 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 lnea de tiempo durante la reproduccin.

Figura 27. Distribucin de mltiples streams en el Helix Server

4.3.5 Comunicacin mediante HTTP

Los clientes de Helix pueden recibir archivos desde un servidor Web. Segn lo mostrado en la ilustracin siguiente, los clientes tienen un plug-in del sistema de ficheros del HTTP que les permita comunicarse con los servidores Web. Los clientes tambin utilizan el plug-in del formato del archivo para el tipo de datos servido.

65

Figura 28. Tunelamiento de Streaming sobre HTTP

La entrega del HTTP proporciona un mtodo 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 caractersticas avanzadas de reproduccin. Cuando el usuario desea colocar en un lugar mas adelante en la lnea de tiempo de la presentacin, la reproduccin en el cliente se detiene pero continua procesando los datos de streaming que le llegan a la rata normal que lo venia haciendo. La reproduccin contina solo hasta cuando se alcanza la posicin de la lnea de tiempo que el usuario haba elegido.

4.3.6 Manejo de memoria

El ncleo proporciona el manejo de memoria que, en la mayora de las plataformas, suprime el manejo de memoria proporcionado por el sistema operativo. Llevando a cabo su propio manejo de memoria el ncleo tiene la habilidad de soportar memoria compartida en un procesado basado en el servidor, mejorando capacidades de depuracin, e incrementando el desempeo de memoria, adems un pre-procesamiento de memoria cach se lleva a cabo para reducir la disputa de memoria compartida en mltiples procesos.

66

4.3.7 Manejo de Sesin

Las sesiones son administradas en el ncleo 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 sesin se maneja en conjunto por un objeto de Sesin. 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 especfica. 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 seales del protocolo en acciones para una sesin determinada. Por ejemplo, la seal RTSP PLAY es convertida por el componente de control protocolar a un evento que empieza el

playback de la sesin.

67

Figura 29. Control de sesin en el Helix Server

68

5. PLAN DE PRUEBAS
5.1 Metodologa
Para la realizacin de las medidas se hizo uso de los recursos disponibles en el laboratorio de Microelectrnica 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 distribucin a los clientes del contenido por medio del servicio de

streaming.
La conectividad inalmbrica se realiza por medio del punto de acceso, conectado al servidor a travs de una interfaz ethernet.

Punto de Acceso Equipo que permite realizar la conexin inalmbrica entre el servidor y los clientes inalmbricos. Debe cumplir con el estndar que se desea evaluar, en nuestro caso el IEEE 802.11a/b/g.

Cliente Equipo porttil bajo prueba, sobre el cual se ejecuta el reproductor de contenido

streaming multimedia, adems de las aplicaciones de diagnstico que se requieren

para determinar las condiciones de funcionamiento en el equipo cliente.

69

Sniffer Computadora de escritorio, sobre el cual se ejecutan las aplicaciones de evaluacin de desempeo sobre el canal inalmbrico, 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 aplicacin KISMET v 3.01, con el cual se capturan los paquetes comunicados a travs del canal inalmbrico en el que se encuentra la red. Para el equipo cliente, se hace uso de una computadora porttil DELL INSPIRON 1300, con procesador Intel Celeron, 1.4GHz y 512MB RAM, ejecutando un 70

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 investigacin que permite iniciar el reproductor automticamente luego de cinco segundos de iniciada la toma de datos, entre los que se incluyen el nivel de la batera (capacidad restante), consumo instantneo de corriente en la batera, voltaje instantneo de alimentacin en la batera, y algunos parmetros de operacin de la comunicacin inalmbrica tales como el nivel de seal, nivel de ruido y la calidad del enlace.

Figura 31. Plataforma de pruebas en el laboratorio de Microelectrnica y control.

El contenido multimedia con el que se desarrollaron las pruebas fue editado anteriormente, el estndar de codificacin, el tamao del frame y dems caractersticas relativas a la edicin. Luego de tener el contenido preparado, se almacena en el servidor, estableciendo as, un servicio de video bajo demanda.

71

El contenido almacenado en el servidor es un video de 10 minutos de duracin codificado en mp4 a distintas ratas, 112Kbps, 256Kbps y 512Kbps, con un tamao de frame de 320x240. Se pretende caracterizar las aplicaciones de video streaming sobre redes inalmbricas, considerando el impacto del servidor streaming as como de los niveles de compresin 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 energa sobre el equipo cuando no se reproduce nada, con el radio encendido y con el radio apagado. La descripcin del desarrollo de las pruebas es como sigue: Una vez encendidos todos los equipos, se configura la red inalmbrica (con direcciones de red apropiadas), se asegura que la batera este a plena carga, se terminan los procesos adicionales en los equipos y se desconectan los perifricos 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 trfico entre el servidor y el cliente por medio del sniffer. Una vez iniciada la reproduccin, se asegura que sta se realiza sin inconvenientes. Al finalizar cada medicin, se recarga completamente la batera 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 administracin de energa usados

por el sistema operativo directamente desde el sistema de archivos, en la ruta

/proc/acpi/battery.

72

El script recibe como argumentos la duracin del video en segundos y la ruta URL del recurso, la ejecucin del script consiste en realizar lecturas del cada segundo de las variables mencionadas anteriormente y almacenarlas en un archivo de texto durante la reproduccin 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 funcin 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 compresin 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.

73

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

74

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 compresin en el stream.

5.2.2 Diferentes servidores para cada rata de compresin

Las graficas siguientes muestran el consumo de corriente del cliente para cada uno de los servidores debido a una rata de compresin especfica.

75

Figura 35. Consumo de corriente [mA] en el cliente debido al stream de 112Kbit en cada uno de los servidores

Figura 36. Consumo de corriente [mA] en el cliente debido al stream de 256Kbit en cada uno de los servidores

76

Figura 37. Consumo de corriente [mA] en el cliente debido al stream de 512Kbit en cada uno de los servidores

En las graficas anteriores es posible visualizar la diferencia en el consumo de corriente en el cliente generado por el stream a una rata de compresin fija, enviado por cada uno de los servidores.

5.2.3 Comparacin 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 porttil con el radio apagado.

77

Figura 38. Comparacin de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 112Kbit

Figura 39. Comparacin de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 112Kbit

78

Figura 40. Comparacin de consumos de corriente [mA] Radio OFF Vs VLS con stream de 112Kbit

Figura 41. Comparacin de consumos de corriente [mA] Radio OFF Vs VLS con stream de 256Kbit

79

Figura 42. Comparacin de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 256Kbit

Figura 43. Comparacin de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 256Kbit

80

Figura 44. Comparacin de consumos de corriente [mA] Radio OFF Vs Helix Server con stream de 512Kbit

Figura 45. Comparacin de consumos de corriente [mA] Radio OFF Vs Darwin streaming Server con stream de 512Kbit

81

Figura 45. Comparacin de consumos de corriente [mA] Radio OFF Vs VLS con stream de 512Kbit

5.2.4 Graficas de trfico de red

Figura 46. Trfico de datos con stream de 112Kbits servidos por el VLS

82

Figura 47. Trfico de datos con stream de 256Kbits servidos por el VLS

Figura 48. Trfico de datos con stream de 512Kbits servidos por el VLS

83

Figura 49. Trfico de datos con stream de 112Kbits servidos por el Darwin Streaming Server

Figura 50. Trfico de datos con stream de 256Kbits servidos por el Darwin Streaming Server

84

Figura 51. Trfico de datos con stream de 512Kbits servidos por el Darwin Streaming Server

Figura 52. Trfico de datos con stream de 112Kbits servidos por el Helix Server

85

Figura 53. Trfico de datos con stream de 256Kbits servidos por el Helix server

Figura 54. Trfico de datos con stream de 512Kbits servidos por el Helix Server

86

CONCLUSIONES
A lo largo de todo este trabajo se discutieron las principales caractersticas 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 comn para dar una visin clara que ayude a determinar cual de ellos es apropiado en la generacin de streaming de video para dispositivos mviles.

En primer lugar nos concentramos en comparar las caractersticas 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 despus determinar cual de ellos presenta mejores prestaciones.

En segundo lugar hicimos un anlisis 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 mvil.

La arquitectura de los tres servidores analizados est diseada bajo un esquema modular, lo que permite adicionar nuevas caractersticas y modificar algunas ya preexistentes sin tener que modificar el ncleo central del servidor, lo cual es una gran ventaja.

La programacin del Darwin streaming Server y la del Helix Server estn basadas en el lenguaje C++ que a excepcin del VideoLAN Server utilizan las bibliotecas

87

estndar de este lenguaje. El VideLAN server por su parte tiene un framework, en el cual crea un entorno propio de desarrollo para ste, utilizando libreras propias desarrolladas para este fin.

En la parte de protocolos todos ellos utilizan los protocolos estndar

para

generacin de streaming, con excepcin del Darwin y del Helix que utilizan algunos protocolos propietarios, sin dejar de interoperar con sistemas basados en protocolos estndar.

En la parte de soporte, documentacin y cdigo abierto se debe hacer hincapi en lo siguiente. Todos los servidores analizados tienen muy buen soporte en documentacin, quizs el Helix tenga una documentacin mucho mas estructurada y un soporte mas completo puesto que dispone de una versin comercial de servidor, pero en cuanto a cdigo 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 caractersticas de la cual carece la versin

libre del Helix DNA Server. Entre esta caractersticas podemos mencionar como la ms importante la incapacidad que tiene la versin libre del Helix Server para servir videos en formato MPEG4, ya que esta caracterstica es propia de la versin comercial. La versin libre del Helix Server es muy limitada respecto a la versin del Darwin

streaming server.
En cuanto a la gestin del servidor, el VideoLAN Server es quizs el ms limitado de todos, adems 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 realimentacin

88

por parte del receptor en el control del stream que se presenta en las transmisiones basadas en el protocolo UDP.

soporte y codigo Servidor Modularidad MPEG4

Unicast

Multicast

abierto

VLC

Darwin Streaming Server

* *(limitado repecto a

Helix Dna Server

*(version comercial)

la comercial)

Tabla 7. Caractersticas de los servidores de streaming en evaluacin

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 variacin 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
compresin de datos vara (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 gestin empleados. En el siguiente cuadro se resume los diferentes consumos de corriente generados por cada servidor.

89

Power streaming Servidor 112k(mA) 1350 1375

Power streaming 256k(mA) 1385 1365

Power streaming 512k(mA) 1400 1360

VLC Darwin Streaming Server

Helix Dna Server

1377

1363

1361

Tabla 8. Consumos de corriente [mA] promedio a diferentes ratas de compresin

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 ms exigentes que los obtenidos con un stream de 112Kbps, es ms 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 solucin a implementar debera tener en cuenta alguno de los otros dos servidores, los cuales presentan un comportamiento ms 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 Trfico RTP es debido a que VLC enva todos sus datos sobre UDP y de ah el hecho de que solo este diseado para redes LAN donde este tipo de encapsulamiento es muy eficaz.

90

Tambin podemos notar que el trfico en cada una de las pruebas es mucho mayor del esperado, respecto a la rata de compresin y esto quizs sea la razn por la cual este servidor genera un consumo de potencia mucho mayor en el dispositivo mvil.

En las graficas 49, 50 y 51 correspondientes al Darwin streaming Server se observaron dos tipos de trfico principales, Trfico RTP y Trfico TCP. Eso nos da una idea del tipo de gestin que el servidor esta estableciendo. La ausencia de trfico UDP es debido a que el Darwin streaming Server encapsula este tipo de Trfico sobre RTP. En lo concerniente al trfico de red como tal, notamos algunos cambios bruscos originados por el tipo de implementacin 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 trfico con variaciones mas suaves, llevndonos a pensar en que la arquitectura interna y el plug-in de MPEG4 usado por este servidor estn debidamente sincronizados en la lnea de tiempo y hacen una implementacin bastante ptima del estndar. Igual que el Darwin streaming Server, Helix usa RTP como protocolo de streaming.

91

ANEXO 1. ACPI
ACPI significa Advanced Configuration and Power Interface. La funcin 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 batera, interfaz de red, temperatura y ventilador e informa de acontecimientos en el sistema como Cerrar la cubierta o Bateras poco cargadas. La BIOS dispone de tablas donde se recoge informacin sobre cada componente y sobre los mtodos para acceder al hardware. El sistema operativo utiliza esta informacin, 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 tambin se est supeditado a la implementacin 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 prctica Cuando el kernel reconoce una BIOS ACPI durante el arranque, ACPI es activado automticamente (y APM desactivado). El parmetro de arranque acpi=on podra ser necesario, como mximo, en mquinas 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 continuacin es necesario cargar una serie de mdulos, de lo que se ocupa el

script de inicio del daemon ACPI. Si alguno de estos mdulos 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 mdulo y puede observarse qu componentes han sido detectados.

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 todava en desarrollo y el soporte de otras depende en gran medida de la implementacin del fabricante. Para lograr una mejor comprensin de ACPI a continuacin se describen los archivos ms importantes:
/proc/acpi/info

Informacin general sobre ACPI

/proc/acpi/alarm

Aqu puede definirse cundo el sistema despierta de un estado de sueo. El soporte actual de esta funcin es insuficiente.
/proc/acpi/sleep

Proporciona informacin sobre los posibles estados de sueo.

/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 porttil.
/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 informacin sobre el estado de la batera. Para comprobar el nivel de carga es necesario comparar last full capacity de info con

93

remaining capacity de state. En alarm se puede introducir qu nivel de carga

provocar un evento en la batera.

/proc/acpi/button

Este directorio contiene informacin sobre diversos interruptores.

/proc/acpi/fan/FAN/state

Muestra si el ventilador est funcionando en ese momento. Tambin puede encenderse o apagarse manualmente escribiendo en el archivo 0 (=encender) 3 (=apagar). No obstante, hay que tener en cuenta que tanto el cdigo ACPI del kernel como el hardware (o la BIOS) sobrescriben estos valores cuando la temperatura es demasiado elevada.
/proc/acpi/processor/CPU*/info

Informacin sobre las posibilidades de ahorro de energa del procesador.

/proc/acpi/processor/CPU*/power

Informacin sobre el estado actual del procesador. Un asterisco en C2 significa inactividad y es el estado ms frecuente, como puede apreciarse en el nmero usage.
/proc/acpi/processor/CPU*/throttling

Aqu se puede configurar la suspensin del reloj de la CPU. Normalmente es posible reducirlo en ocho fases. Esta opcin es independiente del control de frecuencia de la CPU.
/proc/acpi/processor/CPU*/limit

Si un daemon se encarga de regular automticamente el rendimiento (obsoleto) y el throttling, aqu se pueden definir los lmites que no se deben sobrepasar en ningn caso. Existen algunos lmites que fija el sistema y otros que fija el usuario.

94

/proc/acpi/thermal_zone/

Aqu se encuentra un subdirectorio para cada zona trmica. Una zona trmica es una seccin con caractersticas trmicas semejantes, cuyo nmero 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 duracin del hardware. Por lo tanto, las descripciones siguientes son en parte puramente tericas.
/proc/acpi/thermal_zone/*/temperature

La temperatura actual de la zona trmica.

/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 mtodo de refrigeracin preferido controlado por ACPI: pasivo (menor rendimiento pero mayor ahorro) o activo (siempre mximo 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 accin. Esta accin puede abarcar desde la refrigeracin activa o pasiva hasta apagar el ordenador (critical), pasando por suspend (hot). Las acciones posibles se encuentran definidas en DSDT en funcin del dispositivo. Los trip
points definidos en la especificacin ACPI son: critical, hot, passive, active1 y

95

active2.

Aunque no siempre estn 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 automticamente 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 configuracin y eventos mencionados en las lneas superiores no tienen que editarse manualmente. Para ello cuenta con el daemon

Powersave (powersaved) y con diversos programas como powersave, kpowersave

y wmpowersave.

96

ANEXO 2. PORTAL DE GESTION DE CONTENIDO

Uno de los aspectos ms importantes despus de tener un servidor de video instalado y corriendo, es la etapa de gestin del contenido del servidor. Como gestin de contenido nos referamos a la capacidad que se le da al usuario del servidor para incluir contenido multimedia dentro de este. Fue con este fin que se diseo un portal de administracin de contenido multimedia para el servidor.

El portal cuanta con las siguientes caractersticas:

Sistema de bsqueda rpida

Con esta herramienta un usuario puede acceder al portal y realizar una bsqueda rpida por titulo de archivos multimedia dentro del servidor.

Figura 55. Bsqueda rpida

Sistema de Bsqueda por descripcin de campo

La bsqueda por medio de esta herramienta es mucho ms personalizada, y se puede hacer teniendo en cuenta los siguientes campos:

98

Figura 56. Bsqueda por descripcin 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.

Descripcin
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 especfico.

Palabras claves

99

Es una bsqueda que se utiliza cuando no se tiene informacin ni muy detallada ni muy somera de lo que se quiere buscar, se utiliza cuando se quiere obtener resultados de algn nombre en especial como puede ser el caso de alguien que desee buscar algo relacionado con el mar, entonces esta campote bsqueda 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 electrnicos, etc.

Dificultad
Es una valoracin que se le hace al contenido del archivo de acuerdo al grado de complejidad que este posea.

Edad mnima y Edad mxima

En estos campos se puede especificar el rango de edades para el cuales estn orientados la informacin.

La Bsqueda por campos, basta con uno solo de ellos si as se desea y le mostrara informacin concerniente a este. En caso de elegir varios campos la bsqueda se vuelve ms selectiva y detallada.

100

Bsqueda por flder

El usuario por medio de esta herramienta puede ir a todos los flderes de contenido multimedia del servidor y realizar una bsqueda por su propia cuenta, es algo as como un explorador.

Bsqueda alfabtica
El usuario tiene la opcin de buscar por orden alfabtico el archivo que el desee.

Figura 57. Bsqueda alfabtica

Grabacin 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

101

contenido, la descripcin, el pblico al que va dirigido y la edad de la audiencia. El usuario especifica tambin la direccin URL del archivo.

Figura 58. Grabacin de contenido

El portal fue escrito utilizando php, mysql y perl. Con php se realizo todo lo concerniente a la administracin de contenido del servidor y de la base de datos y con perl a la generacin de contenido dinmico del servidor como es el embebido de contenido multimedia dentro de la pgina Web para reproducir los archivos multimedia.

102

BIBLIOGRAFIA
[1] Andrew S. Tanenbaum , Redes de computadoras 4 edicin, 1997. ISBN: 9702601622. 4 edicin (2003). [2] ANSI/IEEE Std 802.11, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifcations, 1999 Edition (R2003) [3] [4] [5] IETF, RFC 793 TRANSMISSION CONTROL PROTOCOL, Septiembre 1981, http://www.ietf.org/rfc/rfc793.txt IETF, RFC 768 User Datagram Protocol, 28 August 1980, http://www.ietf.org/rfc/rfc768.txt IETF, RFC 1889 Transport Protocol for Real-Time Applications, 1996, http://www.ietf.org/rfc/rfc1889.txt [6] IETF, RFC 2326 Real Time Streaming Protocol, Abril 1998, http://www.ietf.org/rfc/rfc2326.txt [7] IETF, RFC 2960 Stream Control Transmision Protocol, Octubre 2000, http://www.ietf.org/rfc/rfc2960.txt [8] Darwin Streaming Server, http://developer.apple.com/opensource/server/streaming/index.html [9] Helix Server, http://www.realnetworks.com/products/media_delivery.html [10] VideoLAN Streaming Server, http://www.videolan.org/