LongoMatch:The Digital Coach

Archive for the ‘Windows’ Category

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.

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!


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