Para poder probar todo lo contado en las anteriores entradas era necesario tener un elemento externo a los ya explicados que fuera el encargado de realizar la conexión entre los MMDevices.

Para ello, desarrollé un pequeño (¡58 líneas!) programa en Python que únicamente solicitaba la conexión entre dos MMDevices, que eran pasados en forma de stringfied proxies al programa mediante argumentos.

Además, siguiendo las directrices de AVStreams, también se debía crear un objeto de la clase StreamCtrl (control del flujo), que a su vez debería estar accesible públicamente. Esto último se ha "obviado" en cierto modo, ya que el programa termina nada más establecer la conexión entre los dos extremos, por lo que el objeto de tipo StreamCtrl desaparece al poco de ser creado. A fin de cuentas, este programa es el que pretendo utilizar para realizar algunas pruebas automáticas a los elementos del sistema (cosa que entrará, si FSM quiere, en otro post).

Ahora, vamos a utilizarlo...

Descarga de argos_config

Como el resto de Argos, se puede encontrar en el repositorio Mercurial:

$ hg clone http://arco.esi.uclm.es/~josel.segura/pfc

Dentro del directorio software/src/CliConfigurator está el ejecutable, que a la vez es el fichero de código fuente al tratarse de Python.

Ejecución de argos_config

Para ejecutarlo deberemos tener en cuenta que la sintaxis correcta para el comando es la siguiente:

./argos_config [ICE options] A-Side-Proxy B-Side-Proxy

Los argumentos A-Side-Proxy y B-Side-Proxy son intercambiables, ya que la conexión entre ellos se realiza igual independientemente de quien tenga el rol de sumidero y quien el de fuente.

Los argumentos opcionales de Ice son los habituales vistos en los anteriores posts. Si no se pasa ninguno, argos_config intentará cargar el fichero de configuración Ice por defecto de Argos, que deberá estar en $HOME/.argos/ice_config (el equivalente a pasar como opción --Ice.Config=~/.argos/ice_config).

Sobra decir que para poder probar esta herramienta de configuración será necesario tener dos MMDevices funcionando. Por ejemplo, se podría conectar una cámara Axis o un dispositivo V4L2 con un sumidero de vídeo en escritorio.

Tras un parón en mis entradas, vuelvo a la carga para contar como servir cámaras (o cualquier otro dispositivo) que funcionen utilizando la librería Video4Linux 2 (v4l2). Dentro de este grupo se engloban tanto cámaras USB, tarjetas capturadoras de televisión, TDT...

Para desarrollar este servicio me he vuelto a apoyar del ya archi-comentado MMDeviceCreator. La implementación del V4L2Server se ha realizado en Python.

El flujo multimedia del dispositivo V4L2 se sirve utilizando un servidor RTSP proporcionado por el proyecto Gstreamer. La implementación del servidor RTSP de Gstreamer, a día de hoy, es algo tosca, ya que no está integrado al 100% con el resto del framework, y además, a pesar de proveer unos bindings para Python que hubieran sido muy útiles para mi implementación, estos están poco/nada documentados y, por lo que he probado, son inusables a día de hoy.

A pesar de ello he decidido utlizarlo en detrimento de otras alternativas como VideoLan VLC, ya que su servidor RTSP no era configurable tan a medida como promete, en un futuro, el de Gstreamer.

Tras esta entrada sobre las tecnologías utilizadas, vamos al meollo del asunto:

Servir un dispositivo V4L2 utilizando Argos

Lo primero será obtener los ejecutables. Para ello y como siempre, debes descargar el código desde el respositorio:

$ hg http://arco.esi.uclm.es/~josel.segura/pfc

En el directorio software/src encontraréis, entre otros, los directorios GstRTSPLaunch y v4l2Server. El primero de ellos contiene el código del servidor RTSP que vamos a utilizar, mientras que el segundo es la fuente de V4L2 de Argos.

Compilar e instalar el servidor RTSP

Para compilar el servidor RTSP necesitaremos tener instaladas las librerías de desarrollo siguientes:

• Gstreamer 0.10 (en Debian y similares, paquete libgstreamer0.10-dev)
• Gst-RTSP-Server 0.10 (en Debian y similares, paquete libgstrtspserver-0.10-dev)

Con ellos instalados, dentro del directorio GstRTSPLaunch indicado anteriormente, ejecutaremos:

$ make

$ make install

Es posible que para el segundo paso (la instalación) hagan falta permisos de super-usuario.

Otro modo de conseguirlo es a través del paquete Debian que se puede descargar desde el repositorio de Gnesis, añadiendo la siguiente línea al fichero /etc/apt/sources.list:

deb http://babel.esi.uclm.es/gnesis sid main

Tras añadir la línea solo hará falta hacer:

# aptitude update

# aptitude install gst-rtsp-server

Ejecutando la fuente Argos de V4L2

Para ello vayamos al directorio v4l2Server comentado anteriormente.

Dentro de ese directorio está el fichero ejecutable "v4l2server.py". Al ejecutarlo podremos pasarle el fichero de configuración Ice de la forma habitual (con el argumento --Ice.Config=fichero) o bien dejarlo sin poner (toma por defecto el fichero de configuración de $HOME/.argos/ice_config).

Dentro del fichero de configuración se deberán definir las siguientes variables de configuración:

• Ice.Default.Locator: el locator por defecto para la aplicación. Se utilizará para resolver nombres de proxies indirectos.
• Adapter.Endpoints: el endpoint que tomará el adaptador de objetos de la aplicación.
• Argos.MMDeviceDeployer: el proxy al servicio de negociación/creación de MMDevices comentado con anterioridad.

En el repositorio podéis ver un ejemplo de este fichero de configuración guardado con el (original) nombre de "config".

Para ejecutar:

$ ./v4l2server.py --Ice.Config=config

Por ahora, y a falta de más pruebas, se supone que el dispositivo a servir es el ubicado en /dev/video0. A no mucho tardar añadiré la posibilidad de configurar esto desde el propio fichero de configuración.

¿Qué está ocurriendo tras todo esto?

Detrás de todo este "lío" lo que está ocurriendo es que el programa v4l2server.py está notificando al servicio MMDeviceCreator indicado su capacidad para servir un dispositivo v4l2. MMDeviceCreator creará un MMDevice y demás objetos asociados a las negociaciones de AVStreams.

Cuando alguien "conecte" este MMDevice con otro que tenga la capacidad de renderizar un flujo (por ejemplo, el RenderApplet), ambos MMDevices comenzarán el proceso de configuración del flujo. Cuando le toqué, el MMDevice creado para nuestro v4l2Server preguntará a éste la cadena de conexión RTSP (u otro tipo de protocolo streaming que se implementara) y se la pasará al sumidero multimedia para que sea capaz de consumir dicho flujo.

Siguiendo la veda iniciada en las dos entradas del blog anteriores, en esta entrada voy a presentaros RenderApplet.

RenderApplet es un programa escrito en Python que utiliza el servicio MMDeviceCreator de negociación. El programa está escrito en forma de applet de escritorio para Gnome: al activarlo se registrará en el servicio de negociación y, a partir de ese momento, dicho servicio negociará en su nombre las conexiones AVStreams, pasándole a RenderApplet la cadena de conexión resultado de dicha negociación.

La utilización como veis es bastante sencilla. Para poderlo probar sin necesidad de añadir el applet de escritorio también puede ejecutarse como aplicación "independiente" (aunque queda mucho peor :P).

Al estar escrito en Python, el código fuente y el ejecutable es el mismo. Para obtenerlo, descargad mi repositorio con Mercurial:

$ hg http://arco.esi.uclm.es/~josel.segura/pfc

Explorar en el directorio pfc/software/src/RenderApplet/RenderApplet y encontraréis el código de la aplicación.

Dos sabores

Como he comentado anteriormente, el programa puede ejecutarse tanto como aplicación GTK normal y corriente y como applet de escritorio de Gnome.

Si eliges utilizar esta segunda opción, deberás realizar, antes de instalar, una configuración para que Gnome sea capaz de encontrar el applet en la ruta de instalación. No instalo directamente en la ruta por defecto dónde lo encontraría por no ensuciar los directorios que gestiona muy bien tu sistema gestor de paquetes ;)

Argos Render como applet

Si te decides a instalarlo como applet, deberás realizar lo siguiente antes de instalar:

1. Instala el programa bonobo-activation-sysconf. En sistemas Debian-based se encuentra en el paquete libbonobo2-bin.
2. Ejecuta, como super-usuario, lo siguiente:

# bonobo-activation-sysconf --add-directory=/usr/local/lib/bonobo/servers

Deberéis cambiar esta línea si habéis cambiado la ruta de instalación en el Makefile del prorgama

Instalando

Para instalar Argos Render Applet deberás ir, dentro del repositorio Mercurial, al directorio software/src/RenderApplet y ejecutar simplemente:

$ make install

Esto copiará todos los ficheros a sus rutas correspondientes.

EDITO: Es importante, pero se me había olvidado. Los programas Python que utilizan Ice pueden cargar los ficheros de definición de interfaces en tiempo de ejecución. Esto obliga a que, para ejecutar el applet, tengáis los ficheros Slice de Argos en una ubicación concreta. Para ello si me dio tiempo a realizar un paquete Debian que podéis encontrar en el siguiente repositorio:

deb http://babel.esi.uclm.es/gnesis unstable main

El paquete se llama argos-slice. Si no tenéis Debian o no queréis instalarlo, tendréis que bajarlos del repositorio Mercurial mencionado anteriormente. Se encuentran en el directorio software/src/slice y, si queréis copiarlos a la ubicación dónde el applet los buscará, deberéis hacer lo siguiente desde el directorio software/src/slice:

# make install

Esto copiará los ficheros en /usr/share/argos/slice, con lo que Render Applet será capaz de localizarlos.

Haciendo que Gnome encuentre el applet

Si vas a usar el applet deberás reiniciar el servicio de búsqueda de applets de Gnome para que busque los nuevos recién instalados y puedas añadirlos a los paneles. Para ello hay dos opciones:

• Reiniciar la sesión de tu usuario
• "Matar" los procesos "bonobo-activation-server" y "gnome-panel". Durante unos instantes desaparecerán todos tus paneles, pero a los pocos segundos volverán, tranquilo :)

Fichero de configuración

Como aplicación Ice que se precie, lo habitual es pasarle los parámetros de funcionamiento (como el default locator o proxys que necesite utilizar la aplicación a través de un fichero de configuración. Si lanzamos la aplicación como programa (no como applet) tan solo deberemos pasarle cualquier opción en la forma habitual que Ice la "parsearía" (--Ice.Config=... --Ice.Default.Locator=...).

Sin embargo, si se trata de un applet no podemos ejecutar y elegir que parámetros se le pasan al ser ejecutado, ya que esta ejecución la realizará el panel de Gnome. Por ello, el programa por defecto buscará en el directorio home del usuario un directorio que se llame .argos y, dentro de él, el fichero ice_config.

Todas las aplicaciones de usuario que voy a desarrollar cogerán su configuración de ese fichero si no la encuentran entre los parámetros de ejecución, sí que sería recomendable que esté escrito desde ya con parámetros que puedan utilizar todos los programas. Un ejemplo mínimo sería el siguiente:

Ice.Default.Locator=IceGrid/Locator -t:tcp -h peter -p 4061

Argos.MMDeviceDeployer = MMDeviceCreator -t:tcp -h peter -p 15000

Ejecución del programa

• Ejecución como applet: Sobre alguno de los paneles de Gnome pulsamos con el botón derecho del ratón en una zona libre y seleccionamos la opción "Añadir al panel". Se abrirá una ventana dónde podremos encontrar el "Argos Media Render Applet". Lo seleccionamos y le damos a "Añadir" y debería aparecernos un círculo rojo en nuestro panel (el applet).
• Ejecución como programa externo: vamos a la ruta del código fuente dónde está el programa o bien a la ruta de instalación (por defecto /usr/local/share/argos-render-applet) y ejecutar como un programa normal desde la terminal el fichero RenderApplet.py, pasándole como primer argumento la palabra "window". Aparecerá una nueva y pequeña ventana que incluye el mismo icono que podríamos ver en el panel si hubiéramos realizado la otra opción.

En ambos casos, una vez hecho esto, si pulsáis en el círculo rojo (o el icono que aparezca, depende del tema de iconos de Gnome) éste pasará a ser verde y significará que, si las configuraciones son correctas, el programa se ha comunicado con el MMDeviceCreator para que cree un MMDevice y el resto de elementos AVStreams necesarios para gestionar la configuración. Una forma de comprobar que todo ha ido bien es, en el programa icegrid-gui, conectar con el registry y observar los objetos bien conocidos: debería aparecer un nuevo objeto, de tipo ::AVStreams::MMDevice, llamado $USER_render (dónde $USER es el nombre de tu usuario en tu máquina).

En la próxima entrada explicaré brevemente como utilizar un pequeño programa de configuración para poder conectar entre si un sumidero y una fuente multimedia, y poderle así dar un uso visual al applet.

Hasta pronto :)

Como comenté en mi entrada anterior (Servicio de negociación), he escrito un servicio IceBox que proporciona, a aquellos clientes que lo necesiten, toda la negociación que puedan necesitar para realizar conexiones AVStream.

En este post detallaré como instalar dicho servicio y como ponerlo en marcha. Allá vamos.

Instalación

Para instalarlo, en entornos Debian, solo habrá que tener esta línea en el fichero /etc/apt/sources.list

deb http://babel.esi.uclm.es/gnesis/ unstable main

y realizar lo siguiente:

# aptitude update

# aptitude install libmmdevicecreator

Para el resto de entornos GNU/Linux, libmmdevicecreator.tar.gz: este fichero contiene tanto la librería (fichero .so) como dos ficheros, nombrados "config" y "config_MMDCS", que serán explicados en el siguiente punto.

Puesta en marcha

Como el resto de servicios implementados utilizando las ventajas de IceBox, para lanzarlo solamente hará falta escribir un par de ficheros de configuración: en uno de ellos, que será el que acepte el ejecutable de IceBox, se describirá como debe lanzarse el servicio (nombre de la librería, versión, orden en el caso de lanzarse varios servicios a la vez...). El otro fichero de configuración se le pasará al servicio propiamente dicho, y tendrá las variables que necesite para su ejecución. Estos ficheros se corresponden, respectivamente, con los que encontramos en el tarball.

Para lanzar el servicio, lo primero, deberemos tener la librería en una ubicación bien conocida para el ejecutable de IceBox. En el caso del paquete Debian no habrá ningún problema, pero en el caso del tarball deberemos copiar el fichero .so a /usr/local/lib o bien hacer que la variable de entorno LD_LIBRARY_PATH contenga el directorio dónde se encuentre el fichero.

El fichero "config" tiene tan solo la configuración del "Default Locator" de nuestro entorno y la configuración de carga de la librería:

Ice.Default.Locator=IceGrid/Locator:tcp -h peter -p 4061

IceBox.Service.MMDCS=MMDeviceCreator:createService --Ice.Config=config_MMDCS

Con esa configuración definimos un servicio IceBox llamado "MMDCS", el cual intentará cargar la librería "libMMDeviceCreator" a través de su punto de entrada "createService", pasándole la configuración del fichero config_MMDCS.

Este otro fichero es el que configura realmente el servicio, y además de la configuración del Default Locator, deberá incluir la configuración del endpoint para el MMDeviceCreatorAdapter, el proxy al PropertySetDefFactory, que nos proporciona el servicio de propiedades, y un par de variables Registry.username y Registry.password que contendrán, si los hubiera, el nombre de usuario y la password administrativa del Registry al que estamos conectados.

Para lanzarlo:

$ icebox --Ice.Config=config

Al lanzarlo, obtendremos por la salida en el terminal algo como lo siguiente:

[INFO] [MMDevice Creator] Starting service

[INFO] [MMDevice Creator] PropertySetDefFactory proxy: PropertySetFactory -t @ AutoPropertyService.Adapter

[INFO] Negotiator -t:tcp -h 192.168.1.2 -p 15000

Esa última línea es la que los clientes deberán utiliazr para poder utilizar el servicio. Si se realizara un despliegue a a través de IceGrid, este último proxy sería un objeto bien conocido, por lo que el acceso para los clientes sería más sencillo aún.

En la próxima entrada os contaré como utilizar el primer cliente que hice para este servicio: un sumidero que se activa a través de un applet de escritorio y que, por ahora, podréis probar con una cámara Axis, si es que la tenéis claro :P

Edición: Por recomendación de mi director de Proyecto os doy las instrucciones para descargar desde el repositorio el código fuente:

hg clone http://arco.esi.uclm.es/~josel.segura/pfc

Por si no lo conocéis, el comando "hg" se corresponde al CVS Mercurial. Podéis encontrar información sobre él en http://mercurial.selenic.com/ y en esta recete en Crysol: Mercurial, por favor.

Una vez tengáis el repositorio en vuestra máquina, podréis encontrar todo el código fuente en el directorio software/src. En concreto, el MMDeviceCreator está en software/src/MMDeviceCreator

Durante el desarrollo de Argos, poco a poco, me he ido dando cuenta que ciertas partes del código se repetían en los diferentes elementos que conforman el sistema. En concreto, todo el algoritmo de

negociación de AVStreams se repetía en cada elemento fuente o sumidero, lo cual implicaba la re-escritura del código en diferentes lenguajes y, además, tener duplicado dicho algoritmo en diferentes ubicaciones.

A raíz de este "descubrimiento" empecé a pensar en simplificarlo: si la negociación siempre se hace de la misma forma, dando los mismos pasos, ¿por qué no hacer un servicio que se encargara de ella? Empecé así a escribir un servicio que permitiera a cualquier sumidero ser anunciado/publicado en el sistema y realizar la negociación sin escribir una sola línea de AVStreams en el mismo, delegando todo ello en ese servicio.

Tras realizarlo, observé que la idea era fácilmente adaptable para acoger no solo a los elementos que quisieran actuar como sumideros, si no también a aquellas fuentes que así lo quisieran.

De esta idea, surgió poco a poco el servicio que por ahora llamo MMDeviceCreator (se admiten sugerencias en el nombre :D).

Este servicio proporciona a sus clientes la posibilidad de delegarle totalmente la negociación de la conexión AVStream. El programador de un elemento solamente tendrá que preocuparse de escribir como proporcionar el flujo multimedia (o como consumirlo, en el caso de los sumideros) y "decirle" al servicio que capacidades tiene (de la misma forma que AVStreams hace para negociar

entre dos extremos de conexión). Con ello, y solamente definiendo un nuevo fichero de interfaz slice, se desacoplaba la negociación del flujo propiamente dicho, y de paso, se permite que la implementación final esté realizada en el lenguaje que queramos (siempre que sea compatible con Ice, por supuesto).

El servicio ya está "terminado", aunque en fase de pruebas. Ya he realizado la puesta en marcha de algunos casos de uso y he implementado un sumidero y una fuente que utilizan el servicio, pero estos serán material para próximas entradas.

En esta receta explicaré como poner en funcionamiento uno de los elementos de Argos: el MediaServer especializado para las cámaras IP de marca AXIS.

Instalación

Como ya comenté en otras entradas, el MediaServer está implementado como servicio IceGrid. Por ello, he distribuido un binario en forma de paquete DEB para Debian. Para poder instalarlo, añade lo siguiente en tu archivo /etc/apt/sources.list

deb http://babel.esi.uclm.es/gnesis/ unstable main

Una vez hecho esto tan solo hará falta hacer lo siguiente:

# aptitude update;

# aptitude install libaxismediaserver

Dicho paquete instalará las dependencias necesarias para hacer funcionar "el invento" y, además, incluye un fichero XML con la configuración mínima para poder cargarlo en IceGrid-GUI y ver como configurarlo. Dicho fichero se encuentra en /usr/share/doc/libaxismediaserver/template.xml

Puesta en marcha

Para la puesta en marcha supondré que tenemos una cámara Axis en la IP 192.168.0.5. El servicio se puede arrancar de dos formas: a mano, ejecutando icebox y pasándole un fichero de configuración con los parámetros correctos o bien utilizando IceGrid-GUI y la plantilla suministrada con el paquete.

Usando icebox y dicheros de configuración

Para arrancar el servicio "a mano" necesitaremos dos ficheros de configuración diferentes:

• El primero será en el que le especifiquemos a IceBox que librería cargar y una serie de configuraciones de administración de los servicios ejecutándose en ese IceBox.

• El segundo es el que IceBox pasará a la librería y que contendrá parámetros que utilizará el MediaServer para Axis para funcionar.

Ejemplo del primer fichero de configuración:

IceBox.Service.AxisMediaServer=AxisMediaServer:createAxisMediaServer --Ice.Config=config_AxisMediaServer

IceBox.InstanceName=AXIS.192.168.0.5

IceBox.LoadOrder=AxisMediaServer

Ice.Default.Locator=IceGrid/Locator:tcp -h locator.ip -p 4061

En este fichero deberíamos configurar el nombre del fichero pásado en la primera línea a nuestro servicio, si tuviera otro diferente, y el proxy del Ice.Default.Locator de la última línea. El nombre de instancia de IceBox no es problemático, pero si convendría adaptarlo a nuestro escenario.

El segundo fichero de configuración contendría información relativa a nuestro entorno:

AxisMediaServerAdapter.Endpoints=default

AxisMediaServer.IP=192.168.0.5

AxisMediaServer.User=user

AxisMediaServer.Password=pass

PropertySetFactory.Proxy=PropertySetFactory @ AutoPropertyService.Adapter

Ice.Default.Locator=IceGrid/Locator:tcp -h locator.ip -p 4061

Al igual que en el ejemplo anterior deberemos adaptar la configuración del Default Locator y, en este casi, de la propiedad "PropertySetFactory.Proxy". Para tener funcionando este servicio de propiedades podemos recurrir a la documentación del paquete libpropertyservice33.

Usando IceGrid y plantillas

Utilizando ZeroC Ice, existe la posibilidad de utilizar IceGrid. Esta utilidad es un servicio avanzado del middleware para la administración de grids de nodos que ejecuten diferentes servicios.

En el paquete libaxismediaserver se incluye un fichero template.xml. Este fichero puede abrirse utilizando IceGrid-Gui y utilizar las plantillas en él definidas para copiarlas a una aplicación dentro de nuestro registry.

La ubicación de dicha plantilla es la siguiente:

/usr/share/doc/libaxismediaserver/samples/template.xml

Esta mañana nos hemos venido mi bien y fiel amigo Manuel y yo a Albacete a la final del Concurso y a las actividades relacionadas. Un día de software libre en plan hermandad, comilona por la cara y claro, la presentación del proyecto.

He sido el primero, rompiendo el hielo, con dos.... y ha ido bien, pero siempre se puede mejorar. Como primera exposición con bastante gente delante de mi vida no me puedo quejar, aunque me dejé un par de cosas en el titnero que me hubiera gustado decir.

Me llevo para casa un premio, el de mejor utilidad. ¡Me siento muy orgulloso!

El ganador ha sido el proyecto Tivio de otro culipardo (Ángel Guzmán, a.k.a. Shakaran). ¡Felicidades amijo!

Por el Twitter llevo todo el día actualizando, así que para enteraros de algo... allí estoy

Escribo hoy, festivo en Ciudad Real, para deciros que me han seleccionado como finalista del Concurso Universitario de Software Libre de Castilla-la Mancha.

Es todo un honor y una alegría poder ir a Albacete a pasar un día con amigos del Software Libre. Además, las charlas que han preparado tienen muy buena pinta.

Las presentaciones de los 6 proyectos finalistas empezarán a eso de las 12, pero la mañana estoy seguro de que empezará mucho antes con algunas charlas que seguro que me encantan (Android, ¡allá voy! :D)

Bueno, solo pido que me deseéis suerte con la presentación de Argos. ¡Espero no ponerme muy nervioso!

Cuando terminé el MediaServer, que comenté hace unas cuantas entradas, empecé a desarrollar el MediaRender.

MediaRender pretendía ser algo muy parecido al MediaServer y que lo complementa: el MediaRender representaría de alguna forma en otro sitio lo que el MediaServer estaba distribuyendo.

Empecé a programarlo siguiendo una estructura casi igual que la del MediaServer: un servicio IceBox que, por un lado, anunciara en un canal de eventos al objeto y, por otro, lidiara con la representación del flujo. Conseguí hacerlo en poco tiempo, reutilizando mucho código del que estaba escrito para el MediaServer (aunque con bastantes arreglos menores) y conseguí poner en marcha un MediaRender basado en Gstreamer que fuera capaz de crear una ventana a pantalla completa y representar el flujo enviado por el MediaServer de Axis que ya tenía.

Tras verlo en funcionamiento, y a sugerencia de mi director de proyecto David Villa, empecé a desarrollar algo similar en Python: un MediaRender que también iba a usar Gstreamer pero que sería completamente diferente en cuanto a utilización por parte del usuario.

A diferencia del primer MediaRender, escrito en C++ como servicio IceBox, este nuevo sería en Python y la parte relacionada con Ice sería más simple. La forma de utilizar uno y otro se diferencian de forma drástica: mientras el servicio IceBox estaba pensado para ejecutarse en la sesión del usuario, de forma transparente para él (y sin ningún control por su parte), el MediaRender hecho en Python sería un applet de escritorio de Gnome, de forma que ofreciera al usuario algún tipo de control sobre el programa (por ejemplo, arrancar o detener el servicio, tiempo entre anunciamientos, modo ventana/pantalla completa...).

Ambos sabores de MediaRender están disponibles, aunque por razones de tiempo, para el Concurso de Software Libre no pude realizar la parte de applet de escritorio para Gnome como tenía pensado, así que por ahora se trata tan solo de una aplicación de escritorio sin demasiadas posibilidades de configuración.

Ésta será una de las líneas a seguir durante los próximos días en el desarrollo de Argos, así que no os extraéis si en pocos días tengo novedades al respecto.

¡Saludos!

Dentro de la evaluación del Concurso Universitario de Software Libre se pide una documentación sobre el proyecto, en la que se explique su filosofía, objetivos, puesta en marcha...

Publico aquí la documentación, por si alguien además de los evaluadores quisiera verla. Estoy abierto a todo tipo de comentarios. ¡Participad!

Documentación de Argos

He aprovechado hoy para hacer un vídeo demostrativo del funcionamiento de mi proyecto para ayudar a los evaluadores. Soy consciente de que, debido al estado de desarrollo actual, muchas de las herramientas que permiten utilizar de forma sencilla mi proyecto aún no están hechas, por lo que he pensado que sería un buen material de apoyo.

Enlace al vídeo en más calidad

En el transcurso del vídeo, primero se observa el canal de anunciamientos, dónde tanto un sumidero como una fuente están enviando sus mensajes de anuncio.

Tras ello, se utiliza la propia herramienta como sumidero de vídeo para conectarse con la fuente que está funcionando. Por último, el vídeo muestra como conectar la fuente a otro sumidero, que se está ejecutando en la misma máquina, representando el flujo de vídeo en una ventana independiente.

En el vídeo se puede observar que se utiliza una herramienta gráfica, llamada Twinpanel, para inspeccionar el canal de eventos y como sumidero multimedia. Esta herramienta ha sido fruto de varios años de trabajo de varios miembros del laboratorio ARCO entre los que me incluyo.

Justo para la evaluación del concurso ha llegado la primera versión del "configurador" de flujos de Argos. Desde luego, no es ni mucho menos lo que espero que llegue a ser (por ahora solo es un programa en terminal), pero es el primer paso.

El programa permite, dados los proxies de dos objetos MMDevice (un "source" y un "sink", como por ejemplo el Media Server y el Media Render), que ambos se conecten y tener el objeto de control de dicho flujo fuera de ambos extremos...

Aunque bueno, quizá me he metido a detalles muy "profundos". Espero que, si me seleccionan para la fase final, pueda llevar algo menos "tedioso" de utilizar que esta primera aproximación para poder realizar una demo "in situ" en condiciones.

P.S. Mañana es la evaluación de los proyectos en el concurso de Castilla-la Mancha. ¡Deseadme suerte!

aunque se me ha olvidado comentarlo, de forma paralela al desarrollo del Media Server se ha realizado el del Media Render.

Las diferencias entre ambos son pocas, ya que según el estándar de OMG AVStreams que estoy utilizando, los dos extremos de un flujo tienen las mismas interfaces y, a grandes rasgos, se comportan de forma muy parecida.

Para el Media Render una de las cosas que he debido tener en cuenta ha sido, ante todo, la posibilidad de tener diferentes "Renderers" que hagan diferentes cosas (representar el vídeo, guardar a fichero...).

Por ahora he implementado un Media Render que utiliza Gstreamer para representar el flujo recibido, pero he dotado al sistema de una especie de sistemas de plugins (usando el patrón factory method) para tener más fácil el desarrollo futuro de otros Media Renders diferentes.

Otra cosa a tener muy en cuenta es el tema de despliegue; en la entrada anterior comenté que el despliegue del Media Server lo realizo gracias a IceGrid y IceGrid-Gui. Por desgracia, el MediaRender es muy dependiente del usuario que lo ejecuta, por lo que la automatización de la puesta en marcha del Media Render habrá que estudiarla un poco más despacio.

Como ya comenté hace algunas entradas, gracias a mi trabajo descubrí algunas herramientas avanzadas de Ice. Entre ellas está IceGrid, que permite realizar despliegues de aplicaciones de una forma sencilla. Además, aporta transparencia de localización y la activación automática de servidores.

Gracias a IceGrid, el Media Server se puede lanzar en un nodo del sistema, configurándolo todo de forma remota desde el editor gráfico Icegrid-Gui.

IceGrid además permite tener plantillas para las aplicaciones, por lo que he podido definir un servicio IceBox para mi Media Server configurable a través de unos pocos parámetros, lo que permite su rápido despliegue en cualquier entorno.

Hoy voy a hacer una pequeña introducción al que va a ser uno de los grandes hitos de mi proyecto: el MediaServer.

Se tratará de un servicio "icebox", desplegable usando "icegrid", que permitirá anunciar en el entorno todo tipo de fuentes de vídeo. Por ejemplo, servirá para anunciar al entorno cámaras IP que no puedan anunciarse por si mismas, webcams o incluso servir ficheros de vídeo.

La idea es hacerlo suficientemente genérico para que pueda abarcar toda esta cantidad de dispositivos.

¿Qué no sabes que es icegrid ni icebox y esta entrada te suena un poco a chino? Tranquilo, ya explicaré con más detalle este tema, solo quería dejar constancia de que el proyecto sigue viento en popa :)

Como ya comenté, compagino la elaboración de mi PFC con mi trabajo dentro del grupo ARCO, lo cual hace que, en ocasiones, pueda dedicarle menos tiempo del deseado al proyecto.

Pero en otras muchas ocasiones este trabajo me permite aprender sobre herramientas que me pueden ser de muchísima utilidad en el proyecto, cómo ha ocurrido en estos días pasados con IceGrid.

IceGrid es uno de los servicios avanzados que proporciona ZeroC dentro de su middleware Ice. Según el manual de Ice, IceGrid es un servicio importante para construir herramientas robustas.

De una forma más coloquial, se puede decir que IceGrid es un servicio que permite desplegar aplicaciones en una serie de nodos de forma transparente, sin tenerte que preocupar nada más que de tener lista la aplicación, su configuración y poco más.

Claro, decir esto es simplificar en demasía: para que esto fuera así deben entrar en juego otros "actores" como IcePatch2 (que permite enviar los ejecutables a los nodos desde un servidor) o "icegrid-gui", que es una aplicación que permite configurar el nodo "registriy" (una suerte de director de orquesta) y decidir que aplicaciones se despliegan y dónde de una forma rápida e intuitiva.

De todos modos esto es un claro ejemplo que nunca se pierde el tiempo si aprovechas para aprender cosas por el camino. Está claro que para mi PFC IceGrid va a desempeñar una función principal para simplificarme la distribución de los nodos de mi sistema por la red.

Bueno, parece que he tenido suerte y entregué el anteproyecto justo cuando la comisión académica iba a reunirse para estudiar las solicitudes.

Ya tengo el anteproyecto aceptado, por lo que en teoría ya puedo ponerme con él (aunque ya estuviera puesto).

[ironic]

¡Ah! Estos temas burocráticos que tanto me gustan...

[/ironic]

Tras un par de semanas escribiendo el anteproyecto para presentarlo en mi facultad, ya está hecho y presentado. La solicitud de estudio del mismo la presenté el 14 de Enero.

En el anteproyecto he hecho una presentación del estado general de la cuestión: la necesidad tener mejores mecanismos de interacción y comunicación entre dispositivos multimedia, debido al crecimiento que ha sufrido el mundo en este ámbito durante los últimos años (teléfonos, videoconsolas o hasta despertadores...).

En el anteproyecto también he querido darle una utilidad práctica dentro del mundo de la enseñanza, ya que al fin y al cabo este documento trata sobre "vender la moto" para que valoren de forma positiva que tu "pierdas" tu tiempo en hacer ese trabajo.

En el documento también explico la metodología de trabajo que voy a seguir. En principio, RUP, aunque debido a la naturaleza modular del proyecto, que estará compuesto de muchas "piezas" que funcionarán juntas, puede que en alguna de esas "piezas" se utilice alguna otra metodología (como TDD, que personalmente a mi director de proyecto y a mi nos gusta bastante, pero no es aplicable en algunos de los elementos del proyecto).

Cómo ya hice en mi post sobre selección de herramientas, en el anteproyecto también he hablado de los lenguajes y herramientas que voy a utilizar.

Dado que el PFC lo estoy haciendo en mi ámbito de trabajo (el grupo de investigación ARCO) voy a disponer de algunos recursos, sobre todo hardware, que me permitirán desarrollar algunas cosas interesantes, como un servidor de medios de cámaras AXIS, otro para cámaras web que usen Video For Linux... y en fin, muchos aparatitos donde implementar partes de mi sistema de cara a una buena demostración.

¡Ah! Se me olvidaba. El anteproyecto está hecho usando LaTeX, y la futura documentación del PFC también lo estará...