Servidor de VideoStreaming

El servidor de “video streaming” es el encargado de distribuir el servicio. Existen una gran variedad de servidores de “video streaming”, cada uno de ellos con sus ventajas e inconvenientes, destacamos algunos de los principales servidores de “video streaming”:

• ffmpeg server • icecast

• vlc server

• Darwin Streaming Server

Nuestro servidor de “videostreaming” va a ser “Darwin Streaming Server” de Apple, en realidad este servidor es la versión opensource del “Quicktime Streaming Server”,

totalmente cerrado y con costes de licencias, no obstante si bien es cierto que la versión comercial del servidor de Apple es más funcional la versión opensource resuelve

correctamente nuestros requisitos. En las próximas secciones daremos una visión global a las posibilidades de este servidor, de ahora en adelante “DSS”.

4.17.1. Que es el “streaming”?

“Streaming” es el concepto de entrega de contenido media desde un servidor a un cliente en tiempo real, desde tasas de módem a gran anchos de banda. En ningún momento existe una descarga de ficheros, el contenido de video, audio o media en general es reproducido directamente en el cliente, por algún cliente “videostreaming”, a medida que el contenido es entregado.

El servidor de “streaming” transmite “streams” de video y audio a individuos en

respuesta a las consultas de tales individuos que utilizan alguna aplicación cliente como mp4player, mplayer, quicktimeplayer, etc. Las consultas son gestionadas utilizando el protocolo “RTSP” (Real-Time Streaming Protocol), un protocolo para controlar un “stream” de contenido multimedia en tiempo real. Los “streams” son enviados utilizando el

protocolo “RTP” (Real-Time Protocol), un protocolo utilizado para transmitir contenido multimedia a través de las redes. Un servidor de “streaming” puede crear “streams” desde películas almacenadas en su propio disco. También puede enviar copias de cualquier “stream” “en vivo” a quien tenga acceso para ello.

4.17.2. Entrega “en vivo” frente entrega “bajo demanda”

Las opciones “streaming” multimedia están divididas en dos categorías: “en vivo” y “bajo demanda”. Mediante el servidor DSS pueden servirse cualquiera de las dos opciones.

Los eventos reales tales como conciertos, discursos y lecturas son frecuentemente convertidos a algún tipo de “stream” y enviados o distribuidos a través de Internet, todo ello en tiempo rea, es decir, a medida que sucede el evento real es capturada toda información de audio o video y enviada por la red, utilizando alguna herramienta “software” de difusión. La herramienta “software” de difusión codifica la fuente de

información, tal como una video cámara, en tiempo real y entrega el “stream” resultante al servidor. Es entonces cuando el servidor sirve, o “refleja”, el “stream” a los clientes.

A pesar de todo cuento los clientes diferentes se conectan al “stream”, cada uno ve el mismo punto al mismo tiempo. Esta experiencia “en vivo” puede ser simulada con

contenidos previamente grabados y almacenados en algún medio físico, como un fichero, un disco compacto e incluso creando listas de reproducción en el servidor.

Para una entrega “bajo demanda”, tal como un película a un fichero, cada cliente inicia el “stream” desde el principio, por ello ningún cliente empezará en un punto diferente respecto a los otros clientes. En este caso de entrega “bajo demanda” no es necesario ningún herramienta de difusión.

Configuración para entrega “en vivo”

La imagen siguiente muestra el esquema de una configuración de “streaming” de audio o video. Una cámara es utilizada como fuente de datos, dicha cámara se y los datos son codificados y difundidos hacia un servidor de “streaming”.

Imagen 57. Entrega en vivo

4.17.3. “Unicast” contra “Multicast”

Con el servidor DSS podemos realizar un transporte de red unicast o multicast para la entrega de cualquier tipo de contenido media.

En una entrega multicast, un único “stream” es compartido con todos los clientes. Cada cliente “sintoniza” con el “stream” del mismo modo que una radio sintoniza con la

radiodifusión FM. Aunque este técnica reduce considerablemente la congestión de red, requiere de una red que tenga acceso a este tipo de servicio, multicast.

Imagen 58. Configuración Multicast

En un entorno unicast, cada cliente inicia su propio “stream”, resultando en la

generación de muchas conexiones “uno-a-uno” entre el servidor y el cliente. Si existen muchos clientes concurrentemente conectados puede resultar en una gran congestión de red. No obstante este técnica es la más realizable para entrega a través de Internet, pues no depende de un transporte especial como es el caso del transporte “multicast”.

4.17.4. Modo “relay”

DSS puede ser configurado en modo relay. Un relay escucha los “stream” de entrada y entonces los reenvía a una o mas destinaciones. Un relay puede reducir el consumo de ancho de banda de una red. Los relays pueden ser útiles especialmente en situaciones “broadcast”, especialmente si muchos clientes en diferentes localizaciones quieren acceder al mismo contenido. En la siguiente figura podemos ver un ejemplo de

configuración utilizando una fuente, relays, servidores de “streaming” y finalmente los clientes que están ubicados en distintas localizaciones.

Imagen 60. Configuración Relay

4.17.5. Conclusiones

En definitiva podemos ver como la solución DSS puede llegar a ser muy versátil,

configuración como servidor, relay y además Apple también dispone de un servidor proxy de “streaming”, también opensource.

No entraremos en detalle en la configuración del DSS, puesto que la documentación de Apple es muy clara, solamente comentar que a excepción de querer crear listas de

reproducción, la publicación de un contenido por parte del servidor, es tan sencillo como copiar, o realizar un enlace simbólico en el sistema de ficharos hacia el directorio en el que el servidor publica los contenidos, habitualmente “/usr/local/movies”. Es decir, si quisiéramos publicar un determinado contenido, bastará con crear un enlace a “/usr/local/ movies/nombrecontenido” o copiarlo directamente.

Cuando un cliente ataque al servidor utilizará una “URL” tal que:

rtsp://@IP/ruta_al_contenido/nombre_contenido

La “ruta_al_contenido” es directamente el árbol de ficheros que existe por debajo de “/usr/local/movies”. Por tanto fijémonos que la gestión de los contenidos que deben ser

publicados es increíblemente fácil y muy factible de ser gestionado mediante “scripting”. De hecho esta solución no la presentan la mayoría de los servidores de “streaming”, esta ha sido una de las principales razones en la elección del DSS.

DSS además permite un control de usuarios al mismo modo que apache, mediante un fichero en el que se define que usuarios y grupos pueden acceder a los contenidos. Debe existir un único fichero por directorio, así, todo contenido que se halle en el directorio estará sujeto a las directrices del control de usuarios y grupos en el momento de ser publicados.