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.
0 comentarios:
Publicar un comentario