enginy@eps Curs 2007/2008 Streaming de Audio/Video. Protocolo RTSP David Mateos Costilla, Samuel Reaño Montoro Serveis Telemàtics Resumen— Este artículo pretende hacer un resumen de las tecnologías existentes para la difusión de contenidos multimedia a través de internet, centrándose en el protocolo de transmisión RTSP. I. INTRODUCCIÓN “Streaming” es un vocablo de procedencia inglesa que significa, literalmente, manar. No obstante su acepción más popular hoy en día es seguramente la que hace referencia a la técnica asociada a la reproducción de información audiovisual en tiempo real Se utiliza para minimizar el tiempo de espera en la transferencia de un archivo multimedia desde una red, normalmente internet. Permite ver y escuchar los archivos mientras se hace la transferencia sin que sea necesaria la descarga completa del archivo. II. RECORRIDO HISTÓRICO En la década de los '90 al avance imparable de la potencia de cálculo, tal y como predijera en 1965 Gordon E. Moore en su famosa ley [1], se le unió la enorme expansión que experimentó internet en aquella época. En estos años se empezó a barajar la posibilidad de compartir contenidos multimedia en tiempo real a través de la red de redes. El problema era que la información era demasiado pesada y las conexiones de la época demasiado lentas para este tipo de aplicación. En 1992 el Motion Pictures Experts Group (MPEG) aprueba un algoritmo de compresión de audio llamado a transformar el modelo de distribución musical para siempre. Se trataba del estándar MPEG1 Audio Layer 3, conocido popularmente como MP3 [2], que permitía unas tasas de compresión de, aproximadamente 1:10 en relación al audio digital PCM sin procesar, manteniendo una calidad de sonido suficientemente fidedigna al original. Esta sensible disminución de la cantidad de información a transmitir y el progresivo aumento en el ancho de banda de las conexiones a internet dio lugar a la aparición de las primeras redes de intercambio de ficheros multimedia mediante protocolos “Peer To Peer” o P2P, entre las que podemos destacar por su popularidad, la red Napster. Cuestiones éticas a parte, la popularización masiva del intercambio de contenidos multimedia a través de la red hizo que mucha gente se diera cuenta del potencial de las nuevas telecomunicaciones en combinación con estos nuevos y potentes algoritmos de compresión. La posibilidad de ofrecer video y audio en tiempo real a cualquier punto del planeta a través de internet ya no parecía imposible y gigantes multinacionales como Microsoft, Real o Apple empiezan a desarrollar sus primeros protocolos de streaming. III. PROTOCOLOS DE TRANSPORTE EN TIEMPO REAL A. RTP (Real-Time Transport Protocol) Protocolo de transporte en tiempo real que conduce la entrega de paquetes coordinada por RTSP y RTCP. Se basa en el envío 'poco fiable', es decir de mejor esfuerzo, en tiempo real de datos sobre UDP. Este protocolo se suele usar conjuntamente con RTSP para las tareas de control del flujo de datos mediante sesiones. En contra de lo que su nombre pueda sugerir, la utilización del protocolo RTP no asegura que la transmisión sea en tiempo real, pero sí que aumenta la sincronización y el control sobre los contenidos en tiempo real (audio y/o video). Es decir, se puede enviar el audio y el video por “flujos” separados y mediante este protocolo, sincronizarlos posteriormente en el destino. B. RTCP (Real-Time Transport Control Protocol) Protocolo de control de transporte en tiempo real que se encarga de tareas de comunicación e información para el correcto control del flujo de datos de RTP. Los paquetes de este protocolo no transportan datos multimedia, sino que trabaja con RTP en el transporte y empaquetado de los datos. Se usa para transmitir los parámetros de una sesión multimedia, y su función principal es informar a cerca de la calidad del servicio (QoS). Durante una sesión, RTCP transmite periódicamente paquetes de control a todos los participantes de la misma para controlar el estado de la conexión en todo momento. C. RTSP (Real Time Streaming Protocol)[3] Protocolo de flujo de datos en tiempo real no orientado a conexión que se utiliza para definir cómo se hará el envío de información entre el cliente y el servidor. Este protocolo trabaja a nivel de aplicación y controla que la entrega de datos se realice correctamente, pues el tipo de contenido con el que se trabaja normalmente al hacer streaming es muy sensible a la sincronía temporal (o a la falta de ella). Así pues se podría considerar que el RTSP actúa como si de una especie de mando a distancia de red para servidores multimedia se tratase. RTSP define diferentes tipos de conexión y diferentes conjuntos de requisitos, para intentar conseguir siempre un envío de flujo de datos a través de redes IP lo más eficiente posible. Además establece y controla uno o más flujos sincronizados de datos como audio y video. A tal fin se definió el uso de sesiones, mediante identificador único, en este protocolo. Es independiente del protocolo de transporte y puede funcionar tanto sobre UDP, RDP o TCP. Durante una sesión, un cliente puede abrir y cerrar conexiones fiables de transporte con el servidor mediante peticiones RTSP. Los flujos controlados por RTSP pueden usar RTP como hemos visto, pero el modo de operación de RTSP es independiente del mecanismo de transporte usado para 15 enginy@eps transmitir el continuo flujo de datos. Sin embargo, en la mayoría de casos se utiliza TCP para el control del reproductor y UDP para la transmisión de datos con RTP. D. Propiedades del protocolo • Extensible: nuevos métodos y parámetros pueden ser añadidos a RTSP fácilmente. • Seguro: RTSP usa los mecanismos de seguridad de la web, cualquiera a nivel de transporte. Se pueden aplicar directamente los mecanismos de autentificación de http. • Capacidad multi-servidor: Cada flujo de contenido perteneciente a una misma presentación puede residir en diferentes servidores. • Separación del control del stream y la iniciación de la conferencia: El control de stream no tiene nada que ver con las invitaciones de conferencia a un servidor. En particular para estos casos se suele usar SIP. • Neutral respecto de la descripción de las presentaciones: no impone ninguna descripción particular o formato concreto de metafile. • Muy similar a http: cuando es posible RTSP reutiliza los conceptos de http, por lo cual puede usar la infraestructura ya establecida. • Capacidad de negociación: si las características básicas están desactivadas, hay un mecanismo para que el cliente pueda determinar qué métodos van a ser implementados. Esto permite a los clientes usar la interfaz más apropiada. E. Operaciones soportadas • Proporcionar contenidos multimedia desde un servidor dedicado: El cliente puede pedir una descripción de la presentación vía HTTP o cualquier otro método. Si la presentación está en multicast [4], la descripción de la presentación contiene la dirección de multicast y los puertos que se deben usar para la recepción de media. Si por el contrario la presentación es enviada solamente de forma unicast[5], el cliente proporcionará el destino por razones de seguridad. • Invitación de un servidor de streaming a una conferencia: Un servidor de streaming puede ser invitado a unirse a una conferencia ya existente, para reproducirla en una presentación. Este modo es muy útil para la distribución de aplicaciones educacionales. • Añadido de contenido multimedia a una presentación existente: Particularmente para presentaciones en vivo, es muy útil si el servidor puede avisar al cliente sobre los nuevos contenidos adicionales disponibles. F. Peticiones RTSP • OPTIONS: Esta petición puede ser enviada en cualquier momento y no influye en el estado de la sesión. Es utilizada en el inicio, para establecer la sesión con los parámetros necesarios, como el número que se nos asigna y cierta información del servidor como la versión o los métodos soportados. También se utiliza, por ejemplo, cuando un usuario pretende realizar una petición no estándar. 16 Curs 2007/2008 DESCRIBE: Se encarga de inicializar la sesión. Obtiene una descripción del objeto requerido, principalmente el flujo necesario para la correcta reproducción. • SETUP: Especificará los parámetros de transporte tales como el protocolo a utilizar, el puerto de recepción o el puerto para los paquetes RTCP. • PLAY: Indica al servidor cuando debe comenzar el envío de datos, con los parámetros especificados en el SETUP. El cliente nunca deberá enviar una petición PLAY sin antes haber recibido una confirmación SETUP. • PAUSE: Detiene temporalmente el flujo de datos. • TEARDOWN: Petición para detener completamente el flujo de datos y liberar los recursos asociados. • GET_PARAMETER: Como su propio nombre indica, sirve para recuperar el valor de algún parámetro de la presentación en curso. • SET_PARAMETER: Análogamente a la anterior petición, sirve para establecer el valor de un parámetro de la presentación en curso. • REDIRECT: Petición que informa al cliente de que debe conectar a otra dirección de servidor. En una sesión RTSP común los intercambios que se producen son los siguientes: el cliente envía una petición RTSP, con formato HTTP al servidor del streaming. Cuando se establece la conexión con el mismo, normalmente vía TCP, se manda una petición OPTIONS pidiendo los datos al servidor para configurar una sesión. Una vez hecho esto, el cliente está preparado para pedir mediante un DESCRIBE una descripción de la presentación concreta a reproducir, a la cual el servidor responde con todos los valores de inicialización necesarios para dicha presentación. La siguiente petición será un SETUP para cada flujo de datos que se quiera reproducir, obteniendo los protocolos aceptados para el transporte. Con todos los datos conocidos ya podemos pedir mediante un PLAY que comience el envío de los datos por parte del servidor. Durante la sesión el servidor y el cliente intercambian periódicamente mensajes de PING mediante SET_PARAMETER. Al detener o terminar el flujo de datos el cliente envía las estadísticas de la sesión también con SET_PARAMETER. Habiendo concluido el streaming el cliente envía un TEARDOWN para liberar definitivamente los recursos. • TABLA I PETICIONES RTSP. DIRECCIÓN DEL TRÁFICO Petición DESCRIBE GET_PARAMETER OPTIONS PAUSE PING PLAY REDIRECT SETUP SET_PARAMETER TEARDOWN Dirección C&S C&S, S&C C&S, S&C C&S C&S, S&C C&S S&C C&S C&S, S&C C&S enginy@eps Curs 2007/2008 IV. TENDENCIAS ACTUALES Actualmente el streaming de vídeo y audio es una de las aplicaciones más populares de la red. Hoy en día cualquier particular puede retransmitir audio y/o video, almacenado o en vivo, a través de la red. Esta posibilidad también es aprovechada, por supuesto, por emisoras de radio y televisión "tradicionales". No obstante, y a pesar del potencial del streaming en tiempo real, una de las mayores revoluciones experimentadas en internet tiene que ver con la creación y almacenamiento on-line de estos contenidos multimedia. La llamada Web 2.0 permite a los usuarios compartir sus propios contenidos con los demás internautas. Populares portales como YouTube o Metacafe son, con toda seguridad, de las webs que más tráfico atraen diariamente en todo el mundo. Este tipo de portales y otras webs que puedan hacer del streaming de contenidos multimedia almacenados su reclamo, generalmente ya no utilizan la tecnología RTSP que ha quedado relegada casi exclusivamente para aplicaciones de retransmisión en riguroso tiempo real. Actualmente la tendencia es utilizar la tecnología Flash de Adobe. A. Streaming Flash Movies La mencionada tecnología Adobe Flash nos proporciona dos modos de hacer streaming: • “Streaming verdadero”, que no es más que un protocolo similar al RTSP pero propietario. Esto unido al hecho de que no ofrece grandes ventajas sobre el “tradicional” RTSP y que solo se puede emplear con la herramienta de pago Flash Communication Server (FCS) hace que esta modalidad no sea muy popular. • “Progressive Download” o Descarga Progresiva. Es la técnica más utilizada de las dos, ya que no necesita ningún tipo de soporte especial del servidor y su uso es gratuito. 1) ¿Cómo funciona? Para la difusión mediante streaming de contenido multimedia por el método de descarga progresiva se necesitan dos ficheros: • Una pequeña película Flash (con extensión .swf) que simplemente será el marco donde se visualizará la información transferida y los controles para interactuar con la reproducción. • El vídeo y/o el audio a transmitir codificado en un fichero con extensión .flv. Este archivo admite diferentes códecs de compresión de audio/vídeo, permitiendo un amplio abanico de calidades para adecuarse a las diferentes velocidades de conexión. Como se ha mencionado anteriormente el método “Progressive Download” es el método más utilizado de los dos que nos ofrece la tecnología Adobe Flash, aunque no es realmente streaming. La descarga progresiva funciona creando un buffer en el cliente y a medida que se va haciendo el volcado de datos al mismo, se va reproduciendo el contenido ya almacenado. 2) Pros • Para utilizar esta tecnología no es necesario ningún soporte especial del servidor. El único requisito es • • • • que el cliente tenga instalado el plug-in adecuado en su navegador web. Las “descargas progresivas” se transmiten utilizando el protocolo HTTP que garantiza el correcto envío de todos los paquetes y, por tanto, asegura la retransmisión de la película entera sean cuales sean las condiciones de la red. El hecho de ser tráfico web estándar nos evita que el firewall (si lo tuviera) del cliente nos pueda bloquear el streaming. Además ya que, a mayor o menor velocidad, se tiene que terminar por descargar todo el contenido, podemos estar seguros de que todos los clientes disfrutaran de la misma calidad de reproducción, independientemente de la velocidad de su conexión a internet. Esta última característica nos permite utilizar algoritmos de compresión con mayor calidad que los que usaríamos en el caso de streaming “tradicional”. 3) Contras Las principales pegas que se le pueden achacar a este tipo de difusión vienen de la necesidad de descargar el contenido entero a la memoria caché del cliente. • La cantidad de memoria que se tiene que reservar en el cliente para el buffer tiene que ser igual a la del contenido a reproducir. • Para asegurar una reproducción sin cortes se necesita un tiempo de predescarga que será mayor cuanto mayor sea el contenido a reproducir. • No se puede adelantar la película hasta el punto que nos interese mientras no se haya descargado al buffer, todo el contenido anterior a ese punto. • Todos estos motivos hacen de ésta una solución poco práctica para la reproducción de contenidos de larga duración, siendo solamente atractiva para clips de audio o de video de corta duración, como trailers de películas, spots publicitarios, etc. B. Streaming FLV mediante PHP La solución a buena parte de estas trabas llegó en 2005 por parte de un grupo de usuarios insatisfechos con todas las soluciones de streaming existentes hasta la fecha y que querían alcanzar una solución satisfactoria antes de que las grandes multinacionales del sector “impusieran” una solución de código propietario [6]. El proceso se basa en una idea muy sencilla. Consiste en una descarga progresiva de una película Flash con extensión .flv, igual que hemos explicado antes, pero fragmentando la información con marcas temporales e introduciendo fotogramas clave en la película. Un script PHP se encargará de la comunicación entre cliente y servidor. Dicho script además se encargará de gestionar la tasa de transferencia en tiempo real. Por ejemplo, aunque el buffer en principio bastaría que fuese tan grande como el mayor fragmento que haya entre fotogramas clave, si nos “sobrara” ancho de banda y memoria caché, se podría crear un segundo buffer donde ir almacenando los siguientes fragmentos de película por si para entonces las condiciones de la red no nos son tan favorables. 17 enginy@eps Curs 2007/2008 Esta solución también nos permite adelantar contenidos. Al hacer click en un punto posterior de la película se ejecutará una función que demandará al servidor la marca temporal que está reclamando el cliente en el reproductor de su navegador. Desde ese momento el servidor enviará al buffer del cliente información solo a partir del fotograma clave más cercano al solicitado, evitando así que se tenga que descargar toda la película hasta ese punto. Esta solución, aunque sigue sin ser auténtico streaming, sí que consigue acercarse mucho, conservando además todas las ventajas de la descarga progresiva. Así pues, no es de extrañar que se haya popularizado tanto el streaming de ficheros flash mediante script PHP, hasta el punto de que el RTSP hoy en día ha quedado relegado casi exclusivamente a aplicaciones auténticamente en tiempo real, como televisiones o radios por internet. Actualmente esta tecnología está registrada bajo una licencia Creative Commons (Reconocimiento 2.0 Inglaterra y País de Gales) [7] por Stefan Richter. C. Comparativa A modo de resumen adjuntamos dos tablas [8] en las que se comparan las características y aplicaciones de cada uno de los métodos de streaming vistos en este apartado IV. REFERENCIAS [1] [2] [3] [4] [5] [6] [7] [8] Entrada en la wikipedia castellana sobre la Ley de Moore: http://es.wikipedia.org/wiki/Ley_de_Moore Historia del formato mp3 disponible en: http://www.pcdoctor.com.mx/Radio%20Formula/temas/Historia%20de l%20MP3.htm Real Time Streaming Protocol Internet-Draft. Internet Engineering Task Force (IETF). Disponible en: http://ietfreport.isoc.org/allids/draftietf-mmusic-rfc2326bis-03.pdf Entrada en la wikipedia inglesa sobre el multicasting: http://en.wikipedia.org/wiki/Multicast Definición de unicast en la wikipedia inglesa: http://en.wikipedia.org/wiki/Unicast Sitio web donde se originó el streaming de ficheros .flv con código PHP: http://www.flashcomguru.com/index.cfm/2005/11/2/Streamingflvvideo-via-PHP-take-two Licencia Creative Commons 2.0 Reconocimiento 2.0 Inglaterra y País de Gales, en castellano: http://creativecommons.org/licenses/by/2.0/uk/deed.es Tablas extraídas y traducidas de la web: http://www.richmediaproject.com/ Asignatura impartida por: Magdalena Payeras Capellà Nombre: Samuel Reaño Montoro. samuel.r.montoro@gmail.com Titulación: Ingeniería Técnica de Telecomunicaciones, especialidad Telemática. TABLA III APLICACIONES ADECUADAS PARA CADA TIPO DE STREAMING Tipo de Aplicación Retransmisión en directo WebTV E-Learning Presentación on-line Trailers de películas Otros clips de corta duración Streaming Descarga Progresiva PHP Streaming X X X X X X X X X X X TABLA II CARACTERÍSTICAS DE LOS DISTINTITOS MÉTODOS MENCIONADOS Características Retransmisión en tiempo real Clips de larga duración Acceso inmediato a diferentes puntos de una película Descarga la película entera Descarga la parte de la película que sea necesaria El FLV se guarda en caché del cliente Necesita un servidor especializado para streaming Necesita un servidor web con PHP Puede ser parado por Firewalls Reproducción de alta calidad con cualquier conexión Retransmite paquetes perdidos 18 Streaming Descarga Progresiva PHP Streaming X X X X X X X X X X X X X X Nombre: David Mateos Costilla. david.ptm56@gmail.com Titulación: Ingeniería Técnica de Telecomunicaciones, especialidad Telemática. Asignatura impartida por: Magdalena Payeras Capellà