| MONOGRAFICO:INTRODUCCIÓN AL STREAMING - Real Media |
 |
 |
 |
| SOFTWARE - General | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Javier Martín-Caro Junoy-k idatzia | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Ostirala, 2008(e)ko otsaila(r)en 29-(e)an 09:47etan | ||||||||||||||||||||||||||||||||||||||||||||||||||||
JPAGE_CURRENT_OF_TOTAL
Real MediaLa primera opción que analizaremos en este tutorial es la que ofrece Real Media ( www.realnetworks.com). Como se ha indicado anteriormente, el primer paso para la realización del streaming es la codificación de vídeo desde una o varias cámaras. La captura puede hacerse de manera analógica a través de una tarjeta capturadora o mediante un puerto FireWire (DV) si la cámara lo permite en los últimos modelos de cámaras con disco duro ni siquiera es necesario disponer de un puerto DV, el USB es suficiente-. El programa que realiza la captura y la envía al servidor es, en este caso, el Real Producer Basic (www.realnetworks.com/products/producer/basic.html). La versión de prueba gratuita en inglés permite hacer unicast con tres bitrates de codificación diferentes, ofreciendo la posibilidad de realizar multicast si se adquiere la versión completa. El servidor que propone Real Networks es el Helix Server ( www.realnetworks.com/products/media_delivery.html), con una licencia de prueba de hasta 5 conexiones simultáneas, y el reproductor necesario en el cliente es el Real One (http://spain.real.com/freeplayer_r1p.html), descargable de forma gratuita. Puesto que el servidor tiene que estar listo para que el Real Producer se comunique con él, comenzaremos analizando la configuración básica del Helix Server. Helix Server / Administración de Contenidos Requisitos Mínimos
Requisitos Recomendados
El programa de instalación de Helix Server nos guiará en el proceso de configuración básica del servidor. En primera instancia pedirá la ubicación del archivo de licencia, que Real Networks envía al correo tras un sencillo proceso de registro. El archivo básico, como indicábamos antes, permite la conexión simultánea de 5 clientes a través de archivos codificados mediante Real Media. Otras licencias de pago permiten trabajar con multicast y otros formatos de vídeo. La siguiente tabla clarifica las posibilidades que ofrece la licencia gratuita de prueba:
El siguiente paso en la instalación consiste en proponer un nombre de usuario y password para la administración del servidor. Debemos recordar estos datos, puesto que, al margen de poder gestionar el servidor, serán necesarios para la comunicación entre el Real Producer y el servidor.
Las siguientes pantallas permiten la configuración de los puertos que se utilizarán en la comunicación. Salvo que haya una causa justificada para cambiarlos se recomienda usar los valores por defecto, habilitando las conexiones a través de los mismos en el Firewall si se dispone de alguno-.
Además, configuraremos el servidor para que se inicie al encender el ordenador, de forma que esté siempre funcionando y tanto el Real Producer como los clientes puedan siempre comunicarse con él. Para ello, dejaremos marcada la opción Install Helix Server as an NT Service en el cuadro de diálogo siguiente.
Por último, una pantalla realiza un resumen de la configuración que acabamos de realizar antes de instalar. Pulsamos Finish y dejamos que el programa se instale en la ubicación que le hayamos propuesto al inicio.
Una vez instalado, el servidor se encontrará ya en funcionamiento tras reiniciar el sistema aunque hay accesos directos desde el grupo de programas creado para poder arrancarlo sin reiniciar-. Si pulsamos sobre el icono de Helix Server Administrator (habrá un acceso directo en el escritorio si no se ha especificado lo contrario en la instalación) se abre una página Web que permite la gestión del servidor una vez hayamos metido el usuario y contraseña que introdujimos en la instalación.
En principio no debemos cambiar nada para que el servidor funcione, pero habría que preguntarse qué queremos hacer con los archivos que se emitan en tiempo real. Si preferimos que, al margen de que el cliente pueda verlos en directo, el servidor los guarde para un visionado posterior, hay que especificárselo al servidor a través de la opción Live Archiving, en la pestaña Broadcasting, activando la opción Archiving -> Enabled.
El acceso a los contenidos del servidor se realiza, por defecto, sin ningún tipo de control; cualquiera que sepa la dirección del servidor puede conectarse y visualizar el vídeo pero no administrarlo-. Si se desea variar esta configuración, para solicitar una contraseña o limitar el uso a determinados equipos, puede hacerse desde Security -> Access Control -> Access Rules -> Allow all other Connections, modificando la pestaña para permitir/denegar las conexiones de determinadas direcciones IP o a través de determinados puertos.
El servidor no precisa de más cambios para trabajar en su modo más básico. Para funciones más avanzadas se recomienda acudir a su completo manual en línea. (http://service.real.com/help/library/guides/helixuniversalserver/realsrvr.htm?page=htmfiles/spliting.htm) A continuación se procede a explicar el proceso de codificación del contenido multimedia mediante el programa Real Producer Basic y la comunicación entre ambos programas. Real Producer Basic / Codificación de Contenidos Requisitos Mínimos
Requisitos Recomendados
Tras instalar y ejecutar el programa, la pantalla que veremos al abrir por primera vez el programa será la siguiente:
En la parte izquierda se verá el vídeo de entrada que le llega al programa, mientras que en la ventana derecha aparecerá el vídeo de salida que se va a mandar al servidor. La parte inferior de la pantalla servirá para funciones de monitorización de los trabajos realizados. Si el archivo que queremos transmitir se encuentra ya grabado en el ordenador podemos enviarlo seleccionando la opción Input File e introduciendo la ruta del archivo. Por el contrario, si deseamos enviar la señal de una cámara es necesario especificar al programa las fuentes de captura de audio y vídeo desde la opción Devices.
Una vez hecho esto podemos variar las preferencias de captura de ambas fuentes pulsando en Settings. Es importante cambiar, sobre todo, el formato de captura de la fuente de vídeo, pues viene por defecto en NTSC, el sistema americano. Pulsaremos, por tanto en Settings -> VfW Video Source y cambiaremos el sistema a PAL-BDGHI. Si este paso se realizó en la fase de instalación de los drivers de la tarjeta podemos saltárnoslo.
En función del tipo de audiencia que esperemos tener podemos variar también la resolución a la que se va a capturar el vídeo. Una resolución mayor consumirá también mayor ancho de banda, pero revelará detalles más finos de la imagen. Todo dependerá del número de usuarios que esperemos tener, del ancho de banda que tengamos a disposición en el servidor y de la red a través de la cual llegue el vídeo al cliente. Para modificarlo, desde el dispositivo de captura de vídeo iremos a Settings -> VfW Format Source -> Video Size .
Al margen de la resolución con la que se capture el vídeo, la velocidad de codificación también afectará al usuario final. Este programa permite utilizar varios bitrates simultáneos de codificación (SureStream) para que, en función del ancho de banda que posea el cliente, el vídeo se reproduzca con mejor o peor calidad. Por defecto, el programa codifica a una solo bitrate de 256kbps, pero puede modificarse pulsando Audiences en la parte derecha de la pantalla.
En nuestro ejemplo, el contenido multimedia se codificará a tres bitrates diferentes, 256kbps, 512kbps y 768kbps. El emparejamiento en función del ancho de banda que disponga el cliente lo realiza de forma automática el programa de la siguiente manera: · 0 450 kbps o Ancho de banda de vídeo = 180.9 kbps o Ancho de banda de audio = 44.1 kbps · 450 700 kbps o Ancho de banda de vídeo = 353.5 kbps o Ancho de banda de audio = 96.5 kbps · 700 y bitrates superiores o Ancho de banda de vídeo = 603.5 kbps o Ancho de banda de audio = 96.5 kbps Una vez se han definido las fuentes de captura y los formatos de codificación del contenido multimedia hay que especificar cómo se realizará la conexión con el servidor de streaming. Para ello pulsamos sobre Add Server Destination en la parte inferior derecha de la pantalla, como se indica a continuación:
Aparecerá entonces un cuadro de diálogo que permitirá configurar la conexión. En primer lugar se especifica el nombre del trabajo y del stream de video a nuestra elección, simplemente definirá el nombre del trabajo, así que sería bueno emplear un nombre que identifique de manera unívoca el mismo-, así como el tipo de conexión que vamos a emplear. Existen dos formas bien diferenciadas de hacer broadcast difusión de vídeo bajo demanda por streaming-. Si se utiliza el método Push el flujo de vídeo está siempre enviándose al servidor, aún cuando no hay usuarios que soliciten su visionado. A través del método Pull podemos conseguir que no se empiece a codificar el vídeo hasta que no haya un usuario que solicite el contenido. En este tutorial se manejará el método Push, pues permite afrontar en la mayoría de los casos las aplicaciones más importantes de streaming. A través de este método se consigue, si hemos activado la opción de archivar en el servidor, que un usuario pueda ver posteriormente un vídeo aunque no hubiera clientes solicitándolo mientras se codificaba.
Habremos de indicar, también, la dirección IP que identifica al servidor (típicamente el mismo equipo donde corremos el Real Producer) y el nombre de usuario y contraseña que se introdujeron en el proceso de instalación de Helix Server. El puerto de comunicación (80, por defecto) y el protocolo (UDP) no se modificarán a no ser que se haya hecho lo mismo en el proceso de instalación de Helix Server.
Antes de empezar la codificación podemos, de manera opcional, definir la información básica del clip multimedia que vamos a enviar. Simplemente hay que pinchar sobre Clip Information, debajo de la pantalla de vídeo de la derecha.
Así, una vez definidos los formatos de codificación y la comunicación con el servidor, la pantalla del programa mostrará un aspecto similar al siguiente:
Para empezar a codificar sólo tenemos que pulsar sobre Encode, en la parte inferior derecha de la pantalla, pinchando en Stop cuando hayamos terminado. Automáticamente se enviará la información al servidor Helix tal y como se haya detallado, estando disponible para que los clientes puedan verla con el programa Real One. En caso de precisar más información sobre el Real Producer, o los modos de configuración para hacer Push Broadcasting o Multicast se recomienda acudir al manual en línea ofrecido por Real Networks. ( http://service.real.com/help/library/guides/RealProducer10/producer.htm) Real One / Acceso a los contenidos Requisitos Mínimos
Requisitos Recomendados
Aunque el usuario puede acceder al streaming a través del propio reproductor de Real Networks Real Placer / Real One-, la situación típica será el acceso a través de un link en una página Web que abrirá automáticamente el programa. De forma general, indicamos a continuación las URL típicas de acceso a los contenidos del servidor. Para el streaming en vivo, los contenidos se encuentran bajo el protocolo de Real Media rtsp, dentro de la carpeta broadcast (rtsp://direcciónIP/ broadcast/nombre_de_archivo.rm). Por ejemplo, para un servidor cuya dirección IP fuera 195.53.170.116 y que estuviera emitiendo un flujo de vídeo de nombre prueba.rm la dirección URL sería la siguiente: rtsp://195.53.170.116/ broadcast/prueba.rm Si se pretende acceder a un contenido archivado la URL es ligeramente diferente. El protoclo de acceso es, en este caso, http, y la carpeta donde se almacena el contenido en el servidor por defecto es ramgen/Archive ( http://direcciónIP/ramgen/Archive/nombre_de_archivo.rm). De nuevo, para un servidor cuya dirección IP sea 195.53.170.116 y un archivo almacenado de nombre prueba.rm la dirección URL de acceso es: http://195.53.170.116/ramgen/Archive/prueba.rm En la pantalla de administración del Helix Server es posible asignar alias a las URL, de forma que se pueda acceder a las mismas usando nombres de archivo más cortos, o almacenar los archivos en carpetas distintas a las mencionadas anteriormente. Antes de pasar al siguiente sistema de transmisión de vídeo en tiempo real a través de la red se procede a realizar algunas consideraciones en cuanto al ancho de banda necesario para ofrecer un servicio de broadcasting a través de unicast, sea cual sea el sistema elegido. Helix Server propone un sistema de monitorización del servidor en tiempo real a través de su página de administración. Para entrar en él simplemente hay que ir a Logging and Monitoring -> Server Monitor e introducir el usuario y contraseña de administrador. Aparecerá entonces una pantalla que indicará a lo largo del tiempo, entre otras cosas, el número de clientes conectados, el número de archivos que se están viendo, si hay programas codificando vídeo en directo y el ancho de banda y memoria consumidos, como aparece en la siguiente figura:
Es importante conocer el ancho de banda que posee el servidor, pues influirá en el número de clientes y codificadores con los que podremos trabajar simultáneamente. Manejar contenido multimedia vídeo, especialmente-, consume mucho ancho de banda, por lo que hemos de estar atentos a este parámetro. Es responsabilidad del administrador del servidor y de la persona que codifica el evento el establecimiento de las reglas de juego en la comunicación entre cliente y servidor. Por ejemplo, si estamos emitiendo en tiempo real un evento a una resolución de 768x576 píxeles y 768kbps y se conectan dos clientes al servidor a 700kbps para ver el evento, el ancho de banda consumido en el servidor ronda los 2000kbps. Es fácil extrapolar el resultado cuando el número de clientes aumenta.
El ancho de banda es un recurso limitado, así que hay que explorar las necesidades del vídeo que queremos transmitir. Si en el vídeo no hay mucho movimiento, es mejor codificar con un bitrate medio-bajo, puesto que la calidad de vídeo seguirá siendo aceptable y en el mismo ancho de banda se podrán conectar un mayor número de clientes. Por el contrario, si el movimiento y los detalles finos de la imagen son lo importante, será necesario codificar el archivo a velocidades más altas, aunque en una conexión lenta el movimiento puede resentirse. Para una sesión de videoconferencia donde la cámara está generalmente fija o su movimiento es irrelevante para la información que queremos captar, si el codificador trabaja a 512kbps y los dos clientes conectados lo hacen a velocidades inferiores a 450kbps (referencia en la página 14), el ancho de banda necesario disminuye hasta poco más de 1000kbps, prácticamente la mitad que en el caso anterior. En la siguiente captura de pantalla puede verse este último caso, y también la memoria consumida en el servidor al administrar el flujo de datos, similar a la del ejemplo anterior:
Una práctica interesante cuando el ancho de banda es limitado y el vídeo no es una característica importante en la transmisión es codificar éste a un bitrate bajo y dejar el audio con una calidad superior. El audio consume mucho menos recursos que el vídeo, pero una bajada de calidad en este aspecto es mucho más incómoda para el usuario final. |
