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.