LongoMatch:The Digital Coach

Archive for the ‘Desarollo’ Category

Con un poco más de tiempo libre después de un mes muy ocupado, empiezo a trabajar en la nueva versión, la 0.16. Este versión va a suponer grandes cambios por varias razones…
En primer lugar pretendo cambiar el backend usado por el editor no linear, cambiando la actual implementación basada en FFmpeg y Mencoder, por GNonLin. GNonLin es un plugin para GStreamer que facilita la creación de pipelines para edición no linear. Esta decisión se debe a dos razones: mejorar el rendimiento del editor no linear y eliminar las dependencias con ffmpeg y mencoder basándose única y exclusivamente en GStreamer, lo cual permitirá, entre otras cosas, que longomatch sea aceptado en los repositorios oficiales de Debian.
Otra de las mejoras que quiero introducir es la posblidad de añadir hasta 40 categorías de marcado, y añadir marcado específico para jugares, pudiendo utilizar una foto del jugador para ello. Este cambio va a suponer un gran cambio en LongoMatch afectando a casi todos los componentes: base de datos, proyectos, plantillas, GUI, controlador de eventos, etc…
Entre las pequeñas mejoras, pretendo añadir la posibilidad de ajustar la velocidad reproducción prefijada en los elementos de una lista de repoducción, pudiendo exportarlos a cámara lenta también. Quiero además incluir la posibilidad de hacer un overlay de texto sobre el vídeo con información de la jugada.
En cuanto a mejoras de usabilidad, quiero añadir una función de hotkeys, para que el marcado de jugadas sea lo más rápido posible.
Pretendo que para finales de Junio/principios de julio esté lista la primera pre-release.
Un saludo!

Ayer me dí cuenta, haciendo una instalción de longomatch en un sistema “virgen” de ubuntu y debian, que había un error en el archivo debian/control .

En ambos sistemas operativos no incluía los bindings de db4o para C# como dependencia, lo cual generaba un error al ejecutar el programa al no encontrarse este componente.

Además, en debian sid se el componente Mono.Posix se distribuye en un paquete externo, teniendo que añadirlo como dependencia.

Otra cosa curiosa en debian sid, es que el compilador de mono se llama gmcs2, en vez de gmcs. He tenido que modifiar los archivos de autotools añadiendo una variable global llamada GMCS, que varía en función de la versión instalada de la siguiente forma en el archivo configure.ac:


AC_PATH_PROG(MCS, gmcs, no)
if test "x$MCS" = "xno"; then
AC_PATH_PROG(MCS2, gmcs2,no)
if test "x$MCS2" = "xno"; then
AC_MSG_ERROR([gmcs Not found])
else
AC_SUBST(GMCS,[gmcs2])
fi

else
AC_SUBST(GMCS,[gmcs])
fi

Después del éxito que ha tenido el sub-proyecto GStreamer-WinBuilds en la comunidad de desarrolloadores de GStreamer, he decido presentarlo al Google Summer of Code. Mi propuesta es trabajar junto con el equipo de GStreamer para facilitar el desarrollo de GStreamer en Windows, lo cual pasa por 3  importantes puntos:

  1. Automatizar la creación de un  entorno de compilación con todas las depencias externas del proyecto GStreamer para facilitar la compilación de los plugins externos a GStreamer.
  2. Portar todos los proyectos existentes de Visual Studio a Code::Blocks, un IDE multiplataforma y de Software Libre, para no depender de Visual Studio
  3. Finalizar el trabajo empezado con GStreamer-WinBuilds y crear un instalador con todos los plugins existentes en GStreamer.

Ahora sólo falta que el equipo de GStreamer lo considere de interés!

Hace unas semanas ffmpeg anunciaba una nueva versión oficial, la 0.5, lo cual es una estupenda noticia teniendo en cuenta que la última versión databa de la era prehistórica. Estos últimos años el equipo de ffmpeg mantenía la rama trunk de desarrollo “estable”, de tal forma que compilar la última versión de ffmpeg era compilar la última revisión del repositorio. Parece ser que han cambiado de política y van a volver a lanzar una nueva versión de forma periódica, lo cual, en mi opinión, es una excelente idea.

La última actualización del módulo ffmpeg de GStreamer utiliza esta versión, la 0.5, y no puede usarse ninguna revisión posterior por los cambios introducidos en avutil. Como siempre, he descargado el tarball y me he puesto a compilar…. Todo perfecto, pero a la hora de ejecutar me salta un horrible error:

“The application failed to initialize properly (0xc00000005). Click OK to terminate the application”

Esto supone un gran contratiempo, ya que no podré incluir la actualización de este módulo en GStreamer-WinBuilds. Además, a primera vista, es un error al que no se le puede dar suloción
Indagando en las listas de correo de ffmpeg, resulta que el enlace dinámico con avutil y avcodec está roto en Windows, por lo que sólo se puede enlazar estáticamente con dichas librerías. Esta noche intentaré configurar el proyecto gstffmpeg de Visual Studio para enlazar estáticamente utilizando las librerías de MinGW.

Son muchas las distribuciones que he probado en mi vida, pero hay una que me enamoró desde el principio… Debian.  Me encató la forma en que se gestionan los paquetes mediante apt-get y como se organizaba la distribución en distintas ramas según la estabilidad de los paquetes. Venía de Windows, donde era impensable instalar cualquier programa con un simple comando, y mi paso por redhat fué un poco frustante, ya que por esa época rpm todavía no gestionaba las dependecias de los paquetes. Por esa razón, una de mis grandes ilusiones fue la de tener un programa en los repositorios oficiales de Debian.

Al presentar LongoMatch al concurso universitario de Software Libre y ver que el programa estaba funcionando bien, se me pasó por la cabeza empezar a buscar la forma para incluirlo en Debian, y así es como descubrí Debian Mentors. Debian Mentors es un repositorio de paquetes público, a través del cual se ofrece la posibilidad de incluir paquetes en los repositorios oficiales sin ser un “Debian Developer”.

Los “Debian Developers” son los únicos que pueden subir paquetes a los repositorios oficiales, y debian mentors ofrece un punto de enlace entre los aspirantes y los “Debian Developers”. Así que la forma que tenemos los desarrolladores ajenos al proyecto Debian de conseguir ver nuestros paquetes en Debian es consiguiendo un “Sponsor”, es decir, un “Debian Developer” que revise el paquete, le dé el visto bueno y lo suba por nosotros.

El proceso es bastante simple:

  1. Creas una cuenta en debian mentors
  2. Subes tu paquete
  3. Buscas un “Sponsor”
  4. Sigues las recomensaciones de tu “Sponsor”
  5. Con un poco de suerte tu paquete será incluido en los repositorios de Debian.

El termino DLL Hell se refiere a los problemas ocasionados por las dll en Windows. El “infierno” ocurre cuando:

  • Una instalación sobreescribe una biblioteca con otra versión, dejando en algunos casos los porgramas que enlazaban con ella inservibles.
  • Una desintalación borra una biblioteca compartida.

El DLL Hell se ha intentado corregir por parte de Microsoft con los “side-by-side  assemblies”  (SxS) que permiten a una aplicación selecionar una versión específica de una dll.  En que consiste esto? Pues tiene una fácil explicación: en el manifest de la aplicación se especifica la dll que vamos a usar y su versión, de tal forma que cuando se vaya cargar dicha dll, se buscará el ensamblado con la versión especificada en el manifest. El problema es que se buscan las dll’s en un caché de ensamblados y si no está, la aplicación muere al no poder cargarla. Ahora ya no se puede simplemente copiar esa dll a cargar en el directorio en el que está el ejecutable (esto daría lugar al famoso DLL Hell), sino que tiene que estar registrada en el caché

Esto deriva en nuevo problema: el Manifest Hell. ¿Qué pasa si compilamos una aplicación con VC2008, enlazando con el CRT de Windows, es decir, con msvcr90.dll? La aplicación tendrá un manifest de este tipo:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>

Cómo se observa en la sección dependentAssembly, la aplicación buscará el ensamblado Microsoft.VC90.CRT de versión 9.0.21022.8 , el cual no se distribuye en por defecto en ningún sistema operativo de Windows. ¿Esto quiere decir que si compilo una aplicación con VC2008  no la puedo ejecutar en culauiqer máquina? La respuesta es NO, NO SE PUEDE. Este problema ha sido todo un infierno, de ahí el nombre Manifest Hell, en el despliegue de LongoMatch (y más específicamente de GStreamer) y me ha llevado un muchos de quevraderos de cabeza estos últimos meses. La solución de Microsoft es instalar en la máquina objetivo el Microsoft Redistributable Package, lo cual me parece una solución poco elegante al tener que recurrir a otro instalador.

El problema es que mi aplicación usa  GStreamer, cuyos binarios tengo que compilar con VC2008 (GStreamer no proporciona binarios para Windows y cada uno tiene que hacerlo a su manera, lo cual ha derivado en nuevo proyecto que está teniendo muy buena acogida en la  comunidad GStreamer).  La solución es más simple de lo que parece, pero estando muy mal documentada fué muy difícil de encontrar.

Antes he comentado que la busqueda de ensamblados se realiza en una caché de ensamblados SxS, pero existe una forma de distribuir copias privadas. Consiste en copiar el contenido de la capeta %PROGDIR%\Microsoft Visual Studio 9.0\VC\Redist\x86\Microsoft.VC90.CRT a la carpeta bin\ de nuestro programa. De esta forma, al lanzar el ejecutable principal y buscar el ensamblado Microsoft.VC90.CRT, encontrará en su directorio de ejecución una carpeta de nombre Microsoft.VC90.CRT con el contenido del ensamblado. Si la versión buscada coincide con la especificada en el manifest cargará la dll con éxito.

Problema Solucionado!

Introduction

Debian-like systems use APT, a free user interface that works with core libraries to handle installing software on Linux. Apt can be functionally considered to be a front-end to dpkg. While dpkg performs actions on individual packages, apt tools manage relations (especially dependencies) between them, as well as sourcing and management of higher-level versioning decisions (release tracking and version pinning).

For this guide I supose that your project uses the autotools buid system. That’s why I will use CDBS which is a tool that uses debhelper to make building and maintaining Debian packages even easier. It has many advantages:

  • It produces a short, readable, and efficient debian/rules.
  • It automates debhelper and autotools for you, so you do not have to worry about repetitive tasks.
  • It helps you focus on more important packaging problems, because it helps without limiting customization.
  • Its classes have been well tested, so you can avoid dirty hacks to solve common problems.
  • Switching to CDBS is easy.
  • It is extensible.

Configuration Files

The files needed to create .deb package are stored in the project’s  root directory with the following structure:
  • debian/changelog
  • debian/control
  • debian/copyright
  • debian/rules

changelog

The changelog file is, as its name implies, a listing of the changes made in each version. It has a specific format that gives the package name, version, distribution, changes, and who made the changes at a given time.

The first line includes the package’s name (longomatch) and the package’s version (0.9.1-1hardy1) followed by the distribution’s name (hardy)

The changelog for the longomatch package:

longomatch (0.9.1-1hardy1) hardy; urgency=low
   *Improved video editor
   *Added templates support
   *Added internationalization support

— Andoni Morales Alastruey Tue, 18 Nov 2008 23:50:00 +0200

control

The control file contains the information that the package manager (such as apt-get, synaptic, and adept) uses, build-time dependencies, maintainer information, and much more.

For the longomatch package, the control file looks something like:

Source: longomatch
Section: devel
Priority: extra
Maintainer: Andoni Morales Alastruey <my@mail.com>
Build-Depends: debhelper (>= 5), autotools-dev, cdbs, pkg-config, mono-gmcs,libdb4o6.0-cil, libgtk2.0-cil,libgstreamer0.10-dev, libgstreamer-plugins-base0.10-dev, libgtk2.0-dev, libmono2.0-cil, libmono-cairo2.0-cil
Standards-Version: 3.7.2
Package: longomatch
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, mono-runtime, ffmpeg, mencoder
Description: LongoMatch:The Digital Coach
Sports video analyze tool for coaches
and trainers to assist them  on making live video reports
from a match. It creates a database with the most
important plays of a game, grouped by categories, to easily
access them and to create play lists and new videos from the
selected plays.

copyright

This file gives the copyright information. Generally, copyright information is found in the COPYING file in the program’s source directory. This file should include such information as the names of the author and the packager, the URL from which the source came, a Copyright line with the year and copyright holder, and the text of the copyright itself. LongoMatch includes the following copyright file:

This package was debianized by Andoni Morales Alastruey <my@mail.com> on
Tue, 02 Sep 2008 03:04:08 +0200.
Upstream Author(s):
Andoni Morales Alastruey <my@mail.com>
Copyright:
Copyright (C) 2008 Andoni Morales Alastruey <my@mail.com>
License:
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
The Debian packaging is (C) 2008, Andoni Morales Alastruey <ylatuya@gmail.com> and
is licensed under the GPL, see `/usr/share/common-licenses/GPL'.
# Please also look if there are files or directories which have a
# different copyright/license attached and list them here.

rules

The last file we need to look at is rules. This does all the work for creating our package. It is a Makefile with targets to compile and install the application, then create the .deb file from the installed files. It also has a target to clean up all the build files so you end up with just a source package again. CDBS is a set of Makefile includes that uses debhelper to make building and maintaining Debian packages even easier. It uses advanced features of Makefiles to abstract the build process, so rules files end up primarily as a series of include statements. The final rules file using CDBS looks like this:

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

As you can see the rules configuration files is very simple. CDBS scripts delegate all the work to autotools.

Creating the binaries package

The next step is to build the binaries package and the sources packages which are built calling the following commands in the ./debian directory:

# debuild -b (to build the binaries package)

# debuild -S (to build the sources packages)

debuild will parse all the previous files and will create a .deb package


Descripción del proyecto

LongoMatch es un proyecto de Software Libre que proporciona una serie de herramientas para el análisis por vídeo. Está enfocado al deporte y ayuda a entrenadores y ténicos a realizar estudios de acciones a través del vídeo, permitiendo localizar y agrupar por categorías diferentes segmentos de una grabación para facilitar su posterior análisis. Su uso puede llegar a ser más genérico, pudiendo ser utilizado para realizar resúmenes de conferencias, estudios de películas o cualquier actividad que consista en localizar y estudiar partes concretas de una grabación. Para más información, visitad la página web del proyecto: www.ylatuya.es