Compilar frei0r

 frei0r es un conjunto de filtros de vídeo. Efectos visuales y tal.

Para compilarlo en Cygwin, necesitaremos los paquetes gcc4-core, gcc4-g++, cmake.

Nos bajamos el código fuente, y lo desempaquetamos:
wget http://www.piksel.no/frei0r/frei0r-plugins-1.2.tar.gz
tar xvf frei0r-plugins-1.2.tar.gz

Se puede construir usando GNU autotools ( ./configure && make ) or CMake ( cmake . && make ).

Usamos CMake. El primer problema es que la versión del paquete cmake de Cygwin es 2.6, así que cambio la primera línea de CMakeLists.txt a esto:
cmake_minimum_required (VERSION 2.6)

Construímos los "makefiles":
CFLAGS=-march=core2 cmake .

Y a compilar. Como tengo un Core2, pues lo aprovechamos:
make -j 2

Para instalarlo:
make install

Y, como se han olvidado, también:
cp -p include/frei0r.h /usr/local/include/

Desde el 24-sep-2010, (SVN r25165), ffmpeg permite usar filtros de frei0r

Para construir ffmpeg con soporte para frei0r:
./configure --enable-frei0r

Antes de usar los filtros, conviene avisar dónde están:
FREI0R_PATH=/usr/local/lib/frei0r-1

Ejemplo de uso de un filtro:
./ffmpeg -i in.avi -vf "frei0r=water.dll:3.0:y:y:y:y:y:y" -y out.avi

Compilar para Windows desde Cygwin (IV)

Ya están disponibles en Cygwin los paquetes para compilación cruzada preparados por el projecto MinGW-w64, que generan código para Windows de 32 y de 64 bits.

Si queremos compilar ffmpeg para Windows de 32 bits, nos bajamos los paquetes:
mingw64-i686-binutils, mingw64-i686-gcc-core, mingw64-i686-headers, mingw64-i686-pthreads, mingw64-i686-runtime

La invocación de configure queda así:
./configure --enable-memalign-hack --arch=x86 --target-os=mingw32 --enable-cross-compile --cross-prefix=i686-w64-mingw32- --disable-shared --enable-static --disable-dxva2


Si queremos compilar ffmpeg para Windows de 64 bits, nos bajamos los paquetes:
mingw64-x86_64-binutils, mingw64-x86_64-gcc-core, mingw64-x86_64-headers, mingw64-x86_64-pthreads, mingw64-x86_64-runtime

La invocación de configure es ahora:
./configure --arch=x86_64 --target-os=mingw32 --enable-cross-compile --cross-prefix=x86_64-w64-mingw32- --disable-shared --enable-static --disable-dxva2

Lo de --disable-dxva2 es porque no uso la aceleración DXVA2 al decodificar h264.
DXVA 2.0 necesita Vista como mínimo (-D_WIN32_WINNT=0x0600), y activar las macros para que C maneje los objetos que normalmente se acceden desde C++ (-DCOBJMACROS), así que, si la queréis, usad --extra-cflags='-DCOBJMACROS -D_WIN32_WINNT=0x0600'.

Ojo con el punto y la coma

Los anglosajones usan el punto para separar decimales. Los españoles usamos la coma.
De vez en cuando, hay algún programa (suelen ser los que importan datos en CSV) que pide ir al Panel de Control y cambiar el separador de decimales de coma a punto.

Ojo, porque este acto, en apariencia inocente, confunde de mala manera a algunos programas escritos chapuceramente. Por ejemplo, al Administrador de Tareas de Vista:

A la izquierda el separador de decimales es coma, y a la derecha es punto

O igual es que así los programas consumen mil veces menos memoria ...

Mostrar entradas recientes

Encontré un JavaScript que muestra las entradas más recientes de una categoría:


<script type="text/javascript">
function recentpostslist(json) {
 document.write('<ul>');
 for (var i = 0; i < json.feed.entry.length; i++)
 {
    for (var j = 0; j < json.feed.entry[i].link.length; j++) {
      if (json.feed.entry[i].link[j].rel == 'alternate') {
        break;
      }
    }
var entryUrl = "'" + json.feed.entry[i].link[j].href + "'";//bs
var entryTitle = json.feed.entry[i].title.$t;
var item = "<li>" + "<a href="+ entryUrl + '" target="_blank">' + entryTitle + "</a> </li>";
 document.write(item);
 }
 document.write('</ul>');
 }
</script>
<script src="http://lineadecomandos.blogspot.com/feeds/posts/summary/-/awk?max-results=999&amp;alt=json-in-script&amp;callback=recentpostslist">
</script>


Este código se puede usar dentro de una entrada (decid al editor que muestre HTML literalmente). Por ejemplo, aquí listo mis entradas sobre awk:




También se puede poner en un gadget HTML/Javascript.

Google admite comandos

Google ha tenido a bien crear googleCL, un script en Phyton para acceder a la funcionalidad de Blogger, Picassa, Calendar, Docs, Youtube.

Lo he probado desde mi Ubuntu 9.10, creando la primera línea de esta entrada:
google blogger post --tags "GoogleCL, Phyton" --title "Google admite comandos" "Google ha tenido a bien crear un script en Phyton para acceder a la funcionalidad de Blogger, Picassa, Calendar, Docs, Youtube."

Tras pulsar enter, te pregunta el nombre de tu cuenta en Google, y te devuelve un URL para que lo valides desde tu navegador.

Cygwin es lento (I)

Pero mucho, mucho.

Lo más lento es ejecutar los configure, que en Unix tardan segundos y en Cygwin minutos.
La razón es la lentísima creación de processos (spawing) en Cygwin.

Por ejemplo, el configure de FFmpeg.

Primero creamos un entorno óptimo, eliminando los directorios innecesarios de PATH:
export TMPDIR=/tmp
export TEMP=/tmp
export TMP=/tmp
export PATH=/usr/local/bin:/usr/bin:/bin

Esta es mi invocación habitual de configure:
time ksh ./configure --disable-shared --enable-static --enable-gpl --enable-avfilter --enable-avfilter-lavf --enable-pthreads --enable-avisynth --enable-bzlib --enable-libmp3lame --enable-libx264 --cc=gcc443 --cpu=core2 --enable-zlib --extra-cflags=-DX_DISPLAY_MISSING

real 2m24.004s
user 0m15.938s
sys 0m41.157s


La cuenta no sale: 2m24s -15s -42s = 86 segundos sin currar.

Primer intento de mejorarlo: evitar las reubicaciones de las DLLs.
Para ello, invocamos la línea de comandos de Windows (cmd.exe), vamos al directorio de los binarios de Cygwin, invocamos dash, y lanzamos rebaseall:
cd c:\cygwin\bin
dash
./rebaseall

Volvemos a invocar el configure de FFmpeg y nos da:

real 2m20.758s
user 0m15.713s
sys 0m42.660s

Bueno, hemos ganado 4 segundos.

Mi tele lee multimedia (II)

Para las pruebas, necesito material HD, por ejemplo Big Buck Bunny

Nos lo traemos:
wget http://mirror.bigbuckbunny.de/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov bbb.mov

FFmpeg nos dice:

ffmpeg -i bbb.mov

Atentos a que partimos de sonido envolvente: los 6 canales de audio.

Convertiremos un trocito, por ejemplo 3 segundos, que a 24 cuadros por segundo, son 72 cuadros.

Empezamos a probar conversiones.

a) Calidad HD.
Los codecs H.264 / AAC encajan con lo que la tele puede leer. El contenedor .mov es un dialecto de .mp4, así que basta con cambiar la extensión de fichero.

Si queremos coger un trocito:
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec copy -acodec copy bbb_9300.mp4

La tele muestra bbb_9300.mp4 correctamente.

Si los codecs no hubieran coincidido:
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec libx264 -fpre normal -crf 22 -acodec libfaac -ab 192k bbb_9300.mp4

b) Calidad DVD.
La tele es 16:9, y Big Buck Bunny también, así que mejor usar "-aspect 16:9". Dotaremos de 8000kb/s al vídeo (los DVDs comerciales suelen quedarse en 6000kb/s).

Preparamos las tres variantes de audio.

b1) MPEG layer 2 (sólo estéreo)
ffmpeg -ss 13 -vframes 72 -i bbb.mov -target pal-dvd -aspect 16:9 -b 8000k -ac 2 -acodec mp2 bbb_8000_mp2.vob

b2) LPCM, forzando audio estéreo.
ffmpeg -ss 13 -vframes 72 -i bbb.mov -target pal-dvd -aspect 16:9 -b 8000k -ac 2 -acodec pcm_s16be bbb_8000_lpcm.vob

b3) AC3, preservando los 6 canales.
ffmpeg -ss 13 -vframes 72 -i bbb.mov -target pal-dvd -aspect 16:9 -b 8000k -acodec pcm_s16be bbb_8000_lpcm.vob

La tele los muestra correctamente.

c) Calidad AVI.
Mi tele no necesita la marca "-vtag DX50" que algunos reproductores requieren en Windows.

Preparamos las tres variantes de audio.

c1) MPEG layer 2 (sólo estéreo)
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec mpeg4 -s 720x576 -aspect 16:9 -b 8000k -ac 2 -acodec mp2 -ab 192k bbb_8000_mp2.avi

c2) MPEG layer 3 (sólo estéreo)
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec mpeg4 -s 720x576 -aspect 16:9 -b 8000k -ac 2 -acodec libmp3lame -ab 128k bbb_8000_mp3.avi

c3) AC3, preservando los 6 canales.
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec mpeg4 -s 720x576 -aspect 16:9 -b 8000k -acodec ac3 -ab 384k bbb_8000_ac3.avi

La tele los muestra correctamente.


Conclusión:
La tele da bastante de sí: muy pocos reproductores de salón soportan 8000kb/s en MPEG4. Y menos aún, H.264/AAC.


Líneas de investigación:
El fichero de partida tiene 23.97 fps (FILM). Hay que ver si la tele soporta 29.97fps (NTSC) y 25fps (PAL).
Lo más probable es que sí, pero he notado que el movimiento con 23.97fps es a saltitos, no es suave.

Hay que probar con distintos tamaños. En AVI he visto que 720x432, 704x298, 640x272, 720x400, 640x480 van bien.

Hay que probar si traga tal cual el .mp4 de YouTube HD (1280x720, 640×360).

El fabricante dice que la tele lee particiones FAT16, FAT32 y NTFS. Leer NTFS es inusual, así que hay que refrendrarlo con una pruebecilla.