| Artículos | 01 JUN 1998

Audio yVídeo en Internet

Tags: Histórico
La Red como medio de comunicación
Esteban Trigos.
La posibilidad de tener Audio, Vídeo y Vídeoconferencia en la Red han convertido a ésta en un medio de comunivcación. Pero ¿cómo funcionan estos sistemas? ¿Nos espera algo mejor o, por el contrario, se está tocando techo?

Los programas para poder escuchar audio y ver vídeo a través de Internet son, junto a los de videoconferencia, los que más atención están captando del usuario que utiliza habitualmente la Red. Internet, por si sólo ya es un medio propio de comunicación. Tiene todo lo que necesita para llegar a su receptor de una forma rápida, clara y directa. Pero a la vez, tiene la ventaja de poder agrupar a otros medios de comunicación habituales con el fin de integrar varios tipos de información bajo un mismo medio. Esto es lo que ocurre, por ejemplo, con un periódico en Internet. Por supuesto, ofrecerá toda su edición escrita, con todas sus secciones y páginas de opinión. Pero tratándose de una edición online es posible poner un fragmento de la entrevista o rueda de prensa del protagonista de la noticia principal. Así, de esta manera, se puede presentar al lector un fragmento de vídeo de una presentación de un libro en un acto cultural.
Internet es una red de ordenadores que está basada en la conmutación de paquetes, pero por el contrario no fue diseñada para manejar información en tiempo real (audio/vídeo). Internet tiene formas fiables de enviar los datos, utilizando protocolos de transporte: la primera es utilizando el protocolo TCP (Transmission Control Protocol, Protocolo de control de transmisión) y la segunda es utilizando el protocolo UDP (User Datagram Protocol, Protocolo datagrama de usuario). UDP apenas ofrece control, mientras TCP es un protocolo fiable pensado para la conexión punto a punto. Los mecanismos de control de flujo y fiabilidad de TCP no son demasiado apropiados para información constante (vídeo, por ejemplo). La pérdida de un paquete de audio puede ser aceptable (usando UDP), mientras que los retardos de transmisión en TCP, provocados por un control excesivo, pueden ser muy desfavorables para obtener una buena calidad de servicio en tiempo real.

Los servidores Web
¿Y porqué no utilizar un servidor Web? Éstos servidores podrían ser una solución ya que están muy extendidos por Internet y hay gran variedad (sobre plataformas Windows, Macintosh, Unix, etc.). Bien, los servidores Web utilizan el protocolo HTTP (Hypertext Transfer Protocol), que envía información usando un protocolo, el TCP, para la transferencia de páginas web. Los navegadores, por ejemplo, comienzan a presentar en pantalla la página que hemos solicitado a medida que va llegando, de este modo no es necesario esperar a que se complete la carga para poder visualizarla. Pero, desgraciadamente, cuando un servidor Web es usado para enviar información en tiempo real como audio, que necesita llegar rápidamente hasta el usuario, el problema del retraso antes comentado del TCP puede hacer que esta transmisión sea tarea difícil. Lógicamente cuanto más grande fuera el ancho de banda de la línea de comunicación menor sería el problema, pero la mayoría de los usuarios acceden a Internet a través de un módem de 33.6 Kbs o una RDSI, por lo que este tipo de emisión no sería la apropiada.
Además, ¿qué ocurriría si un usuario quisiera ir a un punto en concreto de una entrevista o una canción?. Esto no está contemplado bajo el protocolo TCP, los protocolos de Internet están diseñados para la transmisión continua en un solo sentido y no existe el concepto de comunicación bidireccional entre el ordenador cliente y el servidor. Por ejemplo, en una comunicación FTP no podemos coger fragmentos de un fichero, sino que nos lo traemos a nuestro ordenador en una sola vez, desde el principio hasta el final (otro caso es que retomemos la transferencia desde un punto donde la habíamos dejado).
Los servidores web están diseñados para entregar grandes bloques de datos al cliente tan rápido como sea posible, pero manejan un pequeño número de accesos concurrentes (usuarios en un mismo instante). Un Web de gran tamaño puede estar configurado para soportar alrededor de 100 o más conexiones concurrentes. Esto significa una alta capacidad de proceso por parte del servidor Web. mientras que para un servidor de audio sería una tarea que le llevaría menos trabajo.
Como se ha visto hasta ahora los protocolos y servidores utilizados en Internet son los adecuados para la finalidad que tienen: transferencia de páginas web (código HTML, gráficos, etc.) junto con elementos activos (controles ActiveX, applets de Java, JavaScript, etc.) pero no son la solución a la necesidad de enviar en tiempo real información multimedia al usuario.

Los nuevos protocolos
Debido a las dificultades que existen para poder transmitir información multimedia en tiempo real a través de Internet, las principales empresas implicadas en estas tareas, así como los organismos de Internet que tienen como misión la búsqueda de nuevos estándares, su desarrollo y correcta implementación, se pusieron manos a la obra para encontrar un sistema más fiable para poder utilizar Internet como soporte para este tipo de emisiones. Con este objetivo, se han desarrollado los protocolos RTP (Real-time Transport Protocol), RTCP (Real-time Control Protocol), RSVP (Resource Reservation Protocol) y RTSP (Real Time Streaming Protocol).
El protocolo de transporte (RTP, Real-time Transport Protocol) tiene como objetivo la entrega de datos en tiempo real, incluyendo emisiones de audio y vídeo bajo redes unicast y multicast. RTP está definido en el IETF (Internet Engineering Task Force) por el RFC (Resquest For Comment) 1889 y en el 1890 para emisiones específicas de audio y vídeo (véase Tabla 1). Las cabeceras de este protocolo contienen la información necesaria para sincronizar la imagen y el vídeo y determinar si se han perdido paquetes o han llegado fuera de orden. Además, especifican el tipo de emisión, por lo que permiten diferentes tipos de compresión de los datos. Al establecer una sesión bajo RTP, la aplicación define un par de direcciones de destino: además de la dirección de la red, un par de puertos para el RTP y RCP. En una sesión multimedia, cada medio es llevado a través de una sesión RTP por separado, con sus propios paquetes RTCP informando de la calidad de recepción en ese momento. Por ejemplo en una emisión multimedia, el audio y el vídeo pueden viajar por separado (en sesiones RTP distintas), permitiendo al receptor seleccionar qué es lo que quiere recibir.
Las propias asambleas del IETF han servido para poner a prueba estos desarrollos, como ha sido el caso en la que se aprobaba el estándar del RTP. Todos los miembros repartidos a lo largo del mundo enviaban paquetes de audio de 20 ms. de duración. Cada paquete de audio estaba precedido por una cabecera RTP y todo ello era puesto en un paquete UDP. La cabecera RTP indica el tipo de codificación de audio que ha sido usado, por ejemplo PCM. Los usuarios podían elegir cambiar la codificación durante la conferencia en función de la congestión que tuviera la Red en esos momentos, o para adaptar la emisión a los diferentes anchos de banda de cada participante. El protocolo RTP no ofrece ningún tipo de mecanismo para asegurar la entrega continua u ofrecer una garantía de calidad de servicio. No garantiza la entrega de paq

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información