Estos últimos días han sido vertiginosos: LibGoo es oficial; Iván está presionándolo a sus límite haciendo ya audio/video playback; veo bugs por todas partes; me da pánico que pase a testing y que todo truene; los reportes de defecto están acumulándose; la nueva asignación de escribir release notes...

Hagamos una pausa.

LibGoo es una capa de abstracción de software sobre OpenMAX IL, que utiliza GObject y su orientación a objetos para establecer una jerarquía de clases, donde los componentes multimedia pueden ser probados de manera autónoma. La API de LibGoo mimetiza la API de GStreamer reduciendo así el diferencial de impedancia entre la semántica de GStreamer y la de OpenMAX IL.

El primer esfuerzo por hacer una capa de abstracción a OpenMAX IL fue echa por Gomx, cuyo objetivo es ser un envoltorio delgado a OpenMAX IL simplificando el desarrollo de elementos de GStreamer. Felipe Contreras, el programador de Gomx, se fue a un mejor lugar (Finlandia) trabajando para Nokia. Felipe ha empujado gst-openmax, un plugin de GStreamer, integrando Gomx (y adelgazándolo más), basándose en la implementación de Bellagio.

LibGoo lo escribí por una mera comezón que ya traía desde que estaba en testing, sin más objetivo que "a ver dónde llega esto". Pronto tuve pruebas unitarias del componente del MP3 decoder. Cabe mencionar que en el proceso aprendí mucho sobre bibliotecas dinámicamente enlazadas, autools, GObject, gtk-doc y muchas cosas divertidas más. Sólo por eso valió la pena el esfuerzo. Poco tiempo después surgió gst-goo, que es un plugin de GStreamer que contiene elementos que ejecutan componentes de OpenMAX IL envueltos por LibGoo. Huelga mencionar que el primer elemento de GStreamer que funcionó fue el MP3 decoder. Fue aquí donde probé mis ideas de búfers fantasmas en GStreamer y un DASF sink (reproductor de audio).

Pronto Iván comenzó a contribuir al código de LibGoo y sacó el componente de MPEG4 decoder y el PostProcessor (visualizador de vídeo). Luego tuve los componentes de la cámara y el JPEG encoder. LibGoo contó con detractores, que a base de discursos quisieron convencer de su futilidad, y que Gomx era el camino a seguir. En esos días llegó Jamie para ver qué estaba ocurriendo. Una semana de 4 horas diarias perdidas en juntas, un par de ellas dedicadas al problema goo/gomx, sin llegar a ninguna resolución clara, aunque la tendencia era irse por LibGoo, a pesar de los grandilocuentes discursos. Me llama la atención los argumentos recibidos en contra de LibGoo, que tal vez valga la pena traer a colación: El punto esencial es que LibGoo ya tenía implementado soporte para el reloj de OMX y para hacer túneles entre componentes, mientras de Gomx nunca lo contempló. Para rebatir esto, los detractores decían "pero lo puede tener...". Lo más curioso de esto es que nunca hizo algo para que "lo tuviera", más bien daba a entender "háganlo y lo tendrá". Y a esto lleva a una frase de Linus Torlvads: "chat is cheap, show me the code". Los grandilocuentes discursos tienen poco que hacer frente al trabajo realizado que demuestra promisorios resultados. En otras palabras, cállate y demuéstramelo.

Se fue Jamie y yo seguía presionado por demostrar algo más formal con LibGoo/gst-goo que méramente un par de gst-launch simples. Y todavía sigo. El plan es hacer un GstGooPhotoBin, donde se tenga un túnel entre la cámara y el JPEG encoder para hacer una aplicación de cámara fotográfica.

Hoy llegó la resolución de Jamie: LibGoo es el camino a seguir, pero, aprovechando que Gomx y LibGoo pueden coexistir gracias a un cambio que hicieron en OpenMAX, se hará de manera gradual, tratando de evitar que caiga la razón de aprobación por parte del grupo de testing.

¿Estoy feliz? No creo. Contento de que el trabajo realizado halla sido reconocido, pero más preocupado por la responsabilidad que eso implica. Es ahora donde mis pesadillas de desempeño y sincronización de audio/vídeo se vuelven realidad. No es tiempo de echar las campanas al vuelo, sino de seguir extrapolando esta necedad mía, con mucho trabajo por delante.

Esta ha sido una buena y aleccionadora experiencia en el mundo de la programación profesional y les debo mucho a los detractores como a los colaboradores tempranos.

Lo malo ahora son los documentos técnicos, los release notes y los design descriptions, que de acuerdo a los estándares deben estar en formato MSWord, el cual es poco menos que abominable, con una plantilla que luce bonita, pero se come todos los recursos de OpenOffice. ¿Dónde quedó el maravilloso Latex? La gente no entiende las que las curvas de aprendizaje pronunciadas generalmente pagan buenos dividendos.

El domingo me largo a Matacanes.