AgoraRed: Aplicaciones de Gestión cooperativa sobre Redes Avanzadas

Transcripción

1 AgoraRed: Aplicaciones de Gestión cooperativa sobre Redes Avanzadas David Miguel Cortés Polo y José Luís González-Sánchez Universidad de Extremadura. Escuela Politécnica. Departamento de Informática. Avda. de la Universidad s/n Cáceres Resumen- El mundo de las comunicaciones multimedia está evolucionando cada vez a pasos agigantados, son más los usuarios que usan este tipo de comunicaciones para su vida cotidiana, VoIP, videollamada, Tv por Internet Hoy en día, la evolución tan grande que se ha experimentado y la diversidad de métodos para transmitir multimedia, han hecho que sea más factible acercar esta tecnología a todo el mundo. Tanto streaming, unidifusión como multicast son métodos para el envío de información multimedia con grandes virtudes y defectos. Es por esto que las posibilidades cooperativas que brindan estas comunicaciones es motivo de estudio y como cúlmen de este estudio se ha creado la herramienta VLinEx, sistema preparado para transmisiones de tipo multicast para un entorno colaborativo, en el que se pueda dar clases virtuales, conferencias tanto en vivo como en diferido. Palabras Claves Multimedia, Comunicaciones, Software Libre, RTP, RTCP, Vídeo, Audio, GNU/LinEx. 1. Antecedentes I. INTRODUCCIÓN Desde el origen de las redes se hicieron distintos experimentos para poder transmitir tanto audio como vídeo. A principios de los 70 comenzaron diferentes estudios sobre el envío de audio a través de las redes de datos llegando al primer RFC NVP (Network Voice Protocol). En este primer intento de transmitir audio a través de la red ARPANET le siguieron otros al aumentar los recursos con los que se contaba dentro de la misma llegando a crear el protocolo equivalente para el envío de vídeo ST (Stream Protocol). Los estudios siguieron su curso y en el periodo de 1992 a 1996 se desarrollo el protocolo RTP (RealTime Transfer Protocol) por la IETF. Con este protocolo se quería llegar a la base para las transmisiones multimedia en Internet no sólo por incluir herramientas para el envío multimedia sino por permitir el manejo de miembros, la sincronización de elementos y la mejora de la calidad de recepción multimedia. Es en la última década del siglo XX cuando la industria de las telecomunicaciones contempló la aparición de varias tecnologías revolucionarias. Una de ellas es la telefonía móvil, que ha modificado los conceptos de disponibilidad y multiplicado la productividad; otro es la aparición de Internet que ha multiplicado la información disponible a los usuarios y aumentado las posibilidades de comunicación; por último la aparición de las redes de banda ancha que han propiciado el acceso a los usuarios corrientes a nuevas formas de comunicación. Es por tanto que muchos usuarios demanden nuevos servicios que hace unos años sería impensable que pudiera llegar a los hogares, puestos de trabajo, universidades. En este sentido la videoconferencia, la televisión digital a través de Internet y la recepción de contenidos multimedia son cosas que están a la orden del día en estos momentos. Es por tanto normal que aparezcan nuevas formas de aplicación de este tipo de tecnología como el trabajo cooperativo en el que muchos usuarios puedan exponer sus conocimientos hacia otros usuarios, conferencias multitudinarias, foros... Es por esto que la palabra ágora ahora toma más significado que nunca en el sentido cooperativo, como un foro en el que poder exponer los conocimientos, pero no como se hacía antiguamente. Ya no es necesario congregar a personas en un lugar determinado, esto gracias a las redes es posible hacerlo desde diferentes partes del mundo y sin necesidad de estar en un lugar fijo. Es por esto que AgoraRed 1 tiene ahora un significado rico y completo, como un lugar de encuentro cooperativo entre usuarios de una red. Por otro lado hay que decir que al ser un concepto que se comenzó a fraguar allá por los años 70 y que en estos últimos años ha sufrido tal revolución muchos de los estándares que se crearon se han quedado obsoletos no sólo por la calidad con la que transfieren el contenido multimedia sino por los gastos de recursos que generan. Es por esto que la mayoría de las nuevas investigaciones están dentro del ámbito del software cerrado dejando muy de lado el mundo del open source y de la estandarización. 1 AgoraRed es un proyecto que forma parte de AGILA ( AGILA surge del II Plan regional de Investigación, desarrollo tecnológico e innovación de Extremadura, patrocinado por la Consejería de Educación, Ciencia y Tecnología de la Junta de Extremadura.

2 De tal forma que desde el proyecto de AgoraRed se intenta crear una plataforma de estudio para las tecnologías que existen de forma abierta haciendo un análisis sobre las mismas y poder servir de referente en nuevos proyectos del ámbito multimedia dentro del marco de GNU/LinEx, además de implementar una aplicación que sirva de base para el estudio cooperativo. II. ESTUDIO DE LA TECNOLOGIA 1. Flujo continuo Cuando hablamos de multimedia de flujo continuo a lo que nos referimos simplemente a reproducir vídeo o sonido a través de Internet, es decir a lo que se conoce como vídeo o música bajo demanda. El proceso del multimedia bajo demanda es simple, se inicia cuando un usuario al usar alguna aplicación que sirva este tipo de comunicaciones pida al programa un archivo multimedia, en este momento el navegador es el programa que se activa, estableciendo una conexión TCP con el servidor Web con el que el audio está vinculado. El siguiente paso es el de enviar una solicitud GET en HTTP para pedir el archivo, el servidor al recibir la petición busca en su disco duro el archivo almacenado lo devuelve al servidor Web y este a su vez al servidor Web del cliente. Si el archivo es más grande que la memoria del servidor tal vez obtenga y envíe en más de un bloque. El navegador cliente investiga, mediante el tipo MIME o por extensión del archivo, cómo se supone que debe desplegar el archivo. Debido a que la forma usual que tienen los navegadores para comunicarse con una aplicación auxiliar (encargada del despliegue) es escribir el contenido en un archivo de trabajo, donde guardará en el disco el archivo y finalmente el reproductor comenzará la reproducción del mismo. Realmente el enfoque es correcto, el problema es que para comenzar la reproducción se debe haber transmitido completamente el archivo con lo que no es una solución factible y se opta por usar un esquema en el que el servidor mantenga un archivo que será llamado metaarchivo en el que sólo se nombre al archivo de audio. Un ejemplo típico podría ser el de un archivo de texto ASCII como el siguiente: rstp://patanegra.unex.es/agorared/cancion1.mp3 Cuando el navegador obtiene el metaarchivo lo escribe en el disco, inicia el reproductor multimedia como una aplicación auxiliar, seguidamente este lo abre y se encuentra que el audio está almacenado en otro servidor con un protocolo rstp. Para que el reproductor pueda comenzar la reproducción ahora que ya no tiene el archivo almacenado en el disco duro debe mantener un búfer en el cual el servidor lo vaya llenando cada cierto tiempo. Normalmente antes de que el reproductor comience a reproducir espera que el búfer tenga 10 ó 15 segundos para comenzar. Idealmente, el servidor continuará llenando el búfer a la tasa exacta a la que el reproductor multimedia lo vacía aunque en realidad esto no sucede así, por lo que la retroalimentación es útil. Se pueden utilizar dos métodos para mantener lleno el búfer, Con un servidor pull (de recepción automática), siempre y cuando haya espacio en el búfer para otro bloque, el reproductor de medios simplemente sigue enviando al servidor mensajes en los que le solicita un bloque adicional. Su objetivo es mantener el búfer lo más lleno posible. La desventaja de un servidor pull son todas las solicitudes de datos innecesarias. Puede darse la situación en la que el servidor haya envidado el archivo por completo pero el reproductor le siga enviando solicitudes. Por esta razón raramente se usa. Con un servidor push (de actualización automática), el reproductor multimedia envía una solicitud PLAY y el servidor simplemente continúa enviándole datos. Aquí hay dos posibilidades: el servidor multimedia se ejecuta a la velocidad normal de reproducción o se ejecuta más rápido En ambos casos, algunos datos algunos datos se almacenan en el búfer antes de que inicie la reproducción, Si el servidor se ejecuta a la velocidad normal de reproducción, los datos que provengan de él se agregan al final de búfer y el reproductor elimina los datos del frente del búfer para reproducirlos. Siempre y cuando todo funcione a la perfección, la cantidad de datos en el búfer permanece constante Este esquema es sencillo debido a que no se necesitan mensajes de control en ninguna dirección. El otro método push es hacer que el servidor envíe datos a una velocidad mayor que la necesaria. La ventaja aquí es que si no se puede garantizar que el servidor se ejecute a una tasa regular, tiene la posibilidad de reponerse si se queda atrás. Sin embargo el problema es que son los desbordamientos potenciales de búfer si el servidor envía los datos con más rapidez que con la que se consumen. La solución es que el reproductor de medios defina una marca de agua baja y una marca de agua alta. Básicamente, el servidor sólo envía datos hasta que el búfer llega a la marca de agua alta. A continuación el reproductor de medios le indica que haga una pausa. Puesto que los datos continuarán llegando hasta que el servidor obtenga la solicitud de pausa, la distancia entre la marca de agua alta y el final del búfer tiene que ser mayor que el producto del retardo de ancho de banda de la red. Después de que el servidor se detenga, el búfer comenzará a vaciarse. Cuando llegue a la maraca de agua baja, el reproductor de medios indicará al servidor que comience de nuevo. La marca de agua baja tiene que colocare de manera que la inutilización de búfer no ocurra. [1] 2. Unidifusión TCP El punto de inflexión aparece cuando la transmisión debe ser en vivo, en este momento el método que hemos expuesto con anterioridad no sirve y por lo tanto se debe buscar otra forma para poder transmitir contenidos multimedia en vivo (retransmisiones de programas, conferencias, radio por Internet). Aunque tengan diferencias hay muchas cosas en común que se deben mantener. Un punto en el que coinciden es la necesidad de almacenar en el búfer del usuario para disminuir la fluctuación. Al recolectar 10 o 15 segundos de datos antes de comenzar la reproducción, los contenidos se reproducirán correctamente, aunque suceda fluctuación sustancial a través de la red. En tanto todos los paquetes lleguen antes de que se necesiten, no importa cuándo lleguen.

3 Una diferencia clave es que el flujo continuo puede enviar a una tasa mayor que la de reproducción, puesto que el receptor pude detenerla cuando se llegue a la marca de agua alta. Potencialmente, esto le da el tiempo para retransmitir los paquetes perdidos, aunque esta estrategia no es muy común. En contraste la reproducción en vivo siempre se difunde a la tasa exacta a la que se genera y a la que se reproduce. Otra diferencia es que una estación de emisión por lo general tiene cientos o miles de receptores simultáneos mientras que el audio de flujo continuo es punto a punto. Bajo estas circunstancias, la reproducción en vivo debería utilizar multidifusión con los protocolos RTP/RTSP. Esta es claramente la forma más eficiente de operar. Pero en la actualidad no funciona así. Lo que sucede es que el usuario establece una conexión TCP con la estación y la alimentación se envía a través de una conexión TCP. Por supuesto, esto crea varios problemas, como que el flujo se detenga cuando la ventana esté llena, que los paquetes perdidos expiren y se retransmitan, etcétera. [5] Hay tres razones por las que se utiliza la unidifusión TCP en lugar de la multidifusión RTP. La primera es que pocos ISPs soportan la multidifusión, por lo que no es una opción práctica. La segunda es que RTP es menos conocido que TCP y las estaciones de emisión por lo general son pequeñas y no tienen demasiados medios para poder hacer esto, por lo que es más fácil que utilicen un protocolo que conocen bien y que es soportado por todos los paquetes de software. La tercera es que muchas personas utilizan este servicio están detrás de un firewall para proteger su LAN contra ataques externos. Con lo cual y por lo general se obliga a las aplicaciones multimedia a que utilicen modos de operación drásticamente menos eficientes. [1] 3. Multicast Si los requerimientos que vamos a tener son mucho más específicos y la red lo permite podemos usar este tipo de comunicaciones las cuales son mucho más eficientes cuando el número de clientes aumenta drásticamente, multicast sería el método adecuado. Este se basa en protocolo RTP. RTP se puede dividir en dos partes: el protocolo de transferencia de datos y el protocolo de control asociado. El protocolo de transferencia de datos de RTP dirige la entrega de los datos de tiempo real, como audio y vídeo, entre sistemas finales. Define un nivel de descripción del documento multimedia, la detección de pérdida, tiempo de reproducción para permitir la recuperación de la sincronización El protocolo de control de RTP (RTCP) suministra la realimentación de calidad de recepción, la identificación de participantes, y la sincronización entre flujos. RTCP dirige RTP y provee de esa información de forma periódica. [4] Para nuestro sistema vamos a necesitar este tipo de transmisiones ya que son mucho más eficientes dentro de un entorno colaborativo. [2] III. ESTUDIO DE LOS CÓDECS MULTIMEDIA En la literatura técnica podemos encontrar numerosos métodos de codificación de vídeo y audio. Normalmente se basan en explotar los defectos visuales de la vista humana (las limitaciones psico-visuales), y defectos auditivos por lo que es la impresión subjetiva que la imagen o el sonido genera. En general si la frecuencia con la que llegan los datos es menor que la prevista se producirán parones en la imagen y silencios. Los códecs preparados para transmisiones por la red normalmente tienen que trabajar con un ancho de banda sumamente limitado con lo cual han surgido diferentes métodos de codificación para permitir que los contenidos enviados por la red mantengan una calidad aceptable a velocidades muy bajas. 1. Técnicas de compresión de vídeo Como ya se comento previamente una compresión reduce el volumen de datos, explotando las redundancias espaciales y temporales y eliminando los datos que no puedan ser exhibidos adecuadamente. El objetivo de la compresión es el de conservar la mayor cantidad de datos como sea posible para reproducir la imagen original sin causar distorsiones apreciables. Un sistema de compresión consta de los siguientes componentes: Digitalización, muestreo, y segmentación - los pasos que transforman señales analógicas en una malla de elementos fijos y estos en señales digitales. Una vez hecho esto la entrada de vídeo se divide primero en frames y luego en bloques. Reducción de redundancia La transformación de datos correlativos ya predefinidos dentro de un frame a otros que puedan ser invertidos y conseguir la imagen original. Reducción de la entropía Esto es la representación de la información digital descartando algunos bits menos significativos. Este componente causa alguna distorsión; es el factor básico de la compresión con pérdida. Codificación de entropía La asignación de palabras clave (cadenas de bits) de tamaño más pequeño que las cadenas originales de los frames. De esta forma se minimiza el número de bits necesarios para codificar una imagen. Algunas claves para la comprensión en las que se basan los códecs actuales son: Compensación del movimiento Es la codificación de los segmentos de vídeo considerando los desplazamientos entre segmento y segmento (o frame), en otras palabras, codificando los segmentos fijos de acuerdo con el resto de segmentos. Correlación espacial La correlación de elementos dentro de un frame de vídeo para una reducción de los frames por segundo, en otras palabras buscar frames que son idénticos o muy similares que no necesitan ser codificado, sino se deberá ordenar al decodificador que duplique los frame que ya ha sido codificado con anterioridad. Correlación espectral Es la correlación de componentes del color de un elemento de la imagen para una reducción de ancho de banda, (buscando los segmentos de una imagen que tienen el mismo color o similar por lo que no se necesita codificar ese color.

4 Correlación temporal La correlación entre frames correlativos de un vídeo con el propósito del ahorro de ancho de banda (es decir, buscando partes frames de vídeos que son iguales o similares, con lo que no es necesario codificar todas las propiedades en cada uno de los frames, sino que se debe de dar a entender al decodificador que recoja esa información de un frame en particular). Compresión de cuantización El desechar los bits menos importantes de una imagen para conseguir una compresión mayor (esto es equivalente a coger los colores que están más cerca de los colores puros y cambiarlos, ya que así se pueden describir con menos bits). Codificación intraframe Es la codificación de un frame de vídeo explotando la redundancia espacial dentro del frame. Una vez que se han encontrado correlaciones espaciales se pueden describir regiones duplicadas de la imagen una única vez. Codificación entre frames Es la codificación de un frame identificando elementos de ese frame con otros de frames anteriores. La idea es la de describir un elemento visual sólo una vez y luego dar a conocer al descodificador cómo se ha de visualizar ese frame. Eliminar las redundancias espaciales y temporales que existen en la imagen real es primordial para el proceso de la compresión sin pérdidas. Usando las técnicas correctas se puede conseguir la reproducción de vídeo sin necesidad de tener pérdidas de calidad (aunque necesitando mayor ancho de banda). Estas técnicas son necesarias para cuando lo que vamos a transmitir sea de mucha importancia en cuanto al apartado del vídeo como pueden ser las imágenes médicas. Aunque como contrapartida nos encontramos que el ratio de compresión es bastante más bajo que al usar técnicas de compresión con pérdidas y que pueden llegar a ser de aproximadamente 2:1. Con lo cual para una videoconferencia normal necesitaremos el uso de algunos otros algoritmos con pérdida que hagan uso de los defectos inherentes en el ojo humano y así conseguir una compresión de hasta 50:1. Las limitaciones del ojo humano incluyen: Respuesta al color y a la luminancia muy limitada. Existen más colores de los que podemos percibir y existe un umbral de luminiscencia sobre el que no podemos ver. Si se pudiera ver más allá del rango de luminancia que tenemos podríamos identificar objetos con una luz más intensa. Reducida sensibilidad al ruido a frecuencias altas, como son los bordes de los objetos. Reducida sensibilidad al ruido en las áreas más brillantes de la imagen. El objetivo de la compresión, es por tanto, descartar toda información que no es completamente necesaria en la imagen desde el punto de vista de la visión humana. Tal sistema puede ser descrito como sistema psicovisual sin pérdida. 2. DTC - Transformada Discreta del Coseno Dado los múltiples tipos de compresión que nos podemos encontrar nos vamos a centrar en el sistema básico. En el sistema básico, denominado a veces sistema básico secuencial, nos encontramos que la precisión de los datos de entrada y de salida está limitada a 8 bits, mientras que los valores cuantificados de la DCT están limitados a 11 bits. La propia compresión se realiza en tres etapas secuenciales: 1 - Cálculo de la DCT: Se divide la imagen en bloques de píxeles de tamaño 8x8 (ver Figura 1), que se procesan de izquierda a derecha y de arriba abajo. Según se va encontrando cada bloque o subimagen de 8x8, se cambian los niveles de sus 64 píxeles, sustrayendo de los mismos la cantidad 2n-1, siendo 2n, el máximo número de niveles de gris. Esto es, para las imágenes de 8 bits se resta 128 de cada píxel. Después se calcula la Transformada Discreta del Coseno bidimensional del bloque, produciendo un conjunto de 64 valores conocidos como coeficientes de DCT. 2 - Cuantificación de los coeficientes de la DCT: Los 64 coeficientes son entonces cuantificados, produciendo en algunos de ellos su reducción a cero. Los coeficientes son codificados en umbral, usando una matriz de cuantificación y son preparados para la codificación de entropía convirtiéndolos en una cadena unidimensional de 64 coeficientes en orden cuasi ascendente de los componentes de frecuencia. Para convertir los coeficientes en esta cadena unidimensional se reordenan usando una exploración o barrido en zig-zag. El primer coeficiente del barrido en zigzag es conocido como el coeficiente DC mientras que el resto son los coeficientes AC (ver Figura 2). A la matriz de cuantificación se le pueden aplicar factores de escala para obtener diversos niveles de compresión. Las entradas de la matriz de cuantificación son usualmente determinadas según consideraciones psicovisuales, las cuales son discutidas más adelante. 3 - Asignación del Código de Longitud Variable (VLC): El coeficiente DC de cada bloque es codificado usando DPCM. Es decir, se codifica la diferencia entre coeficiente DC del presente bloque y el del bloque previamente codificado. Puesto que la cadena unidimensional reordenada según el barrido en zig-zag de la Figura 2 está distribuida cualitativamente según una frecuencia espacial creciente, el procedimiento de codificación ha sido diseñado de modo que se beneficia de la existencia de largas series de ceros que se producen normalmente en la reordenación. En particular, los coeficientes AC no nulos se codifican utilizando un código de longitud variable que define el valor del coeficiente y el número de ceros precedentes. Se proporcionan unas tablas de especificación estándar de códigos de longitud variable. Figura 1: Bloque o subimagen de tamaño 8x8

5 Hoy en día la mayoría de las comunicaciones son en color, en el dominio RGB (Red, Green, Blue). Normalmente se transforman las imágenes RGB al espacio luminanciacrominancia, generalmente referido al dominio Y-Cr-Cb, definido como: Y = 0.3R + 0.6G B B Y Cr = R Y Cb = Ya que el ojo humano es relativamente insensible al contenido de altas frecuencias de los canales de crominancia Cr y Cb (ver Figura 4), son submuestreados por 2 en ambas direcciones. Esto es ilustrado en la Figura 3 donde los canales de crominancia contienen la mitad de muchas líneas y píxeles por línea comparados al canal de luminancia. De forma normal se ordenan los píxeles de una imagen a color como no entrelazado (3 exploraciones separadas) o entrelazado (una exploración sencilla). Figura 2: Barrido o exploración en zig-zag Figura 4: Respuesta visual a las variaciones de luminancia y crominancia El entrelazamiento hace posible descomprimir la imagen, y convertirla de la representación luminancia-crominancia a RGB para visualizarla con una mínima cantidad de memoria intermedia. Para los datos entrelazados, los bloques DCT son ordenados de acuerdo a los parámetros especificados en la trama. 3. Aspectos Psicovisuales A fin de reducir la redundancia psicovisual en las imágenes, se tiene en cuenta características del sistema visual humano en el proceso de compresión a través de la especificación de matrices de cuantificación. Se conoce que la respuesta en frecuencia del sistema visual humano decae con el incremento de la frecuencia espacial. Además, este decaimiento es más rápido en los dos canales de crominancia. La función de sensibilidad del contraste representada en la Figura 4 demuestra este efecto. Esto implica que una pequeña variación en la intensidad es más visible en regiones de variación lenta que en las regiones de variación rápida, y también más visible en la luminancia comparada con una variación similar en la crominancia. Como resultado se admite la especificación de dos matrices de cuantificación, una para la luminancia y otra para los dos canales de crominancia para asignar más bits a la representación de los coeficientes que son visualmente más significativos. Las figuras 5 y 6 muestran matrices de cuantificación típicas para los canales de luminancia y crominancia respectivamente. Los elementos de estas matrices son basados en la visibilidad de funciones bases individuales DCT de 8x8 con una distancia de observación igual a 6 veces el ancho de pantalla. Las funciones base fueron vistas con resolución de luminancia de 720 píxeles x 576 líneas y una resolución de crominancia de 360x576. Las matrices sugieren que estos coeficientes DCT que corresponden a imágenes base con baja visibilidad pueden ser mas toscamente cuantificados. Figura 3: Submuestreo de los canales de crominancia

6 Figura 5: Matriz de cuantificación para el canal de luminancia forma una matriz de 64 números de 0 a 255 (para imágenes de 8 bits) para la luminancia, y de 128 a +127 para las componentes Cr y Cb (ver la Figura 7). Cálculo de la DCT: Se aplica la DCT a cada uno de los bloques Y, Cr, Cb, generando para cada uno de ellos una nueva matriz de 8x8 compuesta por los coeficientes de las componentes de frecuencias espaciales. El valor de estos coeficientes disminuye rápidamente cuando se van alejando del origen de la matriz, terminando generalmente en una serie de ceros. De esta forma si un bloque es de luminancia y color uniformes, únicamente el primer coeficiente (coeficiente DC) no será nulo, y así solo habrá que transmitir un único coeficiente en lugar de 64. Discriminación por umbral y cuantificación: Esta etapa tiene en cuenta las particularidades de la visión humana: consiste en poner a cero los coeficientes inferiores a un valor predeterminado y en codificar los coeficientes restantes con una precisión decreciente a medida que la frecuencia aumenta. El coeficiente DC se codifica en DPCM, lo que permite aumentar la precisión de cuantificación para un número de bits dado, de manera que se puede minimizar la visibilidad de los bloques sobre la imagen reconstruida, ya que el ojo, si bien es poco sensible a los detalles finos, es, por el contrario, muy sensible a pequeñas diferencias de luminancia sobre áreas uniformes. Barrido en zig-zag: Con la excepción del coeficiente DC que se trata por separado, los 63 coeficientes AC se leen en zig-zag (ver Figura 2) para transformar la matriz en una cadena de datos en serie, adaptada a la próxima etapa del proceso. Codificación entrópica de Huffman (VLC): Esta última etapa consiste en codificar los coeficientes con una longitud tanto más corta cuanto más frecuentes sean estadísticamente, como se vio anteriormente. [8] 4. Compresión de audio Toda compresión de datos de audio se basa en la comprensión del mecanismo auditivo, por lo que constituye una forma de codificación perceptual. El oído es sólo capaz de extraer una cierta proporción de la información contenida en un determinado sonido. A esto se le puede denominar entropía perceptual, siendo redundante el sonido adicional. Figura 6: Matriz de cuantificación para el canal de crominancia La compresión de una imagen a color sigue los siguientes pasos: Descomposición en bloques o subimágenes: La imagen original en la forma Y, Cr, Cb se divide en bloques de 8x8 píxeles, siendo, para una imagen en formato CCIR 601 de 720 x 576, un total de 6480 bloques de luminancia Y y 3240 bloques para cada una de las componentes Cr y Cb. Cada uno de estos bloques Figura 7: División en bloques o subimágenes de 8x8 píxeles

7 Un sistema ideal debe eliminar toda redundancia, dejando únicamente la entropía. Existen muchos tipos diferentes de compresión de audio y cada uno permite un factor de compresión diferente. Algunas aplicaciones como DCC (Digital Compact Cassette) y DAB (Digital Audio Broadcasting) requieren un valor de Para el Minidisco, es de 0.2. La transmisión de audio por RDSI requiere más compresión todavía, que sólo puede realizarse empleando técnicas sofisticadas. La codificación de la sub-banda imita el mecanismo de análisis en frecuencia del oído humano y divide el espectro de audio en un gran número de bandas de frecuencia diferentes con el fin de poder explotar el hecho de que la mayoría de las bandas contienen señales cuyo nivel es inferior al de la señal más alta. Las señales en estas bandas pueden ser entonces cuantificadas independientemente. El error de cuantificación que resulta es confinado a los límites de frecuencia de la banda y así este puede arreglarse para ser enmascarado por el material del programa. Las técnicas usadas en las capas 1 y 2 de MPEG audio son basadas en la codificación de la subbanda como son aquéllas usadas en el DCC. En la codificación por transformación la forma de onda de audio en el dominio del tiempo es convertida a una representación en el dominio de la frecuencia como una transformada de Fourier, Discreta del Coseno o Wavelet. La codificación por transformación toma ventaja del hecho de que la amplitud o cubierta de una señal de audio cambia relativamente despacio y para que así los coeficientes de la transformada puedan transmitirse relativamente con poca frecuencia. Claramente tal aproximación se estropea en presencia de transitorios y se requieren en la práctica sistemas adaptables. Los transitorios causan que los coeficientes puedan ser frecuentemente actualizados mientras que en las partes estacionarias de la señal como las notas sostenidas la tasa de actualización puede reducirse. La codificación por Transformada Discreta del Coseno se usa en la capa 3 (layer 3) de MPEG audio y en el sistema de compresión del Minidisco. 1. Captura multimedia y compresión El proceso de la captura multimedia es esencial tanto de sonido como de vídeo que está siendo transmitido: un fame u onda sin compresión es capturado, si es necesario se transforma en un formato apropiado para la compresión, y luego el codificador es invocado para producir un frame u onda comprimida. El fotograma o sonido comprimido es pasado a la rutina de empaquetamiento y seguidamente uno o más paquetes de RTP son generados. Este es el proceso general de captura y compresión pero vamos a verlo más detenidamente para audio y vídeo. Considerando los detalles concretos de la captura de audio, la siguiente figura indica el proceso de muestreo sobre una fuente analógica para ser capturado, digitalizado, y guardado en un buffer. Para guardar las muestras en el buffer no se suele hacer de una a una sino que normalmente se almacenan después de que un número fijo de muestras han sido tomadas. Así mismo la mayoría de las APIs de captura de sonido devuelven los datos del buffer de entrada en tramas, reteniendo las muestras hasta que contenga número suficiente de muestras para ser devueltas de esta forma. Esto aumenta el tiempo de proceso ya que la primera muestra de una trama no estará disponible hasta que la última haya sido recogida. Normalmente las aplicaciones dirigidas al uso interactivo deben ser configuradas de forma que el tamaño del buffer coincida con la duración de la trama del códec, que suele ser de 20 ó 30 milésimas de segundo, para reducir el retraso. El audio sin comprimir es devuelto por el dispositivo de captura con un tipo de muestreo y con un rango de frecuencias específico. Los dispositivos de captura de audio comunes pueden devolver muestras con 8, 16 o 24 bits, usando cuantización lineal, µ - law o A law, con frecuencias entre 8,000 y 96,000 muestras por segundo, en mono o stereo. Dependiendo de la capacidad del dispositivo de captura y del códec podría ser necesario convertir el flujo multimedia en otro formato antes de que pueda ser usado. IV. PROPUESTA DE COMUNICACIONES MULTIMEDIA SOBRE GNU/LINEX 1. Introducción Fijándonos en el entorno GNU/LinEx no existe ninguna aplicación específica que permita una transmisión multimedia y que pueda ser aplicada al ámbito colaborativo. En este caso existen diferentes herramientas multiplataforma desarrolladas las cuales poseen carencias que hacen que se hayan quedado obsoletas y por lo tanto se debe intentar subsanarlas. No solo en los programas que existen en la actualidad tienen limitaciones, sino que los protocolos en los que se basan están desfasados con las nuevas tecnologías que se han desarrollado. Es por ello necesario el darles un lavado de cara a todos estos conceptos que son útiles. En los puntos anteriores hemos visto las funcionalidades del protocolo RTP y de los códecs, es ahora necesario ver el funcionamiento interno de un sistema de transmisión multimedia. Figura 8: Captura, digitalización y empaquetado de audio

8 Las tramas de audio una vez capturados son pasadas al codificador para la compresión. Dependiendo del códec, los parámetros de compresión pueden ser mantenidos por el códec o pueden ser con valores dinámicos. Algunos códecs, particularmente los códecs de música, basan su compresión un conjunto de tramas sin comprimir y otros comprimidos aisladamente. En estos casos el codificador necesita tener algunas tramas anteriores de audio, o almacenarlos en un buffer un conjunto de ellas para su posterior reproducción. Algunos códecs orientados a la voz suprimen el silencio, de tal forma que detectan y eliminan tramas que contienen solo silencio o ruido de fondo. Estas tramas suprimidas o no son transmitidas o son remplazadas por paquetes de ruido de baja frecuencia. De esta forma se consume poco ancho de banda, es especialmente recomendado este método para hacer un uso efectivo de los canales de capacidad limitada. Los dispositivos de captura de vídeo funcionan normalmente sobre frames completos del vídeo, en vez de devolver las líneas escaneadas individualmente o campos de una imagen entrelazada. Muchos brindan la posibilidad de submuestrear y capturar parte de un frame o devolver un subconjunto de los marcos. Los marcos pueden tener un rango de tamaños, y las capturadoras pueden devolver frames en variedad de formatos, espacios de color, profundidades, y subsampling. Dependiendo del códec usado, podría ser necesario convertir del formato usado a otro para poder ser visualizado. La conversión más comúnmente implementada está probablemente entre el RGB y YUV. Para estas conversiones se necesita una gran velocidad de proceso ya que sino se vería influenciado en la transmisión, por lo cual se han investigado a nivel hardware de las computadoras para aumentar esa velocidad (por ejemplo, instrucciones de MMX de Intel, instrucciones de VIS de Sparc). La siguiente figura ilustra la captura de vídeo, con el ejemplo de una señal de NTSC capturado en el formato de YUV ser convertido en el formato de RGB antes del uso. En cuanto los frames de vídeo han sido capturados, son almacenados antes de ser pasados al codificador para la compresión. El número de frames que son almacenados depende de qué esquema de compresión esté siendo usado; la mayoría de los códecs de vídeo llevan a cabo la compresión interframe, esto es que cada frame depende de los frames circundantes. La compresión interframe puede exigir que el codificador retrase la compresión de un frame especial hasta que los frames de los que depende hayan sido capturados. [2] 2. Generación de paquetes RTP Una vez que los frames son generados se pasan a la rutina de empaquetamiento RTP. Cada frame tiene asociado un timestamp, de la cual se obtiene la marca de tiempo de RTP. Si el payload soporta fragmentación, los frames grandes serán fragmentados en diferentes tramas. Para finalizar se generan uno o más paquetes RTP por cada frame, incluyendo cada uno los datos multimedia y cualquier cabecera de payload. El formato del paquete multimedia y la cabecera de payload son definidos de acuerdo con el formato de payload que se especifique para el códec. Las partes críticas para el proceso de generación de paquete son la asignación de timestamps a los frames, la fragmentación de frames grandes, y la generación de la cabecera de payload. [3] Además de los paquetes de datos de RTP que representan a los frames directamente, el emisor puede generar paquetes de corrección de errores y puede reordenar frames antes de la transmisión. Una vez que son enviados los paquetes, los datos multimedia guardados en la memoria intermedia son liberados. El emisor no debe eliminar los datos que puedan ser necesitados para algún reenvío. El requisito para poder guardar o no esos datos durante algún tiempo, dependerá del códec y el esquema de recuperación de error usado. [5] 3. Recepción de paquetes El primer paso del proceso de reproducción multimedia será capturar los paquetes de datos de RTP de la red, y almacenarlos en un buffer para su posterior proceso. La red puede afectar el cronometraje entre los paquetes, como muestra la figura 10, habrá saturación cuando varios paquetes lleguen a la vez o saltos cuando no llegue ningún paquete, además de que estos pueden llegar desordenados. El receptor no sabe cuándo van a llegar los paquetes con lo cual debe estar preparado tanto para las saturaciones como para los paquetes fuera de orden. Figura 9: Captura de Vídeo

9 Figura 10: Llegada de paquetes en un orden y a una velocidad distinta Cuando los paquetes son recibidos, se valida para la corrección de errores, se anota su tiempo de llegada, y son añadidos a una cola de entrada, clasificada por fecha de RTP, para su posterior procesamiento. La Figura 11 muestra la separación entre la recepción de paquete y rutinas de reproducción. Es importante almacenar el tiempo de llegada exacto de los paquetes de datos, M, con el propósito de que pueda ser calculado el interarrival jitter El tiempo de llegada es inexacto ya que a las mediciones se le suma el jitter de la red y por ello se puede causar el retraso en la reproducción. El tiempo de llegada debe ser medido de acuerdo con la referencia local del reloj del sistema, T, convertido a la frecuencia del reloj multimedia, R. Es posible que este reloj no tenga esta funcionalidad y por lo tanto se calcula a través de la fórmula de la siguiente manera: M = T x R + offset Donde offset es usado para transformar el reloj de referencia al tiempo multimedia, ya que en el proceso de la corrección se puede distorsionar el reloj del tiempo multimedia con respecto al otro. Cuando se programa una aplicación RTP hay que tener en cuenta que no podrá recibir y procesar los paquetes continuamente. Es por ello que como se ha comentado anteriormente se utilicen una serie de buffers de entrada para estas funcionalidades en la cual permiten la comunicación entre la parte receptora de paquetes y el reproductor. Con esto nos podría llevar a pensar que se produciría un retraso en la recepción de los paquetes, pero afortunadamente los sistemas operativos modernos manejan la recepción de los paquetes en dispositivos manejados por interrupciones con lo cual se almacenan los paquetes a nivel de socket para luego ser transportados al buffer general de entrada ya manejado por el nivel RTP. En lo referente a la recepción de los paquetes de control, se ha de tener en cuenta que estos deben ser procesados en paralelo con respecto a los paquetes de datos, es por ello que una aplicación debe estar preparada para recibir, validar, procesar y enviar los paquetes RTCP. Estos paquetes permiten mantener actualizada la base de datos de los emisores y los receptores dentro de una sesión RTP. [2] 4. Decodificando, Mezclando y Reproduciendo. Los paquetes de datos son extraídos del buffer de entrada y son insertados en la memoria intermedia del reproductor (ordenadas igualmente por fecha de RTP). Los frames se almacenan aquí por un corto periodo de tiempo para suavizar las diferencias de cronometraje entre las diferentes tramas almacenadas así como para que lleguen todos los fragmentos de una trama fragmentada en el emisor o que llegue la corrección de algún fragmento. Entonces las tramas se descomprimen, cualquier error que quedara se detecta y se trata y se muestra el resultado al usuario. La figura 12 muestra esto mismo. Con un único buffer se compensa la variabilidad de cronometraje de la red así como ser usado como memoria intermedia para el códec. Es posible separar estas funciones de forma que se usen buffers separados para compensar el jitter de la red y para la decodificación. Figura 12: El buffer de reproducción Figura 11: Separación de la recepción de paquetes de la reproducción usando buffers de entrada

10 Para cada fuente activa la aplicación debe mantener una instancia del decodificador, comprendiendo tanto las rutinas de descompresión como el contexto de compresión con el que se creo el flujo multimedia. El descodificador podría ser un hardware especializado o una función software, dependiendo del sistema. Su función será la de convertir cada frame comprimido en datos multimedia sin comprimir. Cuando cada frame es descodificado, el contexto de compresión se refresca como se muestra en la figura 13. El uso de un contexto de descompresión exacto es fundamental para que el descodificador opere correctamente ya que los códecs producirán resultados incorrectos si el contexto se pierde o es erróneo. Esto se produce a menudo si alguno de los paquetes de datos se pierde ya que habrá algunos frames no podrán ser descodificados. El resultado será un salto en la reproducción ya que no se podrá reproducir el frame que iría en ese lugar, además el contexto de descompresión será invalidado y los siguientes frames estarán corruptos. Dependiendo del códec es posible que se pueda señalizar que el frame se ha perdido, permitiendo al descodificador reparar lo mejor posible el contexto de forma que se minimicen el daño al flujo multimedia (por ejemplo muchos códecs orientados a la voz eliminan frames cuando detectan pérdidas en la señal). De otra manera el receptor deberá intentar reparar el contexto y ocultar los efectos de la pérdida La mezcla (o mixing) es el proceso de combinar múltiples flujos multimedia en uno. Esto se suele dar sobre todo en el audio ya que la mayoría de los sistemas tienen un único juego de altavoces y múltiples fuentes activas, como es el caso de de una teleconferencia múltiple. Esto se ilustra en la figura 14. Una vez que los flujos de audio han sido descodificados, se deben mezclar entre sí antes de ser enviado el producto final al dispositivo de audio. Las fases finales de una aplicación de audio se pueden estructurar como se muestra a continuación. El descodificador genera los datos de audio sin comprimir por cada fuente de datos, se almacenan en un buffer de reproducción distinto por cada fuente y el mezclador combina los resultados en un único buffer para la reproducción. Estos pasos pueden ocurrir en cualquier momento cuando el flujo de datos ha sido decodificado y antes de que llegue el momento de la reproducción. Figura 14: Mezclando audio El proceso por el cual el audio es reproducido al usuario es normalmente asíncrono, permitiendo al sistema que a la vez que reproduce un frame puede estar procesando el siguiente. Esta capacidad es esencial para un modo de operar normal y corriente como el que estamos acostumbrados ya que de esta manera se puede estar reproduciendo ininterrumpidamente aunque la aplicación esté ocupada con la captura y el procesamiento de paquetes RTP. La reproducción asíncrona es especialmente importante sobre los sistemas operativos con un soporte para multimedia limitado. Estos sistemas son diseñados para proporcionar una buena reacción media ante los eventos, pero a menudo tienen un comportamiento bastante malo con respecto a este tipo de reproducciones. Una aplicación puede usar la reproducción asíncrona apoyándose en el hardware de audio, es decir en el DMA (Directory Memory Access) para conseguir una reproducción continúa. Como se muestra en la siguiente figura una aplicación puede monitorear la ocupación del buffer de salida para ajustar la cantidad de información que se envía al dispositivo, de esa forma la ocupación del buffer después de cada iteración es continua. Figura 13: Operaciones de un descodificador multimedia Figura 15: Usando un buffer DMA de audio para una reproducción continua

11 Si la aplicación detecta un periodo anormal de latencia, quizás debido a que disco duro con mucha actividad en un momento dado, se puede incrementar el tamaño del buffer hasta el límite impuesto por la aplicación. La reproducción de vídeo es determinada por el refresco de la visualización, que determina el máximo tiempo entre la aplicación que está escribiendo en el buffer de salida y la imagen que está siendo presentada al usuario. La llave para conseguir una reproducción suave se consigue: Los frames deben ser presentados con un refresco uniforme; los cambios realizados a un frame deben ser evitados mientras el vídeo está siendo renderizado. El primer punto es un problema para el buffer de reproducción, ya que se debe seleccionar el tiempo apropiado para la visualización del vídeo. El segundo punto está relacionado con la visualización en sí. Los frames no se muestran instantáneamente; en vez de eso se representan en series de líneas de derecha a izquierda, y de arriba abajo. Esta representación en serie permite la posibilidad de que la aplicación sea capaz de mostrar un nuevo frame mientras otro está siendo mostrado. [6] La estructura general de nuestro programa se muestra en la figura 16. VLinEx es un sistema multiplataforma ya que ha sido desarrollado en Java. Pero a la vez es dependiente del sistema ya que tenemos que tener en cuenta los códecs utilizados para la reproducción en local. [7] 2. Ventana principal de la aplicación La ventana principal del programa tiene el un aspecto sencillo como se muestra en la figura 17. V. VISOR MULTIMEDIA SOBRE GNU/LINEX: VLINEX 1. Introducción Una vez analizados los fundamentos teóricos sobre los que nos vamos a basar vamos ahora a centrarnos en los aspectos técnicos que se han llevado a cabo para poder desarrollar la aplicación. La idea inicial es la de crear un software que tuviera la misma funcionalidad que las herramientas creadas hasta ahora, fuera completamente operativa con las mismas y además introdujera factores de reproducción que hasta la fecha no se contemplaban además de servir de base para futuras adaptaciones y mejoras. Por lo tanto partiendo de estas breves explicaciones y aplicando la metodología divide y vencerás vamos a ver las diferentes partes en las que hemos dividido la aplicación. Entorno Gráfico, necesario en este tipo de aplicaciones para hacer al usuario más agradable el uso de las mismas. Visor de documentos multimedia, será el reproductor en modo local de documentos multimedia de forma que tendremos que hacer un especial hincapié en los códecs de vídeo y de audio que vamos a necesitar, así como en la visualización de los documentos. Visor remoto, de esta forma se podrán establecer diferentes conexiones con otros usuarios (o participantes) de forma que podamos visualizar lo que otros nos envían. También aquí se hará necesario el uso de túneles para poder enviar la información a través de las redes que no soporten este tipo de tráfico. Gestor de sesiones, sistema preparado para el anuncio de sesiones remotas para anunciar las diferentes transmisiones de los usuarios. Figura 16: Estructura de la aplicación Figura 17: Interfaz del programa

12 Como podemos observar el programa es muy simple de manejar, es por tanto que nos vamos a centrar en la transmisión y en la recepción de sesiones multimedia, ya que el manejo como reproductor es como cualquier otro. 3. Emisión y Recepción de sesiones Primero deberemos estar visualizando ya algún contenido multimedia previo, ya sea un archivo o una reproducción en vivo. Al pulsar sobre el botón transmitir o conectar RTP, nos aparecerá una ventana de conexión sobre la sesión que queramos elegir. Una vez introducida la dirección multicast y el puerto que queremos, si estamos en la transmisión se pedirán los parámetros de configuración de la sesión, nombre de sesión y nombre del usuario y una vez que hayamos hecho esto se comenzará a transmitir el contenido multimedia a través de la sesión. Para esto también se pueden crear túneles por los que enviar la información de una isla multicast a otra como muestra la figura 18. En el caso de la recepción daremos la información de la sesión multicast y esperaremos a que nos comience a llegar el flujo de datos. Si en un cierto tiempo no llega este flujo deberemos crear un túnel entre nuestra isla y la isla que originó la sesión ya que si no ha llegado nada en ese intervalo de tiempo es porque la sesión no está dentro de nuestra isla y por lo tanto es necesario traspasar algún router para poder llegar hasta nuestro destino. VI. ESTUDIO PRÁCTICO. RESULTADOS Esta aplicación ha sido creada para servir de base teórica y práctica para el estudio de las aplicaciones MBone y así poder comprobar que la herramienta funciona según lo esperado y acorde con los estándares. Para entender correctamente estas pruebas hay que tener en cuenta el espacio en el que nos estamos moviendo, es decir, en un entorno no orientado a aplicaciones multicast, compartido con muchos otros usuarios, en el que este tipo de tráfico está cortado por los problemas que puede generar y en el que en la mayoría de los casos no se pueden crear unos escenarios de pruebas contundentes ya que al problema de los filtros con este tipo de tráfico hay que añadir que las máquinas con las que se cuenta, no son todo lo potentes que se necesitan para poder visualizar vídeo y audio en tiempo real con demasiada fluidez. 1. Prueba 1 Trafico local El primer caso que se plantea en este estudio práctico es el análisis de una conexión con un alto frame rate, producido por un archivo como puede ser una película. Como podemos ver los elementos usados para la red en este caso tenemos un par de ordenadores conectados en una red local interconectados por un hub, transmitiendo un archivo multimedia de forma que el número de frames de vídeo a enviar es mucho mayor que lo que se envía normalmente en una comunicación de videoconferencia, ya que el audio se envía siempre a la misma velocidad. Es por esto que probar con un vídeo que se envía a velocidad constante hace que sea una buena prueba para ver la reacción que va a generar sobre una red que está siendo utilizada por muchos usuarios. Opción Valor Dirección de la sesión Puerto y TTL 1234,1 Localización emisor Laboratorio telemática Localización receptor Laboratorio telemática Hora 17:57-18:18 Tipo de medio Ethernet Ancho de banda de la 10Mbps red Medio trasmitiendo Película (Divx y MP3) Las gráficas resultantes de esta conexión se ilustran en las figuras 19 y 20. Como se puede ver en este caso la fuente que introducimos en la red local no hace que se sobrecargue la red ya que como se puede ver los otros usuarios siguen transmitiendo datos TCP sin que se noten bajadas en el tráfico. Figura 19: TCP comparado con UDP en videoconferencia Figura 18: Islas multicast interconectadas por un túnel

13 Figura 20: TCP comparado con UDP transmitiendo vídeo Figura 21: TCP comparado con UDP Como podemos observar en la figura anterior la línea roja es variable y genera muchos picos de sierra, esto es siempre identificativo de transmisiones de vídeo ya que el payload de la trama RTP varía con respecto a los fps a los que se mueva la imagen. De la misma forma cabe destacar que el audio que figura en la línea verde es más constante y se acerca a una recta ya que el payload en este caso si es constante siempre. Como vemos en cuestiones de ancho de banda y teniendo en cuenta que usamos un conmutador de 10Mbps la información envidada sumando los dos canales no va a sobrepasar este máximo y por lo tanto es factible conectar varios equipos para poder ver la misma sesión. Esto se cumplirá si el número de equipos no es muy elevado ya que sino el tráfico que se generaría sería demasiado grande para poder aguantar la comunicación. Los picos más extremos generados por el vídeo se producen ya que en esos momentos la reproducción tendrá un alto contenido en movimiento y en colores, con lo que se debe mandar mucha más información que si el vídeo tiene un bajo movimiento y los colores son muy apagados ya que los bits de luminancia usados para codificar la imagen serán mucho menores. Es por este mismo efecto las depresiones que se encuentran en la gráfica. En estos momentos nos encontraremos con que el vídeo tendrá muy poco movimiento (un primer plano con algún monólogo sin mucho movimiento de cámara) y será con imágenes muy oscuras con lo que la codificación necesitará menos bits. Si nos fijamos en la figura 21 el ancho de banda usado por nuestro programa consumido por un vídeo y por otro (línea negra en el primero y roja en el segundo) es mucho menor para una webcam, esto es de esperar ya que en el primero los fps son mucho menores y además de la codificación de los colores es mucho menos rica que en una película y la necesidad de enviar todos los movimientos muchas veces es innecesaria ya que la imagen está fija y por lo tanto cambian pocas cosas entre uno y otro frame. Es por esto que el uso de este sistema como videoconferencia dentro de una red local es factible y ya realizable desde hace algunos años. 2. Prueba 2 Tráfico local con red saturada En esta prueba vamos a ver como reacciona el tráfico en el momento en el que se sobrecarga la red y son generados muchos paquetes a la vez. Opción Valor Dirección de la sesión Puerto y TTL 1234,1 Localización emisor Laboratorio telemática Localización receptor Laboratorio telemática Hora 19:00-19:30 Tipo de medio Ethernet Ancho de banda de la 10Mbps red Medio transmitiendo RGB y PCM En esta situación nos encontraremos una evolución típica de la red como esta: Figura 22: Tráfico TCP muy superior a UDP

14 Como se puede observar el tráfico TCP es mucho mayor que el tráfico UDP aunque estemos usando multicasting y se esté enviando la información por toda la red inundándola, esto quiere decir que nuestro tráfico se va a ver repercutido con este flujo tan grande de información. Vamos a comparar dos casos en los que la red está muy saturada y como influye en nuestros canales de comunicación, esto se ilustra en la figura 23. Como podemos observar el canal de audio (línea verde y línea roja en las otras dos) se mantiene igual que en el resto de las transmisiones en las que se ha usado micrófono llegando a alcanzar una velocidad en Bytes/seg similar a la prueba sin congestión (1º sobre LinEx). La situación anómala es la ausencia de pequeños máximos en la señal que se ha venido produciendo en las pruebas anteriores. Sabiendo que el payload del audio es constante vemos como el tráfico generado por las otras computadoras hace que el sistema no pueda disponer de todo el ancho de banda requerido. Como hemos visto anteriormente el tráfico TCP era más de 2 veces el tráfico UDP. Es por esto y basándonos en la teoría que podemos afirmar que el tráfico generado por TCP hace que se vea atenuado la información enviada por UDP, de esta forma podemos observar también el vídeo enviado a la red (línea roja y líneas negras en las otras dos) que si bien se caracteriza normalmente en enviar menos información que el audio nos encontramos con la misma situación en la que de los típicos dientes de sierra que se pueden encontrar en la transmisión de vídeo pasamos a una gráfica totalmente plana. Esto es generado por el mismo fenómeno achacable al audio, la gran confluencia de tráfico TCP que hace que no sea posible el envío del vídeo correctamente. A modo de conclusión tenemos que dependiendo de la carga de la red se podrá mandar más o menos información máxima a la red, si nos fijamos en el primer caso en el que apenas había tráfico vemos que la velocidad a la que envía y el bitrate de la transmisión se mantiene constante permitiendo una buena comunicación entre los distintos usuarios. En las dos gráficas siguientes vemos que este bitrate no se puede mantener estable ya que hay mucho tráfico circulando por la red, con lo que vamos a tener que notar algunos saltos en la imagen y en el sonido de forma que la comunicación no sería todo lo perfecta que quisiéramos. 3. Prueba 3 Tráfico local sobre red WiFi En esta prueba vamos a ver como reacciona el programa usando un punto de acceso WiFi y por lo tanto las virtudes y desventajas que tiene. Opción Valor Dirección de la sesión Puerto y TTL 1234,1 Localización emisor Laboratorio telemática Localización receptor Laboratorio telemática Hora 20:50-21:00 Tipo de medio Ethernet -WiFi Ancho de banda de la 10Mbps red Tipo de medio Película (Divx y MP3) La figura 24 muestra la relación entre el tráfico TCP comparado con el tráfico UDP de la transmisión y la figura 25 se centra en la relación entre el canal de audio y el canal de vídeo. En esta última gráfica se puede ver claramente que lo que estamos transmitiendo es un archivo de vídeo ya que el canal de vídeo (línea negra) copa la mayor parte del ancho de banda en casi toda la transmisión con respecto al audio (línea roja) que se mantiene constante. Hay que notar que al final de la gráfica nos encontramos con un periodo de tiempo en el que el ancho de banda consumido por el vídeo es muy bajo en relación con el consumido con el audio, esto puede ser producido por varios factores. El primero puede ser una sobrecarga en el emisor que haga que no se pueda enviar la información de manera conveniente de forma que el vídeo al ser la parte más inestable de la comunicación se vea afectado, este factor sólo se puede constatar al estar delante de la máquina, y el segundo factor que puede hacer que esto suceda es que en ese momento la película esté en una escena muy oscura, casi negra con muy poco movimiento, con lo cual la cantidad de información a codificar es muy pequeña y por lo tanto se requiere muy poco ancho de banda como podemos ver en los otros momentos de la reproducción que también en ancho de banda decae como puede ser en el segundo 300 de esta transmisión hasta el 500. En este caso este factor es el que ha producido ese efecto en la gráfica. Si comparamos con la transmisión local de la primera prueba para ver la comparativa entre los dos medios de transmisión obtendremos la figura 26. Figura 23: Evolución del tráfico local con red saturada Figura 24: Tráfico TCP comparado con UDP

15 Medio trasmitiendo Película (Divx y MP3) Figura 25: Comparativa de los canales de audio y vídeo Figura 26: Comparativa de transmisión en local con wifi y con cable Gracias a la figura 26 podemos asegurar no hay mucha diferencia entre usar WiFi y usar un cable de red UTP-cat5. Es por esto que cualquiera de los dos métodos es bueno para retransmitir la información. Como se puede observar en la figura 27 los anchos de banda son muy similares, teniendo en cuenta variaciones posibles dependiendo del tráfico que se pueda estar dando en la red, aun así hay que destacar la no similitud de la primera ya que si nos fijamos, la transmisión de datos de TCP detecta algunos fallos. De esta forma se producen esas caídas en el ancho de banda que repercutirán en el tráfico UDP ya que este tráfico va encapsulado en TCP por medio del túnel. Vamos a ver más de cerca cada uno de los canales del túnel. Como se puede ver en la comparativa de la figura 28, la prueba de las 13h es la peor parada en la transmisión del túnel, esto es debido a que el tráfico generado en ese momento es mucho mayor que a las otras dos horas con lo que se ve resentido en transferencia de información, como vemos al ser una transferencia TCP toda la información enviada debe llegar a su destino aunque sea a base de retransmisiones, es por esto que nos encontramos un pico de información mayor que en los otros dos ejemplos. Esto producido a posibles recuperaciones de errores. Además podemos darnos cuenta de que los errores se producen la gran mayoría en el vídeo dado que es mucho más inestable en su flujo de información y por lo tanto se pueden producir momentos en los que se necesiten más ancho de banda de lo que la red puede dar en momentos de congestión y por lo tanto se producen estas caídas. A modo de conclusión se puede comprobar que el sistema es viable para ser usado en un entorno inalámbrico pero con limitaciones, ya que hay que tener en cuenta la velocidad de respuesta del punto de acceso en cuestiones de retransmisión de la señal, con lo que puede hacer que el programa al esperar un tiempo de respuesta predefinido pueda lanzar el túnel aunque no tenga que saltar ningún router. Por otro lado también es destacable que al igual que se sobrecarga el hub cuando se genera mucho tráfico el punto de acceso también se puede sobrecargar sobre el que se está conectado. Pese a todo es otra tecnología de red que puede ser usado para estos menesteres y que permita la movilidad, un aspecto muy demandado últimamente. Figura 27: Comparativa de gastos entre TCP y UDP 4. Prueba 4 Tráfico remoto En este caso vamos a ver que pasa a diferentes horas del día con respecto a la transmisión a través de la red desde el laboratorio de telemática hasta una subred en un hogar cualquiera. Opción Valor Dirección de la sesión Puerto y TTL 1234,1 Localización emisor Laboratorio telemática Localización receptor Casa del alumno Hora 13h, 16h y 21h Tipo de medio Ancho de banda de la red Ethernet-ADSL 10Mbps-2Mbps Figura 28: Comparativa entre los flujos del túnel

16 Es por esto que podemos asegurar que la congestión de la red a las 13h es mucho mayor que a las otras dos, que se mantienen constantes y por lo tanto que el vídeo se va a retrasar más en la primera prueba que en las otras dos. Como era de esperar en la figura 29, los flujos multicast se corresponden con los flujos TCP comentados anteriormente, es por esto que en la primera existen esas caídas en el flujo del vídeo ya que al tener que esperar TCP para que les sean reenviados todos los datos del emisor puede darse el caso de que se produzca un error y por lo tanto influir en la transmisión multicast que se está realizando en el otro lado del túnel. Vamos ahora a comparar las retransmisiones que se han tenido que hacer durante la sesión. (Véase figura 30) Como se puede ver el número de retransmisiones en el primer caso es mayor que el segundo esto denota que la sobrecarga en la red es muy grande y por lo tanto se necesitan retransmitir muchas tramas enviadas desde el emisor (en la escuela politécnica) al receptor. Esto es comprensible dado que el mayor tráfico en la red de la escuela está más saturada ya que es el momento en el que hay más gente (además de que cuando se realizaron las pruebas es época de exámenes y por lo tanto por la tarde hay muy poca gente en la escuela). Este mismo motivo podemos achacarle al tráfico de las 16h aunque también puede ser producido por el tráfico de la propia red de Telefónica. Y por lo tanto podemos ver como el tráfico a las 21h es mucho menor ya que en la escuela no hay casi nadie generando tráfico y por lo tanto va mucho más fluido. Figura 29: Comparativa entre los flujos multicast A modo de conclusión cabe destacar el problema de un tráfico excesivo dentro de la red que afecta a la transmisión, aunque esto también es recíproco si se necesita usar una aplicación que consuma mucho ancho de banda va a incidir en esto. Por tanto la conclusión que se saca de esto es que la mejor forma para usar este tipo de tecnología para un ámbito comercial es usar unas redes que permitan calidad de servicio (ATM, MPLS, UMTS ) además de no usar otras aplicaciones con grandes requerimientos de ancho de banda que puedan influir en su funcionamiento. Es por esto que en el caso de las televisiones digitales se use una red troncal para difundir la información sin necesidad de inundar la red de datos, además de usar conexiones con los usuarios finales dedicados únicamente para ese tipo de servicios. VII. CONCLUSIONES Una vez llegado al final de una investigación es normal que se lleguen a unas series de conclusiones. Estamos en un momento dulce para la tecnología multimedia los grandes cambios que se avecinan en los próximos años hacen que sean todavía más emocionante si cabe las distintas investigaciones que pueden surgir a través de los diferentes campos de la telemática orientada sobre todo al mundo multimedia. Los cambios son grandes, en las redes deberán aparecer nuevos elementos que permitan una mayor fluidez a la hora de transmitir tráfico multimedia. La incorporación de la telefonía móvil y la Voz sobre IP son dos elementos que favorecerán a esto. Ya que son dos tecnologías que acaban de nacer y por lo tanto todavía no han sido estudiadas a fondo. Además hay que destacar la fuerza con la que se está promocionando la televisión a través de Internet que influirá de manera considerable a estos cambios también. Por lo tanto y a reseña de los anteriores acontecimientos que están sucediendo es de esperar que muchos nuevos estándares sean aprobados, se revise y mejore los que existen actualmente y sea de uso general estas tecnologías. En cuanto a la tecnología usada en este proyecto (RTP y multicast) hay que decir que aunque está en decadencia y se ha quedado obsoleta, puede seguir teniendo su propia parcela y su porqué en algunas aplicaciones como es el caso de las aplicaciones cooperativas. Si bien es cierto que el desarrollo de este tipo de tecnología ha sido desbancado por otras más modernas y accesibles para un usuario medio, cabe decir que aunque son más nuevas en algunos casos sigue siendo recomendable usar multicast en ciertos entornos (clases a través de la intranet, conferencias dentro de la universidad ) ya que permiten llegar a todos los interesados en estos entornos sin necesidad de grandes anchos de banda ni grandes problemas. Figura 30: Comparativa de retransmisiones VIII. LÍNEAS DE INVESTIGACIÓN FUTURAS A lo dicho anteriormente como conclusiones hay que añadir que el trabajo que queda sobre este tema es largo y muy amplio. Ha habido muchas cosas que se han quedado en el tintero ya que esto quería ser el comienzo de algo mucho más

17 grande y nació con la idea de suplir el hueco que existía en las herramientas multicast desde hace varios años. Es por tanto que muchas de las nuevas herramientas en el mundo del tráfico multicast deben ser adaptadas para ser usadas dentro de este proyecto. Si comenzamos desde abajo, desde la forma de ver las imágenes, en este proyecto se ha intentado acomodar las nuevas formas de almacenar y visualizar los contenidos multimedia para que pudieran ser reproducidos por nuestro programa, pero es del todo ineficiente tener que estar descomprimiendo un fichero de vídeo o de audio para tener que recodificarlo después en otro formato, con la pertinente pérdida de información (H.263) es por esto que queda como trabajo futuro el poder adaptar la mayoría de los códecs de vídeo y de audio que han aparecido en la actualidad para que puedan ser reconocidos como un tipo de Payload de RTP y puedan ser enviados por la red sin cambio ninguno, únicamente siendo descodificados del fichero multimedia y enviados por la red. Además de esto hay que tener en cuenta el desarrollo que se está haciendo ahora mismo sobre el protocolo H.264 que es el sucesor del códec aquí usado (H.263) de tal forma que sería bueno adaptar el programa a los nuevos tiempos usando un códec mucho más avanzado que el anterior. Pasando a otro nivel hay que decir que también hace falta incorporar un sistema para volcar lo que está siendo reproducido al disco duro de forma que para ello habría que adecuar los códecs que ahora mismo se incorporan al programa y otros nuevos para poder codificar la información mostrada a un fichero multimedia. Por otro lado hay que decir que merece la pena estudiar formas para mejorar el rendimiento de la aplicación en cuanto a modo de funcionamiento, de forma que se pueden crear multiplexadores y demultiplexadores para poder codificar los canales de audio y de vídeo en un único canal y así evitar los desagradables retrasos que se producen en toda comunicación multimedia y que son inherentes en ella. En cuanto al uso de túneles TCP se puede ver los problemas que conllevan en cuanto a desincronización y a la sobrecarga de la red con retransmisiones. Dado que en esta escuela el grupo de investigación sobre MPLS es muy importante a nivel nacional sería interesante migrar este tipo de túneles a túneles MPLS para que se puedan aprovechar todos los recursos de la red. Además el sistema de sesiones propuesto es un sistema no estandarizado y por lo cual únicamente lo usa este programa, es por ello importante el uso de estándares en todo momento con lo cual el sistema de sesiones propuesto tendrá que ser migrado a un sistema de sesiones SIP. Internet Engineering Task Force, Work in Progress (actualización RFC 1889), Marzo [3] S. Casner and P. Hoschka. "MIME Type Registration of RTP Payload Formats," Internet Engineering Task Force, Work in Progress, Noviembre [4] H. Schulzrinne, A. Rao, and R. Lanphier. "Real Time Streaming Protocol (RTSP)," Internet Engineering Task Force, RFC 2326, April [5] M. Allman, V. Paxson, and W. Stevens. "TCP Congestion Control," Internet Engineering Task Force, RFC 2581, April [6]J. Sjoberg, M. Westerlund, A. Lakaniemi, and Q. Xie. "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs," Internet Engineering Task Force, RFC 3267, June [7] Java Media Framework API guide version 0.8 (1999) Sun Microsystems [8] Mohammed Ghanbari, Standard Codecs: Image Compression to Advanced Video Coding 1ed (2003). Ed. Institution of Electrical Engineers IX. REFERENCIAS [1] Andrew S. Tanenbaum, Redes de Computadores 4º, ed (2004) Ed. Prentice Hall. (Punto y 7.4.4) [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications,"