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.