Archivo por años: 2008

RealMedia sin RealPlayer

Por casualidades de la vida tengo una película en formato RealMedia (.rm), pero no era capaz de reproducirla. MPlayer, mi reproductor favorito (es el único que se puede controlar completamente desde teclado) se negaba a mostrar el vídeo, sólo reconocía el audio.

Me harté de buscar en google y en todas partes decían lo mismo: si tenía los w32codecs instalados debería poder reproducir archivos .rm sin problemas. Pero a la vez mucha gente se quejaba de que los tenía instalados y ni con esas (como era mi caso).

Los volví a bajar de la página oficial, probé con otros reproductores… y nada. Al final ya me veía resignado a utilizar el RealPlayer para Linux, pero su interfaz me tiraba para atrás. Hasta que echando un vistazo a la salida de Mplayer encontré un mensajito de error en el que no había reparado antes:

 Error: libstdc++.so.5: cannot open shared object file: No such file or directory

Y efectivamente: un simple sudo apt-get install libstdc++5 resolvió el problema.

Por si le sirve a alguien más.

Parecidos razonables

Mientras termino de recuperarme de una recaida de mis adorables cervicales, aprovecharé para subir una entrada que tenía escrita desde hace tiempo. Y es que a veces uno encuentra cosas divertidas o curiosas en la vida real, como por ejemplo el famoso Quick Stop de Clerks (el cartel de la derecha)… pero en Valencia (a la izquierda):


Otro caso es el parecido entre el logo de Nvidia, famosa por sus tarjetas gráficas, y el de una empresa de gestión, promoción y construcción cuya furgoneta encontré en Vigo mientras daba un paseillo, y cuyo nombre he decidido omitir:


Por último, cabe destacar el curioso parecido entre el fondo por defecto de Ubuntu (a la derecha), y el que aparece en la promoción de reproductores de DVD de una conocida marca de foagrás (o foie gras para los puristas) a la izquierda. La foto la hice con mi viejo móvil, por eso tiene tan poca calidad.

¡Y yo que renegaba de los móviles con cámara de fotos!

Enmendando errores

La nueva versión de DeVeDe intenta subsanar un serio problema que se coló en la versión 3.7. Por consejo de un usuario añadí un parámetro extra: VRC_MINRATE. Se supone que permite especificar la tasa mínima de vídeo, y con ello asegurar que el tamaño final del disco sea más ajustado a la realidad. Por desgracia el resultado no fue el esperado: el tamaño final era siempre mayor que el que tendría sin él. En mis pruebas no supuso un problema porque, sin él, el tamaño final era mucho menor del estimado, por lo que al añadirlo parecía que se ajustaba más a la predicción. Por desgracia varios usuarios se encontraron con imágenes ISO mayores que el tamaño del disco, lo que empañó la opción de cálculo automático de las tasas de vídeo. En la nueva versión 3.9 lo he eliminado, y las cosas han vuelto a su cauce.

Aparte de ésto hay algunos cambios interesantes: para empezar consigo más compatibilidad gracias a que ahora uso imágenes con transparencias para los menús, en lugar de un color clave. Por desgracia tiene su lado malo, y es que se pierde el antialiasing en las fuentes.

Otra novedad es que recuerda el directorio desde el que se añadió un fichero, con lo que añadir subtítulos o más ficheros que estén en el mismo directorio es mucho más cómodo.

También corregí la detección del número de núcleos, usando la técnica comentada en el último artículo de programación. Ahora debería irle bien a todo el mundo.

A disfrutarlo, señores! (y señoras 🙂 )

Núcleo duro

En la última versión de DeVeDe añadí por fin soporte para multithreading en Mencoder. Por desgracia no es algo tan simple como decirle «Usa threads», sino que hay que decirle cuantos queremos usar.

Alguno dirá: «¡Pues tantos como núcleos tengamos en nuestro ordenador, por supuesto!»

Y efectivamente, esa es la respuesta. El problema viene cuando queremos saber cuantos núcleos tenemos en nuestro ordenador. La primera solución que consideramos es leer /proc/cpuinfo y contar el número de veces que aparece la palabra processor. Por desgracia la cosa no es tan sencilla por culpa de un infame invento de Intel: el HyperThreading. Esta tecnología lo que hace es simular dos núcleos en procesadores de un único núcleo.

Los procesadores actuales no siempre ejecutan las instrucciones en el mismo orden en que están escritas en la memoria, sino que pueden enviar antes algunas que están después, siempre y cuando no dependan de los resultados de ninguna instrucción anterior. Esto permite aprovechar mejor tiempos muertos en la ejecución de instrucciones (por ejemplo, el tiempo que tiene que esperar una instrucción de carga a que llegue un dato desde la memoria). Pues bien, la mayor independencia de instrucciones se da entre procesos diferentes: es posible entremezclar las instrucciones de dos procesos cualesquiera sin que haya riesgo de dependencia, precisamente porque son completamente independientes (valga la redundancia). Los ingenieros de Intel lo entendieron rápidamente y se les ocurrió que podrían llenar huecos en la ejecución de un proceso con instrucciones de otro, aprovechando así al máximo las distintas unidades funcionales del procesador. Desde fuera el procesador parecería tener dos núcleos, y así lo verían los sistemas operativos, cuando en realidad sólo habría uno. Esto permitía incluso no tener que modificar nada en el software.

Sobre el papel la idea parecía muy prometedora, y de hecho Intel afirmaba que se conseguían aumentos de rendimiento de hasta el 30%. Pero en la práctica no sólo era raro acercarse a dicha cifra, sino que había veces que las aplicaciones iban incluso más lentas. La razón no residía en el hyperthreading en sí, sino en su interacción con el Replay System de los procesadores Pentium 4 (que son los únicos que, hoy por hoy, incorporan HT). En X-bit labs explican muy bien en qué consiste, así que no lo repetiré aquí porque quedaría muy largo y peor explicado.

¿Y qué ocurre en el caso particular de Mencoder? En general la gente no se pone de acuerdo. Algunos aseguran que no hay ninguna mejora, pero que tampoco empeora, mientras que otros afirman que va peor si se utilizan multiples hilos. Ante la duda decidí tomar la opción conservadora, lo que implica calcular con precisión el número real de núcleos. Por desgracia no he encontrado una manera «oficial» de saber esa cantidad, sino que hay que deducirla de los datos que ofrece /proc/cpuinfo. Para entender bien la nomenclatura me referiré como procesador a cada uno de los chips que hay en un ordenador, como núcleo real a cada uno de los núcleos físicos de un procesador, y como núcleo virtual al número de núcleos que cree ver un sistema operativo. Así, en un sistema con dos procesadores, en el que cada uno hay dos núcleos, tendremos un total de cuatro núcleos reales. Si encima todos tienen HyperThreading, tendremos un sistema con ocho núcleos virtuales.

Estos son los cuatro parámetros importantes en un sistema con múltiples núcleos y/o procesadores:

  • Physical id: identificador único de cada procesador (chip).
  • Core id: identificador único de cada núcleo real dentro de un mismo procesador.
  • Cpu cores: número de núcleos reales en este procesador.
  • Siblings: número de núcleos virtuales en este procesador.

A la vista de estas definiciones podría parecer que basta con contar el número de combinaciones diferentes de Physical id y Core id para saber cuantos núcleos tenemos. Eso hice en la versión 3.8 de DeVeDe y el batacazo no tardó en llegar: un usuario con un procesador AMD Phenom (cuatro núcleos) se quejaba de que sólo usaba un núcleo.

Tras recibir una copia de su /proc/cpuinfo la sorpresa fue mayúscula: ¡las cuatro entradas processor tenían exactamente el mismo Physical id y Core id, y el número de cores en cada una era uno en lugar de cuatro!

Era necesaria una nueva aproximación al problema, así que recopilé las descripciones de todas las máquinas que pude, lo que complicó aún más la cosa porque los valores bailaban y diferían mucho de lo que sería lógico: en sistemas con dos núcleos Cpu cores vale 2, pero en el sistema con cuatro núcleos sólo vale 1. Lo mismo ocurría con el valor de Siblings. Probé varias aproximaciones, cada cual más complicada, hasta que encontré la solución: cada entrada en cpuinfo se corresponde con un núcleo virtual, así que basta con calcular a qué porcentaje de un núcleo real se corresponde. Ese valor lo obtenemos con el cociente entre Cpu cores y Siblings.

En efecto, en mi procesador Athlon X2 y en un Intel Core 2 Duo, Cpu cores y Siblings valen ambos 2 en cada entrada processor, con lo que 2/2=1. En el procesador Phenom de cuatro núcleos ambos valen 1 en cada entrada, con lo que 1/1=1. Pero en un procesador con HyperThreading Siblings vale 2, mientras que Cpu cores vale 1, con lo que 1/2=0,5. Cada entrada processor cuenta como medio núcleo en la máquina con HyperThreading, mientras que en el resto de sistemas cuenta como un núcleo.
¿Y qué pasa en una máquina con un sólo procesador de único núcleo? Pues que no aparece ninguna de esas dos entradas, por lo que hay que asumir que Cpu cores y Siblings valen 1 salvo que aparezcan en la descripción del procesador.

Así pues, basta con ir sumando el cociente entre Siblings y Cpu cores para cada una de las entradas para, al final, obtener el número de núcleos reales del sistema. Este es el sistema que usaré en DeVeDe 3.9, que saldrá dentro de unas semanas.

¡Houston, tenemos un problema!

Al poco de sacar la versión 3.8 de DeVeDe ya he tenido que lanzar la 3.8b para corregir dos fallos en la traducción a italiano y polaco, lo suficientemente graves como para que no funcione el programa 🙁

Tendré que buscar alguna solución para que los traductores puedan probar los ficheros antes de enviármelos. Así evitaremos este tipo de problemas en futuras versiones. El problema es que no quiero enviarles por correo el tocho completo de la nueva versión. A lo mejor a alguno no le hace gracia recibir un mastodonte de más de un mega por sorpresa.
A ver qué se me ocurre.

De dos en dos

Hoy he lanzado dos nuevas versiones de manera simultánea. La primera es la versión 1.3 de HTMLProc, el preprocesador de HTML que utilizo para generar mi página web. Se trata de un cambio casi sin importancia: ya no da un Warning al usar enlaces dentro de la misma página (los famosos a h ref=»#…)

Y para los que se pregunten el por qué de usar un preprocesador, la respuesta es que simplifica un montón de detalles. Por ejemplo, permite hacer #includes de otros ficheros, cosa que, sin él, obligaría a copiar y pegar un montón de código repetido en cada página (y posiblemente teniendo que modificarlo de manera diferente en cada una de ellas), o usar PHP incluso para páginas completamente estáticas. Otro detalle que simplifica es la gestión de las rutas de cada fichero. En efecto, convierte todas las rutas de absolutas a relativas, lo que permite usar el mismo archivo de menús para todas las páginas, aunque estén en directorios diferentes. Por último, añade los campos width y height a las imágenes, con lo que la carga es mucho más eficiente cuando se usan conexiones lentas (vale que hoy en día no es algo tan útil, pues todo el mundo tiene ADSL o cable, pero cuando lo creé sí tenía mucho sentido).

Pasando a DeVeDe, los cambios son realmente muchos. El más visible es, sin duda, el nuevo sistema de menús. En esta nueva versión eliminé el feo recuadro rosa alrededor del título e hice que sea éste el que se ilumine. La razón de no haberlo hecho así al principio era que la imagen con la parte seleccionada tiene que tener un máximo de cuatro colores, cosa que con Cairo no es posible hacer directamente. Sin embargo, Mohojolder me envió un parche en el que conseguía hacer ésto usando convert, una de las utilidades de ImageMagick. Además movió el menú al centro de la pantalla. Aunque la idea era buena, el código no me convencía, así que decidí reescribirlo y, además, permitir que el usuario pudiese escoger donde colocar el menú (arriba, centrado o abajo), y los colores tanto del fondo como de las letras.

El segundo cambio importante es que ahora puede ajustar automáticamente la tasa de bits de los vídeos, de manera que ya no será necesario ir probando valores hasta que consigamos unos que llenen bien el disco. Este cálculo no se hace a la ligera, sino que se tiene en cuenta la resolución final del vídeo (dándole más tasa a aquellos que tienen más resolución), la tasa de audio, el número de subtítulos, y si el vídeo se está recodificando o simplemente copiando. Gracias a esta opción, crear un DVD será tan sencillo como arrastrar los vídeos a la ventana en cada uno de los títulos deseados, pulsar dicho botón, y la estructura estará lista para grabarse.

Y ésto nos lleva al siguiente cambio importante: el soporte de hasta 32 subtítulos diferentes. Ahora ya se pueden tener en un mismo vídeo los subtítulos en castellano, inglés y bielorruso. Además también se puede especificar la lengua en la que están cada uno de ellos, de manera que el reproductor nos lo indicará en pantalla.

Otra novedad muy solicitada es el permitir escoger el flujo de audio que se usará, cuando el archivo original contiene varios audios. Aunque muchos usuarios me piden poder generar discos con varias pistas de sonido, actualmente no es posible porque Mencoder no lo soporta (a menos que alguien del público sepa como hacerlo, claro…).

También permite rotar e invertir los vídeos. Esta opción hará las delícias de los usuarios que quieran pasar a un CD o DVD los vídeos hechos con su móvil y se encuentren con que lo tenían girado. A ésto hay que sumar el permitir mezclar en un mismo disco contenido en formato panorámico y normal, además de permitir generar ficheros DivX en Alta Definición (útil para aquellos que quieran recodificar ficheros Matroska en HD).

También añadí soporte para CPUs de varios núcleos. Este activa el flag de Mencoder que permite que éste use X núcleos en paralelo. Por desgracia, la ganancia no parece ser del doble, sino que está en torno a un 50% más.
Por último, ahora se pueden añadir parámetros extra no sólo del grupo de parámetros independientes, sino también en lavcopts, lameopts y vf. De esta manera es más fácil cambiar la matriz de cuantización u otras acciones.

El resto son novedades menores. Espero que lo disfruteis.

Valencia

Hace unos días estuve en la Guademy. Necesitaba tomarme un par de días de descanso para quitarme de la cabeza el trabajo y las molestias de cuello, y nada mejor que Valencia, a casi mil kilómetros de distancia y con un clima mucho más benigno que el de Vigo para mis cervicales. Un viajecito en avión con escala en los Madriles y directo para la Universidad Politécnica. La verdad es que se nota la diferencia con la de Vigo, aunque sólo sea porque allí todo es llano 🙂 A ver cuando pasamos el Bulldozer por aquí…

Hubo varias charlas, aunque las que más me interesaron fueron, sin duda, tres:

  • La charla sobre GTK 3.0: en ella, Carlos Garnacho nos explicó los grandes problemas que la compatibilidad binaria está suponiendo de cara a añadir nuevas funcionalidades en la versión actual de GTK. El principal problema es que, en muchos casos, se accede directamente a los datos de las estructuras que definen un widget. Eso, unido al sistema que usa Gobject para implementar la herencia obliga a que el orden de los elementos y el tamaño de éstas permanezca invariable. La solución actual consiste en reservar varios punteros, que apuntarán (valga la redundancia) a los nuevos datos que se necesiten en el futuro, con todos los problemas que ésto acarrea. Para solucionarlo de manera definitiva han propuesto convertir en privadas absolutamente todas las propiedades de los objetos que forman los widgets, de manera que cualquier acceso que se quiera hacer «desde el exterior» sea a través de métodos. De esta manera los programas simplemente trabajarán con un puntero a la estructura, sin importarles lo que haya dentro. Han elaborado además un plan de transición que facilite la migración de las aplicaciones.
  • La charla sobre el futuro de QT y WebKit. Aunque adoro GTK, reconozco que el metacompilador de objetos de QT es impresionante. Holger Freyther nos hizo una demostración de como usarlo para ampliar WebKit, permitiéndole acceder a objetos QT desde JavaScript con unas pocas líneas de código. Pero lo que más me gustó y sorprendió fue, sin duda, las nuevas capacidades de concurrencia de QT4, por su elegancia y simplicidad. La idea es aprovechar más los múltiples núcleos de los procesadores actuales, simplificando la creación de procesos concurrentes en los casos más habituales. El sistema que mostró era muy sencillo, pues sólo permitía repetir una misma misma tarea X veces de manera concurrente, cada una con un conjunto de datos diferente (el ejemplo era redimensionar todas las fotografías de una carpeta). Aunque es cierto que no permite hacer cosas complejas, como dependencias (el proceso C sólo debe ponerse en marcha cuando el A y el B hayan terminado), es cierto que es un primer paso hacia el aprovechamiento de los nuevos procesadores en el escritorio.
  • Por último, me gustó mucho la charla de Will Stephenson sobre el Akonade PIM, un gestor de datos personales para KDE con una interfaz DBUS. El problema actual en KDE es que un componente gestiona las direcciones de correo, otro las citas, etc, con lo que el acceso a los datos puede volverse muy lento si lo que se pretende es cruzarlos entre ellos. Además, al ser procesos independientes, el consumo de memoria se dispara. La solución propuesta es Akonade, un pequeño gestor de bases de datos que aglutina toda esa información en un único servidor, y permite hacer búsquedas muy complejas. Lo interesante es que lo que ha «estandarizado» es la interfaz DBUS en lugar del servidor en sí, de manera que ésta se podría implementar en, por ejemplo, Evolution, y los programas de KDE podrían acceder a los datos de Gnome y viceversa de manera sencilla.

Por supuesto, la segunda parte buena fueron las estupendas charlas informales con el resto de la gente en los descansos, durante las comidas, en la cena del sábado y en la playa el domingo. ¡¡¡¡Un saludo a todos!!!!

El resultado es que vengo cargado de nuevas ideas y ganas de seguir programando. Ahora sólo me falta encontrar tiempo material para ponerme 🙂

Volviendo poco a poco

Los que sigan mi blog habitualmente (De ilusión también se vive ¿no? Dejadme que me crea que me lee alguien) habrán notado que he estado más de cuatro meses sin publicar nada; ni entradas ni nuevas versiones. La razón es que en diciembre tuve un golpe con el coche (el clásico «alcance por detrás») que me dejó con un esguince cervical bastante aparatoso. En este tiempo varios usuarios me han enviado una serie de parches para SuperShow y DeVeDe, así que he aprovechado que parece que (¡por fin!) empiezo a estar algo mejor (aunque no todo lo bien que me gustaría) para aplicarlos y lanzar dos pequeñas versiones «rápidas».

Pasando ya a describir los cambios, en SuperShow apliqué varios parches que me envió Pablo Rodríguez. Para empezar, cambió los botones originales, hechos con mapas de bits, por botones vectoriales, con lo que la apariencia de éstos ha mejorado muchísimo. Por otro lado, añadió dos botones extra que permiten saltar directamente a la siguiente diapositiva o a la anterior, complementando a los que permiten avanzar o retroceder la presentación cinco segundos. Por último, también retocó el icono del programa y lo añadió a la ventana de Acerca de y a la barra superior del resto de ventanas. Por mi parte, corregí un pequeño bug que había al volver a reproducir una presentación con el botón correspondiente: al pulsarlo saltaba a la segunda diapositiva en lugar de a la primera.

En el tintero se han quedado dos añadidos muy interesantes. El primero es un contador de tiempos y de diapositivas. Las razones para no ponerlo han sido dos:

  • Para empezar,  el texto aparece algo cortado por la parte superior; Pablo aún no sabe por qué.
  • Por otro lado, la versión actual de SWFC (el compilador de FLASH que usa SuperShow) no soporta añadir sólo un subconjunto de símbolos de una fuente de letras, sino que hay que meter absolutamente todos los que están disponibles en el fichero TrueType, con lo que el tamaño de las presentaciones se dispara. Esto está corregido en la versión de desarrollo, por lo que pronto deberíamos poder incluirlo.

El otro añadido es cambiar el código de renderizado de las diapositivas para que use LibPoppler. La principal razón de no haberlo hecho es que no he conseguido compilar PyPoppler en mi sistema. Cuando esté completamente recuperado me pondré con ello.

Un detalle bastante triste es que se ha perdido la compatibilidad con Gnash. Hicieron algún cambio en el código justo antes de sacar la actual versión estable, y el resultado es que los métodos getDuration y getPosition no funcionan cuando se usa Gstreamer como backend (sí funcionan si se usa SDL). Ya avisé del error y espero que lo corrijan pronto.

Respecto a DeVeDe, había un fallo en la traducción a catalán que hacía que no arrancase cuando se usa esa lengua en el sistema. El traductor me envió un nuevo fichero .po que lo corrige. También apliqué una serie de parches que me envió Peter Gill para la versión de Windows (en Linux funciona bien). Por otro lado, si se cerraba la ventana inicial (la que pregunta el tipo de disco que se quiere crear) ésta desaparecía, pero el programa no se cerraba porque me había olvidado de añadir un callback. Ahora pregunta si queremos salir. Por último, hice un par de cambios en el cálculo de la tasa mínima de vídeo (por sugerencia de otro usuario), de manera que el tamaño final de la imagen de CD/DVD se acerca más al estimado por DeVeDe en la ventana principal.

Nota: ésta entrada la escribí el 17 de abril, pero por despiste la mandé a borradores en lugar de publicarla.