PLATAFORMA DE STREAMING

REALNETWORKS

Suleima AristizabalLuis Zapata

ProfesorEdwin Montoya

Sistemas y Aplicaciones Multimedia

UNIVERSIDAD EAFITESPECIALIZACION EN TELEINFORMATICA

Noviembre de 2006

TABLA DE CONTENIDO

1. Instalación Arquitectura ............................................................................................41.1 Instalación Plataforma RealNetWorks...............................................................41.2 Instalación RealProducer ................................................................................111.3 Instalación RealPlayer.....................................................................................13

2. Opciones y Configuraciones del Codificador.............................................................162.1 Codificación de Fuentes Vivas Hacia el Servidor.............................................162.2 Codificación de Fuentes Vivas Hacia Archivos.................................................212.3 Codificación Desde Arvhivos Hacia un Servidor..............................................232.4 Conversión de Formatos.................................................................................262.5 Otras Opciones Particulares del Codificador...................................................31

3. Opciones y Configuraciones del Servidor de Streaming...........................................323.1 Video On Demand...........................................................................................323.2 Broadcast-Unicast de Fuentes Vivas...............................................................363.3 Broadcast-Unicast de Fuentes Almacenadas...................................................383.4 Broadcast-Multicast de Fuentes Almacenadas................................................423.5 Broadcast-Multicast de Fuentes Vivas ............................................................483.6 Otras Opciones Particulares del Servidor .......................................................51

3.6.1 Server Setup ...............................................................................................513.6.2 Security ......................................................................................................543.6.3 Monitoreo de Conexiones y Consumo de Recursos .....................................563.6.4 Splitting .....................................................................................................583.6.5 Surestream-Aware Splitting ........................................................................613.6.6 SLTA ...........................................................................................................62

4. Opciones y Configuraciones del Reproductor...........................................................714.1 Estadísticas Obtenidas con Diferentes Tasas de Transmisión ........................71

5. CONCLUSIONES .......................................................................................................826. BIBLIOGRAFIA ..........................................................................................................83

INTRODUCCION

Un sistema streaming esta constituido básicamente por tres componentes: el servidor, la red de transmisión y los usuarios del sistema.

EL SERVIDOR esta encargado de gestionar los servicios a los clientes, almacenar los contenidos que pueden ser solicitados por los mismos y garantizar la calidad del servicio desde la fuente hasta el destino. Este servidor a su vez esta compuesto por subsistemas, a saber:

Subsistema de control: Encargado de recibir las peticiones de los usuarios y ordenar las acciones necesarias para poder atender estas solicitudes, incluyendo la decisión de servir el requerimiento de acuerdo a los recursos disponibles y a las necesidades de la nueva petición, sin que afecte las peticiones en curso. Este modulo además se encarga de generar y gestionar las estadísticas de utilización, la contabilidad y facturación del servicio y la optimización para mejorar la eficiencia del sistema.

Subsistema de almacenamiento: este se encarga de almacenar el contenido multimedia y recuperar esta de los dispositivos de almacenamiento para prestar el servicio a una solicitud determinada.

Subsistema de comunicación: Este modulo se encarga de gestionar las políticas de servicio y planificar la entrega de contenidos a la red de tal manera que optimice los recursos de la red de transmisión y del servidor mismo.

RED DE COMUNICACIONESPara permitir a los usuarios acceder a contenidos multimedia las redes deben disponer de los mecanismos de transporte que permitan el envió de datos y peticiones, además de ofrecer calidad de servicio que permita la transmisión de información dentro de niveles mínimos de rendimiento.Para cumplir estos requisitos la red para un sistema streaming debe contar con un gran ancho de banda y velocidad de transmisión.

CLIENTES La interface entre el sistema streaming y el cliente se realiza a través de un player, este esta encargado de recibir las ordenes del usuario (pausar, adelantar, retroceder, etc) y enviar las señales al servidor. Otra de las funciones principales del placer es almacenar los contenidos recibidos, decodificar estos y enviarlos a la interface de visualización

CARACTERISTICAS

El servidor Helix puede entregar flujos de eventos de video sobre demanda y vivos en mas formatos de medios que cualquier otro servidor de medios, dependiendo de la licencia, el servidor puede entregar los siguientes tipos de formatos:

Real Networks: RealAudio (.rm, .ra), RealVideo (.rm, .rmvb), RealPix (.rp),RealText (.rt), Multi-Rate Container (.mrc)Macromedia: Flash (.swf)Microsoft: Windows Media (.asf, .wma, .wmv)Apple: QuickTime (.mov)Standards-Based: MPEG-4, MP3Image Formats: GIF (.gif), JPEG (.jpg, jpeg), PNG (.png)

Other: AU (.au), AIFF (.aif, .ief), WAV (.wav)

1. Instalación Arquitectura

1.1. Instalación Plataforma RealNetWorks

Una vez ejecutado el instalador del Helix Server (helix-server-retail-11.02-win32-setup), aparece la siguiente ventana de Bienvenida:

Tras presionar el botón Next aparecerá la siguiente ventana:

En la venta de diábolo anterior se ubica y selecciona el archivo que contiene la licencia, la cual para nuestro se encuentra en la misma carpeta de donde fue ejecutado el Helix Server (RNKey-Helix_Server_Unlimited-110-8138443213125934), es importante resaltar que sin la licencia adecuada no se habilitarán las opciones para la distribución de medios broadcast multicast.

Las siguientes dos ventanas de diábolo permiten aceptar los términos de licenciamiento y la carpeta de instalación del Helix Server, luego se visualizará una nueva pantalla en la cual se debe ingresar un nombre de usuario y una contraseña para administrar el servidor una vez instalado. La administración se realiza mediante una interfaz Web. Evidentemente, es necesario recordar el nombre de usuario y la contraseña ingresada, pues de olvidarse, será necesario reinstalar el servidor. Se recomienda utilizar una contraseña que no se utilice para nada más, pues por defecto aparece en texto plano en el fichero de configuración del servidor.

Creación de la cuenta de usuario para administración del servidor

Las siguientes ventanas de diálogos piden los puertos para las conexiones que utilicen el protocolo RTSP (554 por defecto), el protocolo HTTP (puerto 80 por defecto), el protocolo MMS (puerto 1755 por defecto). Si alguno de estos puertos estuviese reservado por algún otro programa, deberán ser cambiados, aunque el instalador no advirtiese el problema, al ejecutar el servidor de streaming este finalizará con un mensaje de error. Posteriormente, se muestra un diálogo en el que se pide el puerto en el que residirá la página Web de administración del servidor. Este puerto es elegido de forma aleatoria en cada instalación para hacer más difícil accesos no deseados al servicio de administración.

La siguiente tabla muestra los puertos recomendados.

El penúltimo diálogo ofrece la posibilidad de instalar el servidor como un servicio de Windows, lo cual es altamente recomendable. Finalmente, aparece un diálogo con un resumen de la información introducida a lo largo del proceso de instalación:

Una vez finalizada la instalación, el servidor puede ser ejecutado de dos formas: mediante el icono Helix Server creado en el escritorio (con copia en Inicio /Programas/Helix Server) ó mediante la consola de gestión de servicios de Windows. En el primer caso, al ejecutar el servidor aparece una ventana de Símbolo del Sistema en la que se ejecuta Helix Server. Para parar el servidor, bastará con cerrar la ventana (Ejecución de Helix Server como un programa de usuario)

Evidentemente, esta forma de ejecutar el servidor implica que haya que entrar en sesión cada vez que se desee ejecutar. Esto evita que el servidor, por ejemplo, sea arrancado automáticamente ante un reinicio del sistema. Para esto existe la segunda

posibilidad comentada antes, la ejecución del servidor desde la consola de gestión de servicios de Windows como un Servicio Win32. Esta consola es accesible desde Inicio/Programas/Herramientas Administrativas. Una vez allí, debe seleccionarse la consola Servicios.

a.) Ejecución de Helix Server como un programa de usuario

Doble clic sobre el icono de Helix Server el cual se encuentra en el escritorio.

b.) Ejecución del servidor desde la consola de gestión de servicios de Windows como un Servicio Win32:

Haciendo doble clic se puede acceder a las distintas opciones para configuración de servicios que ofrece Windows. En primer lugar, se puede cambiar el tipo de inicio: por defecto, el servicio tiene un tipo de inicio Automático, que implica que el servicio se ejecuta al iniciarse el sistema operativo; si el tipo de inicio fuese Manual, habría que pulsar el botón Iniciar en las opciones del servicio cada vez que se desease ejecutarlo. En la Ilustración aparece una configuración con tipo de inicio Automático y con el servicio parado, al estar el servicio recién instalado. Para iniciarlo, basta con dar clic derecho y luego Iniciar ó reiniciar el sistema operativo.

Doble clic en Herramientas administrativas, la cual se encuentra en el panel de

Doble clic en Servicios.

Administración del Servidor

Para acceder a la interfaz de administración del servidor, es necesario acceder a la URI:

http://direccion:puerto_administración/admin/index.html .

Para nuestro caso accedemos desde el propio equipo en el cual se encuentra instalado el Helix Server:

http://127.0.0.1:22249/admin/index.html

Tras introducir el nombre de usuario y la contraseña, el aspecto de la página principal es el mostrado en la siguiente ilustración:

Página principal Web de administración del servidor

Las dos únicas acciones ejecutables directamente a partir de esta página son la recarga de la página (útil en caso de haber reiniciado el servidor desde la consola de servicios de Windows, o de haberse producido algún error a causa de la existencia de un Proxy web intermedio) y el reinicio del servidor. Ambas pueden llevarse a cabo mediante los dos botones que aparecen en la parte superior derecha de la página.

1.2. Instalación RealProducer

Tras descargar y ejecutar el instalador del RealProducer (realproducer_basic_11_windows_setup), aparece una serie de diálogos que permitirán instalar RealProducer Basic 11. Los dos primeros diálogos muestran al usuario el acuerdo de licencia y la elección de la carpeta de instalación por defecto. También permite crear un acceso directo de la aplicación en el escritorio (opción activada por defecto), añadir otro en la barra de inicio rápido (desactivado) y añadir a la variable de entorno PATH el directorio donde se encuentran las herramientas de línea de comandos de RealProducer 11 (opción activada por defecto y obligatoria para esta sesión de prácticas).

Pantalla principal de RealProducer Basic 11.

En ella destacan las siguientes zonas:

1. Visualización: muestra el audio y/o el vídeo de la entrada (izquierda) y de la salida (derecha). La zona de visualización de la salida mostrará la calidad con que se están produciendo los contenidos para el servidor.

2. Definición de la entrada: permite seleccionar el fichero de medios o los dispositivos hardware desde los que producir.

3. Definición de la salida: ofrece opciones para configurar la salida.

4. Gestor de trabajos: permite crear trabajos (tareas de producción de medios), gestionarlos y

controlar su resultado.

1.3. Instalación RealPlayer

Tras ejecutar el instalador del RealPlayer (RealPlayer10-5GOLD) se visualizará la siguiente ventana de Bienvenida:

Seleccione Accept para aceptar los términos de licencia; posteriormente se mostrará una nueva ventana en la cual se debe elegir la velocidad de conexión a Internet que se dispone ó el ancho de banda si la distribución del streaming se hace en una red LAN. Para nuestro caso seleccionamos Office LAN (10 Mbps and above).

Dependiendo de la velocidad ó ancho de banda elegido se podrá tener un mejor rendimiento y reproducción de los medios transmitidos.

Luego se presenta la carpeta donde quedará instalado el RealPlayer y la localización de los iconos de acceso directo.

En la siguiente pantalla se puede visualizar el inicio de la instalación del programa:

Finalmente seleccionamos finish para completar la instalación de RealPlayer.

2. Opciones y Configuraciones del Codificador

2.1. Codificación de Fuentes Vivas Hacia el Servidor

Helix Producer crea paquetes de datos streaming media por un proceso llamado "encoding." Durante la codificación, el medio fuente es transformado en un flujo de medio usando "codecs" (compression/decompression algorithms). El proceso se describe a continuación:

1. Helix Producer recibe el medio fuente como un archivo de audio o video, o fuente viva.

2. Helix Producer usa un codec para comprimir los datos del medio fuente en paquetes.

3. Los paquetes de datos son fluidos vía internet o una red hacia el usuario.4. En el usuario final, el mismo codec es usado para reconstruir el medio tal que

este pueda ser ejecutado.

La codificación de audio es mucho más simple que la codificación de video. Un streaming de audio básico, se crea usando un archivo de audio o fuente vivas de audio como la entrada. Helix Producer usa varios codecs de audio para convertir su audio estándar en un formato que puede ser streamed.

Una tarea más compleja para el Helix Producer es convertir video estándar en medio de streaming. Un RealVideo clip es creado convirtiendo una archivo de video o capturando de una fuente de video, tal como una cámara de video o videocasetera, al computador via una tarjeta capturadora de video. Helix Producer convierte diferentes atributos del video—tal como la rate de frames, tipo de movimiento, y tamaño de la imagen —en un RealVideo clip usando un codec de video. Además, si el video incluye datos de audio, deben también ser convertido usando codecs de audio.

Antes de que el Helix Producer pueda comprimir la entrada de datos de medio, este necesita saber algunas cosas acerca de la audiencia. Una audiencia es definida por la rata de bits a la cual ella puede conectarse. Por ejemplo, una persona que use una conexión dial-up por modem a 56 kbps para conectarse a su flujo, es un miembro de la audiencia MODEM 56K. Si se tiene una sola audiencia, entonces se usa una rata de bits única.

Como la compresión de datos pierde alguna información, la selección de la audiencia correcta es clave para decidir cuanto se mantiene de los datos de la fuente. Con la tecnología Helix Producer's SureStream se puede alcanzar una gran variedad de audiencias posibles, y proporcionar a todos los usuarios la mejor experiencia de escucha y visualización optimizado para su ancho de banda.

Al utilizar SureStream se puede crear un único clip de RealMedia grabado para múltiples audiencias, o se puede crear un clip que automáticamente se conmutara a un ancho de banda mas bajo en condiciones de red pobres. Los archivos SureStream RealMedia pueden combinar muchos streams diferentes.

Así, se puede grabar un video clip para audiencias 56 kbps, 112 kbps, y 256 kbps, y Real Player automáticamente usara el stream correcto basado en la velocidad de conexión del usuario. Todos los stream estarán contenidos en un único archivo RealMedia.

Para el ejemplo se utilizaron las fuentes vivas el micrófono y la cámara web

Se eligieron tres audiencias para utilizar la característica SureStream y el codec RealVideo10

Se configura el destino, en este caso es el servidor.

Se definieron parámetros básicos como el nombre y la dirección ip del servidor de streaming, el nombre del medio y el método de autenticación usuarios, el puerto por el cual se escucha en el servidor, el protocolo de transporte usado y el nombre y password del encoder (RealProducer o Helix Producer) que debe haberse registrado en la base de datos del servidor previamente, para que este admita sus streaming. Se explica mas adelante.

Dentro de la configuración avanzada se configuran parámetros que permiten la optimización del servicio de streaming, como:

2.2. Codificación de Fuentes Vivas Hacia un archivo

En el Real Producer se inicia el nuevo trabajo y se selecciona el ó los dispositivos fuentes, además de seleccionar los tipos de audiencias como en el numeral anterior, la diferencia entonces se encuentra en la selección del destino, en éste caso corresponde a un directorio y un nombre de archivo con la extensión adecuada al medio que se va a codificar tal como aparece en la figura:

Después de realizado el proceso de codificación anterior inmediatamente aparecerá en el directorio seleccionado el archivo correspondiente codificado con el nombre que se le haya dado.

2.3. Codificación desde un archivo hacia un servidor

En el real producer se inicia el nuevo trabajo y se selecciona el archivo fuente

Se puede observar que acepta múltiples formatos del medio fuente, en este caso se selecciono un archivo de tipo avi, con las siguientes características:

Luego se seleccionan las audiencias y el codec de video, en este caso se seleccionaron dos audiencias para aprovechar la característica SureStream y el codec RealVideo10.

Luego se configura el servidor de destino y las características como se describió en el numeral 2.1.

Luego de iniciado el proceso de codificación se puede observar desde el Server la información

2.4. Conversión de Formatos

La conversión de formatos es aquellas en la cual se transforma un archivo audiovisual que no es de formato Real Media a un formato que si lo es, ejemplo (.rm, .ra, .rv), además de codificarlo para distintas audiencias, para su posterior publicación. Para realizar la conversión de archivos se deben seguir los siguientes pasos:

2.4.1. Seleccionar la Fuente

El primer paso es seleccionar el archivo a convertir; se pueden convertir archivos de diferentes formatos (.avi, .wmv, .mov, .qt, .wav, .au, .mpeg, .mpg).

Seleccionar la Fuente de Contenidos Multimedia:

2.4.2. Seleccionar la Salida

Conjuntamente con esto se debe seleccionar el directorio de salida del archivo convertido. El programa, por defecto selecciona el directorio del programa.

2.4.3. Datos del Clip

Al seleccionar el botón Clip Information se debe introducir los datos acerca del Clip, es decir, la información que se mostrará posteriormente en el Real Player de los usuarios.

Los datos del Clip se mostrarán en el reproductor del cliente de manera informativa y pueden servir al usuario o reproductor, de referencia o información adicional a la hora de hacer la distribución de los medios. Los campos Description y Keywords se utilizan

para introducir una descripción textual del contenido del Clip y una lista de palabras claves para su localización en motores de búsqueda multimedia.

2.4.4. Seleccionar Audiencias

Tras pulsar el botón Audiences se debe indicar las diferentes tasas de transferencia a los que el archivo será codificado, ya que puede ser transmitido a distintas calidades dependiente de la arquitectura de la red. Además se puede seleccionar el tipo de audio y la calidad del video del archivo.

En la parte superior, además se encuentra la opción de ajuste del audio y video. Se dispone de cinco diferentes posibilidades de configuración de la calidad de audio y otras para video. La calidad tanto de audio y el video están basadas en un balanceo entre el consumo de ancho de banda para cada uno y otro. Por ejemplo, si se quiere retransmitir o crear un archivo para usuarios que poseen un MODEM de 56 Kbps, se dispone de un acho de banda limitada para hacerlo (lo normal es entre 34 y 37 Kbps). Por lo tanto, no será factible superar éste consumo en la creación del archivo o la retransmisión. Así, lo único que se puede hacer es balancear el gasto de ancho de banda que se tiene que asignar para el audio y el video. A más ancho de banda asignado para audio, menor calidad de video. Entonces, dependiendo del tipo de contenido que tenga el Clip que se elabore y de la necesidad de una mayor o peor calidad de sonido o audio se podrá ajustar ese balanceo. Las posibilidades para ajustar la carga de audio son:

Music: Pensado para ofrecer más calidad de audio que de video.

Voice (sólo voz): fue pensado para Clips que contengan sólo voz.

No Audio: como su nombre lo dice, es utilizado para crear Clips sin sonidos. De esta forma se da todo el acho de banda al video.

Con el video ocurre lo mismo y existen cinco posibles configuraciones que son:

Normal Motion Video: Diseñado para la mayoría de los Clips.

Sharpest Image: Se aplicará un realce de la imagen. Pensado para secuencias de poca luz que necesiten un ajuste del contraste.

Smoothest Motion: Aplicará un suavizado a la imagen para lograr una mayor claridad. Está pensado para videos con alto movimiento que necesitan ser suavizados.

Slide Show: Esta opción está pensada para mostrar imágenes estáticas en secuencia.

No Video: Es utilizado para indicarle al programa que se va a crear una secuencia con audio solamente.

Real Producer permite seleccionar el Codec de compresión de video a utilizar; el programa ofrece tres opciones que son: RealVideo 8, RealVideo 9, que mantiene la compatibilidad con las versiones anteriores del Player y RealVideo 10 con SVG (Scalable Video Technology) que ofrece ajustes automáticos del tiempo de muestreo de los fotogramas, tamaño del fotograma y perdida de paquetes, ofreciendo la máxima calidad a usuarios de la versión anterior del Player.

Codecs de Audio Codecs de Video

Codecs de compresión

Se pueden configurar otras opciones más del Codec:

2-pass encoding: Como su nombre lo indica, realiza dos pasadas, una de análisis y otra de codificación al origen de video para ajustar el Codec al máximo (ésta opción se deshabilita automáticamente en retransmisiones en Directo).

2.4.5. Opciones de Video: Real Producer incluye unos sencillos y eficaces filtros de video que permiten mejorar la calidad de las secuencias creadas:

En Video Noise Reduction (reducción del ruido en el video) se puede mejorar la calidad de las secuencias de la siguiente manera:

Low: Es la opción que se debe mantener siempre seleccionada por tratarse de la más adecuada. Significa que se aplicará un ajuste de niveles moderados al origen de video sin casi afectar la calidad. A no ser que el origen de video sea de excelente calidad o ya esté pre-procesado, se debe aplicar éste filtro.

High: Aplica una ajuste de niveles más severo y está indicado para retocar orígenes de video más defectuosos, con ruido u otros problemas.

Las otras dos opciones de filtrado disponible son:

Deinterlace Filter: Elimina artificialidades generadas en PAL ó NTSC. No es aplicable a videos menores de 240 píxeles o a videos entrelazados.

Inverser-Telecine: Está indicada para los casos en los cuales se codifica material a 30 fps y lo convierte a 25fps. Este filtro elimina los fotogramas redundantes.

2.4.6. Comienzo de la Codificación: Una vez configurado los parámetros anteriores

en la pantalla principal del programa, al pulsar el botón Encode comenzará la conversión.

2.5. Otras Opciones Particulares del Codificador

La intención de los creadores de SMIL al proponer esta nueva especificación ha sido la de cubrir un hueco existente en los lenguajes para Web definidos a través de XML: el de la presentación de elementos multimedia integrados en una misma página Web, ya que, si bien existen otras formas de presentación multimedia muy conocidas como Flash o HTML+Time, que permiten mostrar imagen, texto, texto en movimiento, música y vídeo sincronizados y distribuidos no sólo sobre el espacio, sino sobre el tiempo, SMIL ofrece una alternativa a estos lenguajes cuya ventaja principal radica en que la integración y asociación de los elementos multimedia se hace dentro del contexto de XML.

En el campo de la documentación hay que destacar los módulos SMIL referentes a metainformación y metadatos, y su capacidad de integración con  RDF y otros lenguajes derivados de XML, ya que SMIL no sólo es muy potente en el diseño y presentación de los documentos multimedia, sino también es una herramienta muy potente desde el punto de vista del contenido, para tratar y recuperar la información, debido a la integración natural de elementos fundamentales para el tratamiento de este tipo de documentos, tanto desde una perspectiva semántica, como puede ser el caso de los metadatos Dublin Core u otras propuestas de metadatos y modelos, como desde una perspectiva sintáctica como es el caso de RDF.

Los archivos .smi se abren con distintas aplicaciones como Real G2 Player Plus. Esta aplicación la soportan archivos de RealAudio, RealMedia, RealPix, RealText, etc. y está disponible como un plug-in en las versiones más recientes de los navegadores más conocidos como Internet Explorer y Netscape.

Los diferentes archivos multimedia (.Avi, .Mov, .Ppg, etc. se tienen que convertir al formato:. rm Real Media para archivos de vídeo. rp RealPix para archivos gráficos .rt RealText para archivos de texto.

El software para convertir estos archivos es el RealProducer G2 Authoring Kit que se puede descargar desde el sitio oficial de Real.

El funcionamiento es el siguiente: A través de un marcador análogo a <img src></img> del lenguaje HTML, incluiremos los archivos multimediales que preferiblemente tendrían que convertirse por lo que respecta a los archivos de vídeo en: (.rm Real Media), los archivos gráficos en: (.rp Real Pix) y las cadenas de texto a .rt (RealText).

Veamos un ejemplo:<body>

<par> <video src = "MiVídeo.rm" id = "Vídeo" region = "VideoChannel" title = "MiVídeo"/>

<img src = "MisImágenes.rp" id = "Headline Pix" region = "PixChannel" title = "MisImágenes"/>

<text src = "MiTexto.rt"

id = "Ticker" region = "TextChannel" title = "MiTexto"/>

</par>

</body> </smil>

Los marcadores <video src/> <img src/> <text src/> están comunicados con los archivos multimediales y su disposición está definida en la cabecera. De esta forma, a través del navegador tomarán forma las páginas HTML, mientras que a través de RealPlayer u otra aplicación, veremos y oiremos los archivos .smi.

Así pues, SMIL es una especificación del W3C basada en el lenguaje XML y que está destinada a permitir la integración y asociación de información en distintos formatos para el desarrollo de documentos multimedia. Se trata, pues, de un sublenguaje de XML.

3. Opciones y Configuraciones del Servidor

3.1. Video On Demand

Para ofrecer medios en Demanda es importante primero tener clips de audio y de video codificados disponibles en el punto de montaje del servidor Helix. Para hacer la codificación se realizaron los siguientes pasos.Utilizamos un CD de audioSe arranca el real producer y seleccionamos como fuente el dispositivo de reproducción de cd.

Se selecciono un nombre para el archivo de salida y el directorio para guardarse Ondemand1.ra directorio Archive

Luego este archivo se guerda en el punto de montaje del Helix Server para distribución on demand, por defecto este archivo esta ubicado en la ruta C:\Program Files\Real\Helix Server\ContentAunque pueden crearse otros puntos de montaje, para los cuales se guardara en la ruta apropiada.

Luego creamos una pagina web con el enlace al clip de audio, la cual será servida por el web server. Se uso el siguiente formato para el enlace:<a href="http://address:HTTPport/ramgen/ondemand1.ra">Click here</a>El puerto utilizado es el 81.

Luego desde el cliente a través del navegador ubicamos la página

Y al seleccionar el enlace se lanza automáticamente el realplayer y el medio.

3.2. Broadcast-Unicast de fuentes vivas

ProcedimientoSe inicia el RealProducer y se crea un Nuevo trabajo File>New JobSe seleccionan los dispositivos de entrada por Devices >Audio, se realiza la selección de la lista.Se configure el servidor de destino File>Add Destination Servera. El nombre del servidor de destino.b. El nombre del stream live.rm.c. La dirección Ip del servidor, en este caso 192.268.2.2d. El nombre User Name y Password que se tiene registrado en el servidor para la autenticación de encoders o en su defecto el mismo nombre y password que se usa para ingresar en el servidor como administrador.e. se inicia la codificación Encode button.

En el servidor se configurar en el transmisor la dirección ip del receptor y en el parámetro transporte se selecciona el protocolo de transporte y el modo unicast. (Los otros parámetros se explican mas detalladamente en la sección de multicast)

En la parte del receptor se configuran solamente unos pocos parámetros:El punto de montaje donde estarán temporalmente los contenidos a distribuir, La direccion ip del transmisor(en este caso la del servidor Helix),el rango de puertos por donde le llegara la información al receptor, el protocolo de transporte y el modo unicast.

En el cliente se accede al medio mediante un navegador donde se suministra la dirección ip del servidor de streaming, el puerto, el punto de montaje y el nombre del medio con la misma extensión con la cual se crea en el codificador.

3.2. Broadcast-Unicast de fuentes vivas

ProcedimientoSe inicia el RealProducer y se crea un Nuevo trabajo File>New JobSe seleccionan los dispositivos de entrada por Devices >Audio, se realiza la selección de la lista.Se configure el servidor de destino File>Add Destination Servera. El nombre del servidor de destino.b. El nombre del stream live.rm.c. La dirección Ip del servidor, en este caso 192.268.2.2d. El nombre User Name y Password que se tiene registrado en el servidor para la autenticación de encoders o en su defecto el mismo nombre y password que se usa para ingresar en el servidor como administrador.e. se inicia la codificación Encode button.

En el servidor se configurar en el transmisor la dirección ip del receptor y en el parámetro transporte se selecciona el protocolo de transporte y el modo unicast. (Los otros parámetros se explican mas detalladamente en la sección de multicast)

En la parte del receptor se configuran solamente unos pocos parámetros:El punto de montaje donde estarán temporalmente los contenidos a distribuir, La direccion ip del transmisor(en este caso la del servidor Helix),el rango de puertos por donde le llegara la información al receptor, el protocolo de transporte y el modo unicast.

En el cliente se accede al medio mediante un navegador donde se suministra la direccion ip del servidor de streaming, el puerto, el punto de montaje y el nombre del medio con la misma extensión con la cual se crea en el codificador.

3.3. Broadcast unicast fuentes almacenadas

Configuración de Real ProducerProcedimiento: Selección del archivo a codificar para transmitir

Configuración del servidor de destino, el nombre del medio codificado con la extensión rv, ra, rm según sea el caso de codificación de un archivo de video, archivo de audio, o múltiples fuentes.Se configuran los mismos parámetros explicados en secciones anteriores para transmitir al servidor de medios.

Se arranca la codificación.

Mientras se esta codificando el archivo broadcast desde fuentes almacenadas, en el servidor aparece un archivo temporal correspondiente a esta codificación, en el punto de montaje por defecto, en este caso es un subdirectorio de content llamado Archive, este se almacena debido a que el servidor se configuro de tal manera que se le habilito la opción de guardar los archivos de broadcast.

Mientras se hace la codificación en el cliente se puede reproducir el medio. Esto se puede conseguir de varias formas: A través de un navegador se da la dirección con los siguientes formatos:Rtsp://dirección ip del servidor de streaming:puerto/broadcast/nombre del medio.extensión correspondientehttp:// dirección ip del servidor de streaming/ramgen/broadcast/nombre del medio.extensión

En el primer formato se expresa explícitamente todos los parámetros necesarios para localización y reproducción del medio, indicando que la conexión se hará con el protocolo rtsp y el puerto a utilizar.

En el segundo formato la conexión se hace a través del protocolo http, pero al llegar la solicitud al servidor, al identificar este que es un contenido de broadcast cambia automáticamente al protocolo rtsp y la función ramgen hace que en el cliente se generen las acciones para lanzar el Player que permite la visualización del medio.

Al terminar la codificación en el Server en el mismo directorio Archive, aparecerá el archivo correspondiente al medio codificado que fue transmitido previamente.

3.4. Broadcast multicast Fuentes almacenadas

Se debe configurar previamente en el servidor de streaming los transmisores y receptores para multicast.

En los transmisores se deben configurar cada uno de los clientes multicast, para ello los parámetros son los siguientes:

El nombre del receptor: Se coloca un nombre con el cual el Server pueda enviar información de identificación en los reportes que hace periódicamente sobre el estado de la conexión.

La dirección ip multicast: Es una dirección comprendida en el rango 224.0.0.0 a 239.255.255.255

La dirección ip del receptor: Esto permite asociar la dirección ip del cliente a la dirección ip multicast del grupo, según el criterio con el que se armen los mismos, generalmente de acuerdo al tipo de medio que recibirá.

Transport: En esta opción se elige el protocolo de transporte a utilizar y el tipo de distribución que se hará para el cliente (Unicast o multicast).

SureStreaming Aware Spliting: con esta opción se permiten seleccionar si los contenidos distribuidos al cliente tienen la propiedad surestreaming, o sea, si se adaptara el flujo a las condiciones del enlace del cliente.

Low Latency: Permite habilitar una de las funciones especiales de la plataforma Real Networks la cual disminuye la latencia del medio, hacia el cliente para el cual se habilita.

Multicast time to live: esta opción permite configurar el tiempo de vida del los paquetes multicast en la red, la medida se da en numero de saltos que pueden dar los paquetes antes de que sean destruidos. Para nuestro trabajo elegimos 16, pero para distribución en una red lan son comunes valores mucho más bajos, como se muestra en la siguiente tabla:

Metadata transmit rata: Permite configurar cada cuanto tiempo en segundos se le envían metadatos sobre el medio, al cliente. Un número menor aquí implica un mayor consumo de ancho de banda, pero disminuye la latencia del reproducción del medio en el cliente.

Honor resend request: esta característica permite que el cliente haga un re-requerimiento de paquetes que han llegado con calidad pobre. Usar esta opción permite mejorar la calidad del servicio, pero requiere la configuración de un back-channel e incrementa el uso de ancho de banda.

Relay Live Broadcasts: esta opción permite que los flujos broadcast se envíen de un servidor a otro servidor de streaming, y cualquiera de estos puede entregar el medio a sus clientes cercanos.

Port Range: Configura los puertos en el receptor a los cuales se envía el flujo. Aquí se recomienza configurar un rango mínimo de 20 puertos o un puerto por cada Megabit de ancho de banda del flujo broadcast.

Security type: Esto permite configurar con que tipo de seguridad se hará la transmisión de flujo al cliente específico. Las opciones son NONE o Basic, en la primera no requiere ningún tipo de autorización o password, lo cual si es necesario en la segunda opción. Para la práctica trabajamos sin seguridad (Opción NONE).La configuración que se haga en este item debe ser coherente con lo que se configure el los receptores.

La configuración de los receptores es necesario trabajar con los siguientes parámetros:

Moint point: el punto de montaje desde el cual tiene derecho a servirse el receptor a configurar, y este debe aparecer el URLs del cliente para tener acceso al medio; por defecto /broadcast/.Edit Transmitter Name: Aquí se da un nombre al transmisor.

Transmitter Address/Netmask, Se da la dirección IPv4, o IPv6 del servidor de streaming que le entregara el flujo al receptor. Para recibir flujos broadcast de un rango de transmisores, se especifica una mascara después de la dirección ip.

Port Range, se configure los puertos en los cuales el flujo se recibirá, estos deben ser iguales a los configurados en el transmisor.Transport se selecciona el protocolo de transporte a utilizar y el modo unicast o multicast.

Multicast Address en este campo se configure la dirección multicast. Esta dirección debe corresponder a la dirección configurada en el transmisor.

Resend Requests reste parámetro permite que se hagan re-requerimientos de paquetes que no llegan al receptor, requiere uso de mas ancho de banda si se elige y se necesita que el transmisor se haya habilitado Honor Resend Requests.

Security Type se deben usar los mismos valores que en el transmisor.

pull splitting se usa cuando se quieren utilizar la característica de splitting (Se explica mas adelante en las opciones particulares del servidor). En este caso no se uso.

Back-Channel MulticastingBack-channel multicasting trabaja con los players de medios que soportan el protocolo RTSP. En este método de multicast cada player mantiene un canal de control al

Servidor Helix, usándolo para enviar comandos como STOP y PLAY, y para enviar estadísticas a cerca de la calidad del servicio que permite hacer un monitoreo del servicio a cada cliente.

Configuración de Back-Channel MulticastingCuando se trabaja con multicast escalable no se requiere la configuración del back-channel.

Enable Multicast es necesario habilitar este parámetro para poder trabajar multicast. De lo contrario los players solo podrán recibir unicast todos los flujos broadcasts.

Enable SAP al habilitar este parámetro permite que se envíen anuncios de sesiones multicast.

RTSP Port para configurar el numero del Puerto en los clientes donde el servidor envía los flujos multicast RTSP. Por defecto es el 3554.

IP Address Range aquí se especifica el rango de direcciones IPv4 a las cuales se hace el flujo multicast. El servidor Helix usa la primera dirección disponible en el rango. Si se utiliza la característica SureStream se requiere configurar un numero de direcciones de acuerdo al numero de audiencias para las cuales se codifico el medio.

Time to Live: Tiene el mismo propósito explicado anteriormente.

Resend: Permite que los paquetes perdidos se reenvíen a los clientes por peticiones de estos, permite alta calidad de multicast.

Multicast Delivery Only. Se activa esta opción si se desea entregar broadcast solo en modo multicast. Los Players que no puedan usar multicast no podrán conectarse al medio broadscast.

Access Rules Configurando esta opción permite restringir el rango de media players que pueden conectarse al multicast según sea definido en la regla a usarse.

Después de tener lista la configuración del servidor puede iniciarse la difusión multicast, para ello se configura el producer de la misma forma en que se hizo para broadcast unicast de fuentes almacenadas:

Se selecciona el archivo de entradaSe seleccionan las audiencias para la codificaciónSe configura el servidor de destino y se inicia la codificación.

Desde el momento en que se inicia la codificación los clientes (players) pueden reproducir el medio. Para ello se da el mismo formato en el navegador:

En este caso el medio se reprodujo perfectamente, pero en la captura de la pantalla la imagen no aparece debido a que es un video en ejecución y la captura no la puede hacer por frame.

Con el Ethereal se capturaron los paquetes y se filtro por la dirección ip del servidor de streaming, en la grafica se puede observar la negociación el anuncio multicast y los

flujos.

En las siguientes graficas se pueden apreciar el análisis de los flujos entre el servidor de streaming y el cliente multicast.

3.5. Broadcast multicast fuentes vivas

Toda la configuración previa en el servidor de streaming es exactamente igual. El cambio ocurre en el producer, puesto que aquí la fuente que se selecciona es un dispositivo de entrada, en este caso utilizamos el reproductor de CD. Después se configuran los otros parámetros como las audiencias y el servidor de destino de igual forma que en el caso de broadcast unicast de fuentes almacenadas.

Luego de que se inicia la codificación del medio en el cliente se podrá reproducir este dando en el navegador la URL en el formato especificado para broadcast unicast.

El cliente no modifica así la forma de requerir el contenido. Entonces para este es igual la reproducción multicast y unicast.

Si en el producer se ha configurado en el ítem CLIP la información relacionada con el medio como el titulo de la obra, el autor, el álbum u otra información, el cliente en el player tendrá la posibilidad de observar esta información.

En la captura de paquetes con el ethereal se verifica el trafico multicast, aunque no nos puede aportar mayor información sobre la fuente.

3.6. Otras Opciones Particulares del Servidor

Sin dunda, son muchas y variadas opciones de configuración que permite establecer Helix Server, pero solo destacaremos aquellas que para nuestro criterio son las más importantes, éstas son:

3.6.1. Server Setup

En ésta sección se deben establecer todos los parámetros necesarios para que el servidor presente las funcionalidades requeridas:

3.6.1.1. Ip Bindig

Por medio de ésta opción se especifican las direcciones IP que el servidor Helix podrá usar como interfaces.

En éste formulario se deben ingresar todas las direcciones IP a las que el servidor responderá. En caso de que el administrador del Sistema requiera que el servidor responda a todas las interfaces disponibles se introducirá la dirección IP 0.0.0.0, sin embargo, con transmisiones de medios vía Internet no es conveniente por el asecho de posibles hackers; será necesario reiniciar el servidor una vez se introduzcan las direcciones respectivas.

3.6.1.2. Connection Control

En ésta página podemos limitar, tanto el número de conexiones concurrentes como también el ancho de banda utilizado por el servidor. Esto es muy útil a la hora de ajustar el consumo del servidor, si se tienen limitaciones de ancho de banda se pude hacer la restricción, independiente o no del número de usuarios concurrentes que se acepten; si no se desea limitar el ancho de banda se deja el valor en 0.La opción Real Placer Plus Only hace referencia a si los archivos se pueden visualizar con el reproductor RealPlayer gratuito.

3.6.1.3. Mount Points

Por medio de ésta página se pueden configurar los diferentes puntos de montaje de los contendidos multimedia a transmitir y a los cuales el usuario puede hacer referencia (como directorios), Los Mount Points ó Puntos Base pueden ser definidos como directorios virtuales. Para la emisión de contenidos en directo desde nuestro servidor o para videos bajo demanda, se pueden ofrecer diferentes tipos de contenidos, es por esto que existen los puntos de montaje para clasificar los contenidos a distribuir en carpetas virtuales y organizadas en forma ordenada.

Al agregar un punto de montaje, se debe indicar el nombre (alias) que va a tener dicho punto base (/telepresencia/), en este ejemplo se localizará dentro del directorio “Content” y dentro de éste una subcarpeta llamada “telepresencia”; además se le puede asignar una descripción, ejemplo: La Telepresencia y en Base Path se le asigna la ruta real donde estará los archivos c:\luiszapata\telepresencia. Una vez creado éste punto de montaje los usuarios podrá invocar los archivos allí contenidos mediante una llamada:

rtsp://nomb_servidor:554/telepresencia/nomb_archivo.rm

3.6.1.4. Cache Directives

Cuando se desarrolla un sistema con Helix Server, éste sirve los contenidos multimedia cada vez que se le solicita, consumiendo tiempo y recursos para realizar la petición. Es por ello que RealNetworks creó una aplicación llamada Real Proxy que permite almacenar archivos de Streaming, la cual funciona repartiendo contenidos bajo demanda, de forma que los usuarios puedan acceder al servidor más cercano a ellos, además se puede configurar para que almacene los contenidos multimedia más solicitados y reenviarlos a usuarios que lo soliciten.

3.6.2. Security

En ésta sección se configura tanto las opciones de identificación de usuarios para comunicarse con el servidor, como las reglas y restricciones asociadas a ellos.

3.6.2.1. Access Control

Esta opción es muy importante no solo para impedir el acceso a los contenidos multimedia por parte de usuarios no deseados, sino que mediante las reglas de acceso, se puede configurar qué servidores de redundancia tienen la posibilidad de comunicar con nuestro servidor.

Primero se debe crear la regla (pulsando sobre +), luego se debe introducir el permiso o la denegación de acceso y la dirección IP del cliente, servidor y los puertos a los que se aplica la regla. En caso se requiera denegar o habilitar la regla a cualquier dirección IP, se debe ingresar “ANY”, de igual forma para los puertos.

3.6.2.2. User Databases

Helix Server, por defecto crea dos bases de datos de usuarios autenticados para administración y la codificación de contenidos multimedia. Estos usuarios son los que tienen privilegios de administración del sistema (éste usuario se crea automáticamente en todas las bases de datos) y los que pueden codificar contenidos en directo contra el servidor. Se pueden comprar licencias que permitan la creación de contenidos “Pay Per View” ó protegidos mediante contraseña.

3.6.2.3. Authentication

Existen seis bases de datos de autenticación por defecto, de las cuales 3 son las más relevantes: “Secure admin” la cual contiene la lista de usuarios con permiso de administración del sistema, “SecureRBSEncoder” la cual contiene la lista de usuarios con acceso a la retransmisión de eventos en directo desde Real Producer, y “SecureWMEncoder” que contiene la lista de usuarios con acceso a la retransmisión de eventos en directo desde Windows Media Encoger. En la parte inferior izquierda aparecen en color rojo las opciones para adicionar usuarios (Add a User to Real) con permisos a cada una de las bases de datos mencionadas con anterioridad; con Romote elimina usuarios previamente creados, change permite cambiar los usuarios o contraseñas creadas y Browse User in Realm permite visualizar todos los usuarios creados.

Para nuestro caso creamos un usuario con permiso de reproducir medios desde el Real Producer, se eligió la base de datos “SecureRBSEncoder” la cual contiene la lista de usuarios con acceso a la retransmisión de eventos en directo.

Si desea visualizar los usuarios que se han creado puede seleccionar la opción: Browse Users In Realm:

3.6.3. Monitoreo de conexiones y consumo de recursos.

Existen muchas opciones particulares del servidor, tocaremos primero la opción de monitoreo. De la transmisión multicast de fuentes vivas del punto anterior se obtuvo las información que aparece en la grafica de monitoreo.

El servidor Helix lleva registro del tipo y el número de conexiones, el tiempo de conexión y el archivo al cual conectaron. También permite observar el estado del consumo de recursos en el servidor mismo, como el consumo de CPU, el de memoria el número de conexiones, el ancho de banda usado y el número de archivos usados.

Se puede personalizar la pantallas de monitoreo y escoger los parámetros que quieren ser visualizados así como su color de representación. También permite hacer filtros para ver información mas especifica.

3.6.4. SPLITTING

Transmisores y receptores

Los transmisores y receptores son dos componentes de splitting, el cual habilita entregar flujos broadcast en cualquier formato a múltiples Servidores Helix, estos envían entonces los flujos multicast o unicast a los players de medios.

Reparto (Splitting)

Splitting es una tecnología que habilita a un componente para entregar flujos broadcast vivos o simulados como vivos a otro componente. Esto permite a un encoder transmitir un flujo a uno o mas Servidores, y a un servidor distribuir un flujo a uno o mas servidores adicionales. Esta tecnología permite entregar un único broadcast a muchos más usuarios y una mayor calidad debido a que el flujo puede estar más cerca de los clientes.

Definiciones

EncoderUn encoder es software que genera un flujo vivo o simulado vivo. Para RealMedia, un encoder puede ser RealProducer o SLTA simulated live transfer agent (SLTA). Se pueden usar encoders adicionales como Windows Media Encoder y Sorenson Broadcaster.

TransmitterUn transmisor es un servidor Helix Server en el cual se origina un flujo. El transmisor envía el flujo al receptor y puede también difundir el flujo directamente a los players. El RealProducer y SLTA pueden funcionar también como transmisores. Ellos envían un flujo solo a un Servidor Helix receptor y no a los players individuales.ReceiverUn receptor es un servidor helix que recibe un flujo de un transmisor y lo difunde a los players de medios.RelayUn relay es un servidor Helix Server que funciona como transmisor y receptor.Este recibe un flujo de otra fuente y transmite ese flujo a otro receptor. Puede además distribuir los flujos directamente a los players de medios.Push SplittingEn push splitting, un transmisor inicia la sesión splitting entregando el flujo broadcast a uno o más receptores.Pull SplittingEn pull splitting, un receptor inicia la sesión splitting contactando a un transmisor y requiriendo el flujo.

SPLITTING ENCODER-A –SERVIDOR Se puede usar la tecnología splitting para entregar un flujo vivo o simulado de un encoder a un servidor. Un servidor puede adquirir un flujo de muchas formas y no todas usan splitting, la siguiente tabla explica varios métodos de entrega encoder-a-servidor, indicando cuales están basados en la tecnología splitting.

SPLITTING SERVIDOR-A-SERVIDOREn Splitting Servidor-a-Servidor, Un servidor Helix transmite un flujo vivo o simulado a otro servidor. El transmisor puede adquirir el flujo a traves de la configuración de splitting con el encoger, o a través del método tradicional de broadcast. Esto permite transmitir el mismo flujo a múltiples servidores en una red y se puede usar esta tecnología para formar un cluster de servidores Helix en una intranet o en Internet.Esta tecnología ayuda a conservar el ancho de banda y a transmitir diferentes flujos a diferentes receptores.

Características• splitting push y pull—Un configuration splitting puede usar push splitting, pull splitting, o ambos.• unicasting y multicasting—Los transmisores pueden enviar unicast o multicast a los receptores. • solo transmisores o relays encadenados—Un transmisor puede repartir un fllujo a múltiples receptores. O, cada servidor Helix puede pasar el flujo al próximo servidor Helix. Se pueden combinar estos métodos para conseguir una gran red de servidores en cualquier configuración.• SureStream-aware splitting—Con esta característica al transmitir broadcast RealMedia,Se conserva el ancho de banda enviando solo el flujo codificado que se requiere de acuerdo al ancho de banda del enlace del cliente.• multiples definiciones de splitting—cada servidor puede tener múltiples definiciones de transmisores y receptores. Así puede distribuir ciertos flujos en modo push y otros en modo pull, originados en cualquier parte de la red.• redundancia—un complete Splitting suporta redundancia de encoders para cualquier tipo de medio. Pemite asi adicionar redundancia de servidores y de flujos.

Push SplittingLa siguiente ilustración muestra el modo convencional de splitting o “push” de servidor-a-servidor. En este el transmisor inicia la conexión al receptor. Cuando un media player require el broadcast, el receptor esta listo para entregar el flujo. En esta forma de reparto, un enlace en una pagina Web apunta al receptor. Un transmisor puede también entregar flujos a media players.

Pull Encoding with Push SplittingEn push splitting, el encoder empuja el flujo broadcast stream al transmisor, iniciando el broadcast. Sin embargo, el transmisor puede también arrastrar el flujo del encoder. Así se consigue push splitting con pull encoding. Para hacer esto, se debe crear un enlace privado al broadcast en el transmisor. Cuando se este listo para empujar el flujo al receptor, se da click al enlace, lo que causa que el transmisor arrastre el flujo del encoder y empuje este al receptor. Los clientes pueden entonces conectarse al broadcast en el receptor.

PULL SPLITTING

La siguiente ilustración muestra el método pull splitting, en el cual el transmisor no entrega el flujo al receptor a menos que el primer player de medios haga un requerimiento (step 1). Hay un pequeño retardo mientras el receptor hace el requerimiento (step 2), recibe (step 3), y entrega el flujo (step 4). Después de que el flujo esta vivo en el receptor y otros players hace requerimientos para este flujo, estos no tendrán el retardo de configuración de sesión (step 2)

Usar pull splitting tiene una mayor latencia que push splitting en el primer requerimiento, pero puede ahorrar ancjo de banda por que el flujo no es transmitido al receptor si no al player que hace el requerimiento. Cuando los clientes se desconectan del flujo antes de que la transmisión finalice los datos del flujo entre el transmisor y el receptor se eliminan entonces no se consume ancho de banda entre el transmisor y receptor si no hay clientes conectados al flujo en el receptor.Push Encoding with Pull SplittingAl uasr pull splitting entre transmisor y receptor, también se puede usar RealProducer o SLTA para empujar el flujo al transmisor.

Push Encoding with Pull SplittingAl uasr pull splitting entre transmisor y receptor, también se puede usar RealProducer o SLTA para empujar el flujo al transmisor.

3.6.5. SURESTREAM-AWARE SPLITTINGSureStream-aware splitting es similar a pull splitting cuando el flujo broadcast esta codificado a diferentes ratas de bits. Sin SureStream-aware splitting, el transmisor envia todos los flujos codificados en el broadcast al receptor. En la siguiente figura se muestra un flujo broadcast que no tiene habilitada la característica SureStream-aware.Cuando el receptor adquiere el flujo broadcast, este toma todas las ratas de bits, aunque solo se ha requerido el flujo a 56 Kbps por el player.

Con la característica SureStream-aware splitting envía cada flujo solo por requerimiento.El encoder envía al transmisor todos los flujos, pero solo el que fue requerido va al receptor. Si otro player posteriormente pide el flujo a otra rata, el transmisor envía este flujo. Si el placer para el trasnmisor detiene el envio del flujo. Esta característica ayuda a ahorrar ancho de banda, se puede habilitar tanto en modo de push splitting como de pull splitting, pero no esta disponible cuando transmisores y receptores se comunican a través de multicast.

3.6.6. SLTA

Difusiones vivas simuladas - SLTA

SLTA es una herramienta de línea de comandos instalada con el Helix Server. Corre en Windows o UNIX, esta envía un flujos de medios a un servidor Helix , el cual los difunde a los players. SLTA soporta todas las características de broadcasting:

•multicasting—SLTA puede entregar el mismo flujo a multiples servidores Helix en una red que tiene habilitado multicast.• entrega push —SLTA puede iniciar el broadcast contactando uno o mas servidores Helix y entregar el flujo.• entrega pull—El servidor Helix puede iniciar el broadcast contactando a SLTA y adquirir el flujo cuando el primer placer requiera el broadcast. SLTA soporta conexiones de multiple receptors configurados en modo pull. • redundancia broadcast —se puede separar aplicaciones SLTA en diferentes maquinas para crear flujos primerios y de backup.• SureStream-aware splitting—SLTA puede conserver el ancho de banda entregando cada flujo solo cuando este se require.

Formatos Broadcast

SLTA puede simular broadcast de audio o video en formatos RealMedia, QuickTime,MPEG, AU, WAV, o Windows Media.

Con SLTA, se pueden hacer entregas repetitivas y simular la programación de un canal de radio o TV, además permitiendo entregar cierta cantidad de clips.

Modo básico y avanzado

SLTA tiene dos modos: básico y avanzado. El modo básico simula la difusión basada cuenta. Permite empujar el streaming hacia un solo servidor.

En modo avanzado, SLTA funciona como un transmisor en una configuración de splitting, es decir, enviando flujos de streaming a unos o más servidores configurados como receptores.

Configuración del modo básico

El modo básico de SLTA es autenticado, así que se necesita instalar un nombre y una contraseña del usuario en el Helix Server:

Para simular el modo básico se difundirá un clip previamente codificado:

1. Crear una carpeta con nombre simulado, y copiar los siguientes archivos en dicha carpeta:

a. El archivo de slta.exe b. El archivo de slta.bat c. El clip de real9video.rm desde la carpeta content.

2. Salir al Sistema Operativos y pararse en la carpeta simulado

C:\Archivos de programa\Real\Helix Server\Content\simulado>

3. Ejecutar el siguiente comando para transmitir el clip real9video.rm bajo el nombre live.rm de la corriente. En Windows:

slta.bat 127.0.0.1 80 name password live.rm real9video.rm

Nota: Para este ejercicio, se puede utilizar el nombre y la contraseña que se utilizó cuando se registro el administrador del Helix Server.

4. Luego abrir el Explorer en la maquina del cliente (player) y digitar la siguiente URL:

rtsp://dir_ip_Helix_Server/broadcast/live.rm

5. Cuando se acabe de transmitir se debe para el proceso SLTA. Se debe salir al sistema operativo y en la línea de comando presionar Ctrl+ C.

Configuración del modo avanzado

Para simular el modo avanzado se difundirá un clip previamente codificado:

1. Crear una carpeta con nombre simulado, y copiar los siguientes archivos en dicha carpeta:

d. El archivo de slta.exe e. El archivo de slta.bat f. El clip de real9video.rm desde la carpeta content.

2. Salir al Sistema Operativos y pararse en la carpeta simulado

C:\Archivos de programa\Real\Helix Server\Content\simulado>

3. A través de la página de administración del Helix Server, configurar el servidor como receptor. Incorporar los valores siguientes, aceptando los valores prefijados para cualquier ajuste no enumerado.

Ajuste Valor Notas

Nombre del transmisor

Simulación

Un transmisor puede tener cualquier nombre, pero el nombre no debe incluir espacios.

Dirección del transmisor 127.0.0.1 Se SLTA se ejecuta en la misma máquina donde

se encuentra instalado el Helix Server.

Transmisor Netmask

32 pedacitos

Se requiere esto al usar el Servidor Local. No se requiere si se usa una dirección completa.

Tipo de la seguridad Ninguno Esta opción no requiere ninguna contraseña.

4. En un editor de textos, copiar la siguiente sintaxis XML salvando el archivo como transmit.cfg en el la carpeta creada “simulado”. Las variables de etiquetas deben terminar con una raya vertical (/).

<List Name="BroadcastDistribution"> <Var SourceName="simulado"/> <List Name="Destinations"> <List Name="TestReceiver"> <Var PathPrefix="*"/> <Var PortRange="30001-30020"/> <Var Address="127.0.0.1"/> <Var Protocol="udp/unicast"/> <List Name="Security"> <Var Type="None"/> </List> </List> </List></List>

Nota: Esta configuración establece SLTA como un transmisor push.

5. Salir al Sistema Operativos y pararse en la carpeta simulado

C:\Archivos de programa\Real\Helix Server\Content\simulado>

6. Ejecutar el siguiente comando para transmitir el clip real9video.rm bajo el nombre live.rm de la corriente. En Windows:

slta.bat -c transmit.cfg live.rm real9video.rm7. Luego abrir el Explorer en la máquina del cliente (player) y digitar la siguiente

URL:

rtsp://dir_ip_Helix_Server/broadcast/live.rm

8. Cuando se acabe de transmitir se debe para el proceso SLTA. Se debe salir al sistema operativo y en la línea de comando presionar Ctrl+ C.

Crear Playlist

No se requiere crerar un Playlis para difundir un solo clip. Un playlist puede contener cualquier número de clips.

Escritura de un Playlist básico

En un archivo de texto (.txt), se debe escribir en una línea separada cada archivo que se desee transmitir con SLTA. Si los archivos “clips” no residen en el mismo directorio que el playlist, se debe incluir la ruta de localización de dichos archivos:

CompanyLogo.rmWelcome.rmPresident.rmTreasurer.rmConclusions.rm

Advertencia: Todos los archivos en el playlist deben estar en el mismo formato de medio.

Adición título, autor, e información del copyright

Los clips de antemano tienen a menudo título, autor, e información del copyright codificada en ellos. Con el playlist, se puede sobrescribir la información de un clip o se puede dejar el mismo título, autor, y los datos de copyright para todos los clips. Los clientes “players” pueden observar ésta información con el comando (Ctrl+i).

Fijar la información para todos los clips

Para incluir el mismo título, el autor, y la información del copyright para cada clip, agregan título, el autor, y la etiqueta de copyright al principio del playlist. Esta información elimina cualquier información codificada en el clip. Terminar cada etiqueta con dos puntos, según las indicaciones del ejemplo siguiente:

title: Annual Reportauthor: Chris Lee, Executive Assistantcopyright: Copyright 2002

...clip1...

...clip2...

Carpeta simulado con los archivos slta.exe, slta.bat y los clips que se transmitieron:

En el archivo listado.txt se pueden

Observar los clips que se transmitieron.

En esta pantalla se observa claramente el clip real9video.rv que se repite simultáneamente.

En esta pantalla se puede observa un error que se produjo debido a que los formatos de los clips que se encuentran dentro del Playlist son diferentes.

Finalmente se transmitieron 4 clips (Video 1, Vedeo 2, Video 3 y Video 4), cada que llega al clip # 4 se repite la serie.

4. Opciones y Configuraciones del Reproductor

4.1. Estadísticas Obtenidas con Diferentes Tasas de Transmisión

a. Transmisión en Directo (256 DSL or Cable)

Nota: la imagen se visualiza con buena calidad.

Ancho de Banda:

Estado de los Paquetes:

Información de Clip de transmisión:

Otras estadísticas Avanzadas:

b. Transmisión en Directo (56k Dial-up)

Nota: la imagen se ve un poco borrosa.

Ancho de Banda:

Estado de los Paquetes:

Información de Clip de transmisión:

c. Transmisión en Directo (28k Dial-up)

Nota: la imagen se ve mucho más borrosa.

Ancho de Banda:

Estado de los Paquetes:

Información de Clip de transmisión:

d. Transmisión en Directo (150k LAN)

Nota: la imagen se ve mucho más borrosa.

Ancho de Banda:

Estado de los Paquetes:

Información de Clip de transmisión:

e. Transmisión OnDeman (150k LAN)

Ancho de Banda:

Estado de los Paquetes:

Información de Clip de transmisión:

f. Transmisión Broadcast Multicast (150k LAN)

Ancho de Banda:

Estado de los Paquetes:

Información de Clip de transmisión:

5. CONCLUSIONES

La tecnología de Streaming permite compartir medios audiovisuales de una forma fácil e inmediata, sin la necesidad de codificar o bajar archivos a un medio magnético antes de reproducirlo.

Esta tecnología permite distribuir flujos multimedia a diferentes usuarios casi de una forma inmediata, asegurando cierto nivel de calidad en el servicio; dicho servicio depende principalmente del servidor de medios y del canal o la red donde se implemente.

En un sistema de Streaming se pueden distinguir tres componentes o módulos fundamentales que son:

Servidor de streaming: se encarga fundamentalmente de entregar los flujos a los usuarios provenientes de las estaciones emisoras o reproductoras de medios, la gestión del ancho de banda, los accesos de los usuarios y la administración general de la plataforma de distribución de medios.

Otro componente o módulo importante, es el codificador el cual se encarga de digitalizar la información, es decir, permite comprimir o cambiar el formato de los medios de tal forma que pueden viajar por la red con el menor consumo de ancho de banda y con la mejor calidad posible para luego entregársela al servidor.

Finalmente se debe contar con un módulo de reproducción de medios transmitidos desde el servidor, el cual se encarga básicamente de la emisión de los flujos previamente grabados y almacenados en disco ó que son retransmitidos en directo.

Algunas aplicaciones de la tecnología de streaming son: TV Bajo demanda, estaciones de Radio en Internet, capacitación en línea, educación virtual, entre otros. Lo más importante de ésta tecnología es que puede ser implementada con muy buenos resultados y con muy bajos costos.

6. BIBLIOGRAFIA

Helix Server Administration Guide Helix™ Server Version 11 Revision Date: 2 September 2005

Canal de Televisión a Través de Redes IPhttp://www.uctem.cl/biblioteca/tesis-on-line/marcelo-ziem/tesis.pdf

Manual de Usuariohttp://www.internetmultimedia.com.mx/real/producer.htm

http :// unixhelp.ed.ac.uk/CGI/man-cgi?iptables+8

http://cita2001.ucauca.edu.co/jitt01/smi.htm

https://www.helixcommunity.org/

http://www.videoaktiv.org/fileadmin/template/main/vw/ehu/ manual_de_taller.pdf#search=%22Caso%20de%20Estudio%20RealNetWorks%22

http://www.fundaciontripartita.org/almacenV/publicaciones/documentos/ 23902_8686200594247.pdf#search=%22Ejercicio%20pr%C3%A1ctico%20RealNetworks%22

http://alumnos.elo.utfsm.cl/~eric/index7.htm

http://service.real.com/help/library/guides/helixuniversalproxy/proxy9.htm? page=htmfiles/quick.htm%23installation

http://service.real.com/help/library/encoders.html

http://www.atc.uniovi.es/doctorado/6smi/material.html

http://www.microsoft.com/spain/office/powerpoint/producer/prodinfo/ overview.mspx#E4C

http://www.isdmex.com/MxTV.pdf