¿Editando vídeos en un smartphone? A dónde vas...

Me he encontrado con un caso que para mi, a mi edad, me parece bien extraño. Alguien (Mr X, que no quiere ser reconocido en esta oscura historia) quiere hacer un vídeo introductorio corto y para ello decide instalar un programa (se dice app, ¡carca!) en el teléfono, un tal Kinemaster. Hace con cuatro clics un vídeo, le mete música de fondo, y todo orgulloso me lo enseña. Incluye, ya que es la versión gratuita, una marca de agua. Pregunté yo si necesitaba el vídeo en ese mismo momento, y resulta que no. Así que hice una foto del objeto principal de la historia (sí, la hice sin bajarla de ningún lado, y con una cámara de fotos, no con el teléfono); en gimp hice un desenfoqué para que hiciera el mismo efecto que Kinemaster, creé un logo similar al que había cogido en la red, corregí su gamma y 4 cositas más. Con esa foto y openshot generé un vídeo de los mismos 11 segundos, introduje un aumento hacia delante similar al logrado por Kinemaster e incluí la misma música (solo 11 segundos, por cuestión de derechos de autor), y quedó perfecto. Ni una marca de agua, sin problemas de derechos de autor de la foto o del logo, por que los hice yo, edité con software libre (free en libre y free en gratuito) y me quedó igual de bien y sin marca de agua.
¿Para qué narices necesitamos editar un vídeo en un teléfono, o pagar para evitar una marca de agua? Tenemos todo lo necesario a nuestro alcance y nunca ha existido la necesidad de mandar un vídeo editado de manera inmediata.
Cada día me gusta menos la velocidad que está desarrollando el mundo. Ya he pasado de Facebook, pero el siguiente éxito verdadero será poder tirar el móvil a la basura.

jdownloader, youtube y ffmpeg

Estos días me he encontrado con un "pequeño" problema cargando vídeos de youtube. Empecemos por el principio. Cuando un vídeo de Youtube me interesa o me apetece verlo con más calidad, resulta muy fácil poner la dirección del vídeo en youtube en jdownloader y este programa baja la mejor versión en muy poco tiempo para cuando quieras verla. Realmente nunca me he preocupado como Youtube guarda los vídeos ni nada por el estilo; lo utilizo de vez en cuando como observador y alguna vez, muy pocas, incluyendo algún vídeo con fin didáctico. Por lo que parece youtube guarda los vídeos con diferentes formas de vídeo y sonido por separado, y jdownloader los junta cuando lo utilizamos para bajarlos. Para ello debe utilizar —es una suposición lógica, según lo visto estos días— ffmpeg.

En una actualización jdownloader ha debido instalar plugins propios de ffmpeg que no funcionan, y el programa para en el intento de bajar los ficheros de vídeo y audio y pide una instalación de ffmpeg. Al decirle que sí, la respuesta es que ya está actualizado, y sigue sin bajar los ficheros; círculo infernal sin solución aparente.
La solución es bastante simple. En Opciones, Ajustes Avanzados, buscamos la ruta de ffprobe y ffmpeg. La ruta que estaba antes del arreglo era una ruta interna de jdownloader. Picamos con la derecha del ratón y las volvemos a las anteriores. Listo.

Estuve un montón de tiempo hasta que lo resolví, pero la respuesta directa estaba aquí. La de tiempo que me hubiera podido ahorrar.

Manipulando vídeos en el terminal: mencoder

Muchas veces tenemos vídeos muy interesantes, pero demasiado largos para ser utilizados en una clase o charla. El inconveniente está en poder separar un fragmento y adaptar ese fragmento para que pueda ser proyectado en cualquier PC, sobre todo si no se conservan las tomas iniciales para volver a montar el trozo necesario.

En este caso tenemos un vídeo de 2014, resolución 640x480 —no recuerdo por que se grabó en esta resolución—, con codificación h264 de video y AAC de audio. La duración es de 37 minutos y 50 segundos de los que nos interesaba tener solo el fragmento desde 9'07'' hasta 11'07''. Estoy seguro que existen muchas formas gráficas de extraer ese fragmento, e incluso páginas web donde se podría realizar, pero ninguna tan rápida como esta orden de terminal:

mencoder -ss 00:09:07 -endpos 00:11:07 -oac pcm -ovc copy video.mp4 -o fragmento.mp4


Por alguna razón que aun estoy revisando no me permitió hacer -oac copy —una entrada para el futuro—. En todo caso, en mi ordenador y en mi portátil el fragmento, al igual que el vídeo original, funciona perfectamente, pero muchos ordenadores con Windows 7 y Windows 10 que he probado en diferentes salas no disponen de decodificadores para leer estos video y/o audio, así que lo más sencillo es reconvertirlo a un avi con los clásicos XviD/DivX y MP3. De nuevo podemos afirmar que existen muchas formas gráficas de hacerlo, pero de nuevo ninguna tan rápida como el terminal:


mencoder fragmento.mp4 -oac mp3lame -ovc xvid -lameopts preset=standard:fast -xvidencopts pass=1 -o fragmento.avi

Más rápido, imposible.

PD. Para más información
Codificación básica con mencoder
Mencoder en archlinux

Vídeos webm; cortar y unir

Por razones de docencia, me interesaba unos minutos del episodio sobre el Ártico de Beyond Survival. Como es natural, es muy sencillo conseguirlo en Youtube, ya que en general estos programas están colgados en su versión inglesa. Si alguién tiene curiosidad, en Youtube solo hay que buscar beyond survival artic, y encontrará el programa dividido en 5 partes. el problema reside en que lo que nos interesa era el final de la parte 2 y el principio de la parte 3. ¿Como lograrlo?

1. Bajar los ficheros. Tenemos varias opciones; lo más fácil es usar la extensión DownloadHelper en Firefox. En Chrome/Chromium tenéis aplicaciones o extensiones para que os aparezca en los ficheros de youtube la opción de descarga. Finalmente, en terminal (¡por supuesto!) existe la aplicación youtube-dl. Bajamos mediante youtube-dl todas las partes

youtube-dl url

Las partes 2 y 3 corresponden por ejemplo a:

youtube-dl http://www.youtube.com/watch?v=vXto9zcwlZg
youtube-dl http://www.youtube.com/watch?v=KNjQBzp-q5Y

Los ficheros que obtuve fueron del formato webm, descrito en su faq como

"WebM is an open media file format designed for the web. WebM files consist of video streams compressed with the VP8 video codec and audio streams compressed with the Vorbis audio codec. The WebM file structure is based on the Matroska media container."

Los que prefieran trabajar en otros formatos, la solución es

youtube-dl --all-formats url

Y así bajará todos los contenedores presentes (webm, flv, mp4...).

Se observaron los vídeos, anotando los segundos iniciales y finales de cada parte para los siguientes pasos.

2. Recortar los vídeos. Las GUI de las que disponía no me permitieron cortar de forma fácil el vídeo, así que me fui a las aplicaciones CLI. Lo más sencillo es recurrir a ffmpeg

ffmpeg -i video.webm -vcodec copy -ss 190 -t 320 -acodec copy corte1.avi

siendo
-vcodec copy y -acodec copy significa que no alteramos los vídeos, manteniendo los codecs de video y audio, ya que solo queremos cortar
-ss 190 el segundo donde empieza el corte (en este caso de la parte 2)
-t 320 el tiempo de duración en segundos que yo quiero a partir de ese 190


3. Unir los dos cortes. No todos los formatos de vídeo permiten la unión con una simple concatenación. En el caso de que fuera así, con un simple cat los podemos unir

cat video1.mpeg video2.mpeg > video.mpeg

El ejemplo indica vídeos mpeg, ya que vídeos así sí se pueden concatenar. En el caso de webm no funciona. Una solución es la transformación previa , por ejemplo a mpeg, pero eso supone una pérdida de calidad, solo para unir, así que hay que evitarlo. Gracias a esta dirección, descubrí que se pueden unir utilizando las mkvtoolnix

mkvmerge -o video.webm corte1.webm +corte2.webm

lo que tiene sentido, si el formato webm está basado (ver arriba) en el contenedor matroska. Según otras páginas, tambien es posible hacerlo de forma gráfica, con las mkvtoolnix-gui, pero no lo he probado.

Todo ello me ha dejado un vídeo de unos 6 minutos que contienen exactamente lo que yo quería, una piel de caribu con larvas de Hypoderma tarandi, es decir, con barros. De esta forma podemos enseñar diferentes especies de estas moscas parásitas afectando a otros hospedadores diferentes a los de aquí, las vacas.

4. Recodificación
Solo queda un último paso, que es la transformación de ese webm a otro formato que se pueda proyectar en casos en que no haya disponibilidad de red y con ordenadores de pocas prestaciones, antiguos, sin codecs, etc... Sin embargo, por ahora he tenido problemas. Winff gráfico y las ffmpeg en terminal indican errores que impiden la conversión. Debido a dependencias de librerías, solo puedo instalar transmageddon en la versión 0.16-1, y no lo puedo configurar adecuadamente para conseguir un vídeo razonable. Mencoder en terminal

mencoder video.webm -ovc xvid -oac mp3lame -lameopts abr:br=128 -xvidencopts bitrate=1200 -o video.avi

genera un video con desincronización de sonido respecto al vídeo. y de una calidad baja, así que tendré que leer más sobre mencoder. Las aplicaciones gráficas generan órdenes de decenas o centenares de líneas, que exigen un conocimiento a alto nivel que no tengo.

Lo logrado por ahora genera un vídeo perfecto para lo que queremos y que podemos usar fácilmente en muchas circunstancias. El problema es, por ejemplo, si queremos introducirlo como tal dentro de una presentación, si vamos a usar un portatil desconocido sin conexión a Internet en aulas aisladas, conferencias donde no sabemos de que vamos a disponer etc... Para evitar esos problemas, es recomendable llevar varios formatos del vídeo en el bolsillo. Seguiremos indagando.

Conversion de vídeos

Estas últimas semanas estoy muy ocupado en la generación y conversión de vídeos científico-educativos. Para mostrar algunas de las acciones de un insecto sobre el ganado, hemos estado grabando vídeos con nuestras cámaras. Dispongo de vídeos de dos orígenes; los primeros se generaron con una cámara Olympus. El "fotógrafo" tenía marcada una calidad muy baja

y los resultados fueron "poco óptimos".
Por suerte, simultáneamente estaba otro "fotógrafo" sacando vídeos de lo mismo con una Lumix con una configuración de calidad muy alta, lo que supone vídeos mts de alta definición de estas características (como ya habíamos visto aquí)

$ ffmpeg -i 00020.mts

sale:
...
Stream #0.0[0x1011]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 100 tbc
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s

Por supuesto, esto genera un problema para ser proyectados en una presentación de PowerPoint (sí, PowerPoint; no lo voy a presentar yo, que conste). Desde hace unos años he utilizado WinFF en la conversión de los vídeos, pero por alguna razón de librerías en mi ordenador principal me genera un error y no convierte. Siguiendo el orden de "calidad" señalado en un artículo de Ubuntu Users (Revista #6 Ubuntu en la nube) intenté entonces con Arista Transcoder; sin embargo, una vez instalado, no era capaz de iniciar un proyecto. El siguiente intento fue Transmageddon; de nuevo, por dependencias sobre librerías más modernas de las disponibles, me vi forzado a instalar la versión 0.16 (la 0.21 y 0.20 exigían librerías no disponibles en Fedora 64bits). Sin embargo, la transformación fue correcta y se obtuvo unos avis con una resolución idéntica al original y con buena calidad.

He generado también un VCD.

Como es natural, la transformación 1280x720 a 352x288 genera una alteración en la apariencia, así que tengo que "pulirlo" con algún crop lateral. Por supuesto, la intención será intentar mostrar los mts originales, pero como nunca se sabe de que ordenadores se dispone en los diferentes sitios y que codecs tienen instalados, lo mejor es siempre llevar todas las posibilidades, y el formato VCD (mpeg1) es un formato nativo en PowerPoint. No será la primera vez de que nos ha salvado en una conferencia llevar presentaciones en ppt, pptx, odp, pdf y vídeos de todo tipo de formatos. De hecho, para que no fallara nunca nada, antes siempre llevaba una instalación de Debian en un USB. Si fallaba Windows y Ubuntu o Fedora, siempre nos queda Debian, que aun no me ha fallado nunca. Si fuera una presentación personal mía, la haría algo más pública y colgaría la presentación en slideshare y los vídeos en Youtube.

Fotos en ráfaga - motion

Como se ha visto a lo largo del mes y medio que llevo manejando cheese, las aplicaciones gráficas generan o sufren limitaciones que muchas veces solo podemos superar con el terminal. La primera limitación era la dependencia de evitar la suspensión del monitor, que habíamos superado en gnome 3 con unas ordenes simples en terminal

xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
setterm -blank 0

Sin embargo, la limitación que no he podido superar ha sido la limitación del número de fotos extraídas por cheese. Sin embargo, gracias a motion, un programa de vigilancia y monitorización mediante cámaras GPL2, y a mi amigo hckorootx ya no hay ningún límite a las fotos en ráfaga, salvo el que nos imponga el hardware del que disponemos.
La instalación de motion en Fedora es tan simple como
$ su -
     palabra
# yum install motion

La ejecución sería algo más compleja, pero hckorootx nos ha preparado un itinerario simplificado que yo he seguido al pie de la letra y funciona perfectamente

1. Crea un directorio "motion" (o cualquier otro nombre) en home

2. Dentro del directorio crear un archivo "motion.conf" con el siguiente contenido:

process_id_file /var/run/motion/motion.pid
# 1 captura por segundo:
snapshot_interval 1
output_normal off
# tipo de paleta a utilizar (3 = JPEG):
v4l2_palette 3
framerate 2

brightness 0
contrast 0
hue 0
saturation 0

# anchura de la imagen
width 1280
# altura de la imagen
height 720
# calidad de la imagen (porcentaje de 0 a 100)
quality 75
# directorio de destino de las capturas
target_dir /home/lince/motion
# formato para los nombre de los archivos
snapshot_filename %d-%m-%Y/%H-%M-%S

3. Desde terminal, ejecuta:

$ motion -c /home/usuario/motion/motion.conf

Como se puede ver solo he cambiado sobre el original de hckorootx la anchura y altura de las fotos, ya que ahora mismo estoy usando una Logitech 525, que me permite mayor resolución.

El resultado es magnífico; una foto por segundo, sin tener que preocuparse por el apagado del monitor.

Además, tal como ha diseñado el fichero hckorootx las fotos se van guardando en un directorio diferente cada día, con lo cual podemos ir eliminando los días no válidos con un simple rm en terminal o de manera gráfica en nautilus. No recomiendo el uso del explorador gráfico, ya que estamos hablando de decenas de miles de ficheros y nautilus tarda mucho en escanear los ficheros y responder.

El siguiete objetivo será conseguir sacar fotos desde dos cámaras distintas con un solo ordenador. Nos ponemos a ello.
Muchas gracias a Kenneth Lavrsen por escribir esta magnífica aplicación y a hckorootx por estudiarla por mi y facilitarnos su uso.

Limitaciones de cheese

Como he señalado en algunas entradas (1, 2), estoy utilizando cheese y unas simples cámaras web baratas (Logitech C200 y C525) para hacer fotos en ráfagas para hacer vídeos de la evolución de unas fases larvarias de un insecto. Como decíamos, el primer problema ha sido controlar el apagado del monitor, que provocaba eue cheese dejase de hacer fotos. Gnome 3 no ofrece la posiblidad "nunca" en el apagado de monitor, así que hay que recurrir al terminal; lo hemos logrado mediante la ejecución como administrador de estas 3 órdenes:

xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system

setterm -blank 0

Sin embargo, ha surgido una nueva dificultad. Al disparar en ráfaga, cheese tiene un límite de 10.000 fotos, lo que reduce las horas en las que puede estar disparando automáticamente, según los segundos de espera que configuramos. Esto nos obliga a controlar el programa varias veces al día, incluido el fin de semana. Mi amigo hckorootx ha estudiado el código de cheese y me ha señalado donde tiene escrito ese límite y como cambiarlo. Con un simple

$ su -
   palabra de administrador
# /usr/share/cheese/cheese-prefs.ui

editamos el fichero y podemos cambiar ese límite.

Sin embargo, el programa no parece admitirlo, por que a pesar de que luego en la configuración indiqué 30.000 fotos en ráfaga, el programa se apaga al llegar alrededor de la 18.800, por algún bug interno o control de ficheros por Linux, falta de memoria (esto lo dudo, por que ese ordenador tiene 16GB de RAM DDR3) u otras razones que aun no se nos hayan ocurrido. Este "killed" que podemos ver

pasó 3 veces seguidas; la primera a las 18.894, la segunda a las 18.816 y la última a las 18.000, como se puede ver en esta captura

Para intentar solucionar este problema hckorootx me recomendó instalar cheese desde código fuente. Una vez desinstalado, la instalación desde código siguió la rutina habitual (./configure, make y make install), pero para terminar ./configure me encontré en un infierno de dependencias que duró hora y media, con una acción cruzada del terminal y yumex para ir añadiendo librerías de desarrollo y algunos paquetes que cubren ciertas opciones de cheese que no se cubren al instalar desde binarios.
El resultado fue aun peor, ya que este nuevo cheese de origen código fuente no me permitió editar el fichero cheese-prefs.ui. Mejor dicho, me lo deja editar, pero el sistema genera un nuevo cheese-prefs.ui~ con los valores básicos originales (hasta cuatro veces y un fichero final cheese-prefs.ui~~~~).

En resumen, hasta ahora hemos solucionado el problema provocado por el monitor y el renombrado en masa de los ficheros mediante script para luego hacer correctamente el vídeo con mencoder. Sin embargo, seguimos como antes en el límite de 10.000 imágenes y tenemos que lanzar la ráfaga por la mañana temprano, al mediodía y por la noche.
Posiblemente la mejor solución sería usar un programa de vigilancia, como motion, pero no disponemos del tiempo necesario para estudiar los manuales (es un programa de terminal bastante complejo) para saber usarlo.

Cheese, fotos en ráfaga y conversión a vídeo

He logrado, o mejor debemos decir hemos logrado, por que he tenido ayuda "experta", superar algunas de las dificultades del uso de cheese que decíamos aquí. En primer lugar, el apagado del monitor ha sido bastante simple, ejecutando estas ordenes:
xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
tomadas de aquí.
Sin embargo, han aperecido otras dificultades. Cheese, además de limitarse a 10.000 imágenes, ha presentado otra dificultad; guarda los ficheros con unos nombres que dificultan la conversión a vídeo. Los ficheros, para poner un ejemplo, tienen unos nombres que muestran un cuerpo inicial común formado de la fecha de inicio y la hora, minutos y segundos de comienzo:
- Primero: 2012-02-17-173235_1.jpg
- Último: 2012-02-17-173235_10000.jpg
Luego se numeran desde el 1 en adelante, pero sin mantener un número común de caracteres. Esa falta de ceros a la izquierda de los números hace que el ordenador, y los programas que generan el vídeo desde las imágenes, los ordenen de manera equivocada, siendo por ejemplo el último el 2012-02-17-173235_9.jpg. Así, cada determinado número de frames hay una imágen equivocada que genera bastantes molestias.
Por suerte mi amigo hckorootx generó unos scripts para cambiar en masa el nombre de los ficheros, como podemos ver en los comentarios de esta entrada. En concreto, este script funcionó perfectamente (muchas gracias, hckorootx):

#!/bin/bash
for archivo in *.jpg; do
long_total=`expr length $archivo`
long_util=`expr $long_total - 18`
nombre_inutil=`expr substr $archivo 1 18`
nombre_util=`expr substr $archivo 19 $long_util`
if [ $long_util -eq 5 ]; then
ceros="0000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 6 ]; then
ceros="000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 7 ]; then
ceros="00"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 8 ]; then
ceros="0"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
fi
done

Además, como se ve es muy explicativa por si misma. Menos mal, por que yo de script en bash no tengo ni idea, y eran casi 40.000 ficheros en 6 tandadas los que había que renombrar.
Una vez convertidos adecuadamente desde el primero 2012-02-17-173235_00001.jpg hasta el último 2012-02-17-173235_10000.jpg, ya solo quedaba dar una orden de conversión. Después de haber pensado en usar openshot, decidí usar directamente mencoder, por que el terminal es siempre más rápido.
Con esta orden,

$ mencoder "mf://*.jpg" -mf fps=25 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4

que tendré que pulir leyendo más profundamente las guías modernas de mencoder, me salió un conjunto de vídeos de los que cortando trozos y pegando con VirtualDubMod a través de wine logré un total de 4minutos y 12 segundos bastante buenos (me ha felicitado mucha gente), a partir de algo más de 6300 imágenes del total de 40.000.
No, no enseñaremos aquí el vídeo, por que es un objeto científico, y hasta que sea publicado los científicos no compartimos nada de nada. Después de publicarlos los derechos dejan de ser nuestros y ya no podemos disponer de nuestros hallazgos para difundirlos y hay que pedírselos a editoriales como Elsevier, Springer y otras similares. Si me dejan ponerlo en Youtube, según el uso al que esté destinado, lo pondré también aquí, pero no prometo nada.
El siguiente paso sería aprender lo suficiente de motion para poder evitar esa limitación de 10.000 imágenes de cheese... pero esa será otra historia

Cheese y fotos en ráfaga. Problemas al apagarse el monitor

Estoy experimentando la mejor forma de sacar tandadas de fotos con una cámara para luego hacer un vídeo. El modelo es una larva en desarrollo y la intención es seguir algunas de las fases de transformación. La primera prueba fue "casi" exitosa. Y digo casi por que mi cámara cutre Logitech C200 sacaba una resolución 640x480 decente con cheese, hasta que descubrimos varios defectos. Primero, no se puede pedir más de 10.000 fotos (lo intenté con 30.000 y 15.000, y siempre marca 10.000). Segundo, y mucho más importante, al llegar horas después para comprobar como ha salido todo, descubro que cheese para de fotografiar cuando el monitor se apaga. Además, en gnome 3 no hay una opción gráfica para negar el apagado de la pantalla. El máximo tiempo es de una hora (ha desaparecido el never).

El resultado ha sido que a lo largo de la noche se ha parado repetidas veces de fotografiar. Lo más sorprendente es que unas después, siempre aleatoriamente, volvía a empezar. Sospecho que se debe a vibraciones que activa el monitor por movimientos del ratón. Por supuesto, he intentado encontrar soluciones:

1. Uso de motion. Tiene varias ventajas. Es un programa de vigilancia, así que se puede activar para sacar solo fotos cuando hay movimiento. Es en consola, con lo que supongo que no se verá alterado por un monitor apagado.

2. Editar xorg.conf. Aquí podemos ver como editando la sección ServerFlags

Section "ServerFlags"
Option "blank time" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"
EndSection

se anula el apagado. El problema es que en las distribuciones modernas la mayor parte de los conf de toda la vida han dejado de existir o se localizan en otro sitio en directorios conf.d. En resumen, en Fedora 16 no existe xorg.conf. Mejor aun, al querer generarlo como administrador, simplemente al escribir estas líneas,

su -
palabrita
gedit /etc/X11/xorg.conf

sin escribir en el fichero y sin guardarlo cheese dejó de funcionar (y tardó un rato antes de poder llamarlo de nuevo). Por lo de ahora he dejado esta posibilidad aparte

3. Ordenes más sencillas a través de setterm. Por ejemplo aquí indica alguna posibilidad

$ setterm -powersave off -blank 0

Empezaré probando esta última. Si no funciona, seguiremos generando un xorg.conf y finalmente con motion (es un programa de terminal cuyas opciones dan para un kilómetro y medio de papel impreso). La versión gráfica kmotion creo que precisa apache, lo que para hacer unas fotos de 50 kb me parece mucho.

Finalmente, si todo sale bien, compraré una cámara con más resolución.

Vídeos "azules"

Como decía hace unos días, tengo el ordenador principal en un "casi" perfecto estado de revista. Y digo casi, por que desde que instalé Ubuntu desde el DVD de UbuntuUsers los vídeos tenían un cierto tono azulado (ejemplo con mi WebCam).

No me molestaba mucho, pero hoy después de misa tenía un rato, así que busqué en la red, donde salen miles de cambios y cosas para solucionarlo (por ejemplo aquí), pero lo más fácil está en una de las respuestas de esa página, complemetada por esta otra; llamamos a totem (Aplicaciones, Sonido y vídeo, Reproductor de películas) y en Editar, Preferencias descubrimos que Tono está totalmente a la izquierda, así:

Presionamos sobre Restablecer predeterminados, con lo que Tono se coloca en el centro

y el resultado es

Perfecto. Esas imágenes son la prueba de video de la orden en terminal

    $ sudo gstreamer-properties

y se traduce en la reproducción de cualquier video, tanto en totem como en VLC. Ahora sí está el ordenador a mi gusto; solo le falta poder instalar el 10.10, pero creo que tendré que esperar al 11.04

Vídeos MTS en el salón

Si la primera pregunta sobre los vídeos MTS de mi cámara era de qué estaban hechos, la segunda fue como verlos en el salón cómodamente y no sobre el monitor. En los lectores habituales que usamos estaba seguro de que no sería posible, así que con WinFF los tranformé a avi, codificando H264 y AC3 a XviD y Mp3; la verdad es que quedó muy bien. Esa podría ser la primera respuesta, que además supone una gran ventaja de espacio, ya que a pesar de que estaba codificando con kbps variable bastante alta, alrededor de 2000-3000, el volumen queda reducido aproximadamente a un quinto del MTS original. Sin embargo hay también una segunda respuesta; el pequeño aparato de Western Digital, WD TV, no solo lee los ficheros normales, o imágenes iso de Dvds, ficheros MKV o casi cualquier cosa, también lee los MTS de la cámara, con lo que es innecesario recodificar los vídeos, con el gran ahorro que supone en tiempo.
Para finalizar, una última sorpresa; WinFF también puede ser descargado para Windows; y yo que inocentemente pensaba que los usuarios de Windows solo veían videos wmv con drm incluido.

Videos MTS y latitud y longitud

He descubierto ayer donde guarda mi nueva cámara (Lumix TZ10) los vídeos. La confusión nace en el hecho de que si usas tarjetas grandes, no te preocupas de las fotos que haces hasta que te queda poco espacio o, como en este caso, hasta que te piden unas copias de las fotos. Leí la tarjeta y no me aparecían los vídeos. En vez de guardarlos con las fotos esta cámara genera un directorio nuevo para los vídeos de alta definición con un montón de subcarpetas, supongo que para poder manejarlas directamente sobre televisiones Panasonic. La sorpresa (para mi) fue descubrir que los videos tienen una extensión mts.
Al querer ver de que "estaban hechos",

$ ffmpeg -i 00020.mts

sale:
...
Stream #0.0[0x1011]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 100 tbc
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s

Es decir, para ser una cámara de bolsillo, no está mal. Los voy a probar en mi WDTV para ver si los puedo ver en el salón sin tener que transcodificarlos.
Por lo de pronto, en los monitores de resoluciones altas se ven muy bien.

Además, quería leer los EXIF de las fotos, para ver como guarda esta cámara la latitud y longitud (única razón por la que decidí comprar esta cámara, como decía en esta entrada), y no sabía como leer los metadatos, así que buscando por la red encontré en este blog la solución;instalamos el paquete libimage-exiftool-perl y solucionado. Simplemente

$ exiftool -a -u -g1 P1000699.jpg

y salen metros y metros de información, incluido
---- GPS ----
GPS Version ID                  : 2.2.0.0
GPS Latitude Ref                : North
GPS Latitude                    : 42 deg 59' 39.46"
GPS Longitude Ref               : West
GPS Longitude                   : 7 deg 32' 46.50"
GPS Time Stamp                  : 09:43:39
GPS Satellites                  : 4
GPS Status                      : Measurement Active
GPS Measure Mode                : 2-Dimensional Measurement
GPS Dilution Of Precision       : 1.8
GPS Map Datum                   : WGS-84
GPS Processing Method           : GPS
GPS Date Stamp                  : 2010:11:24

y al final de todo
---- Composite ----
Aperture                        : 3.3
Blue Balance                    : 2.802657
GPS Date/Time                   : 2010:11:24 09:43:39Z
GPS Latitude                    : 42 deg 59' 39.46" N
GPS Longitude                   : 7 deg 32' 46.50" W
GPS Position                    : 42 deg 59' 39.46" N, 7 deg 32' 46.50" W
Image Size                      : 4000x3000
Preview Image                   : (Binary data 712616 bytes, use -b option to extract)
Red Balance                     : 1.225806
Scale Factor To 35 mm Equivalent: 6.1
Shutter Speed                   : 1/30
Thumbnail Image                 : (Binary data 7436 bytes, use -b option to extract)
Circle Of Confusion             : 0.005 mm
Field Of View                   : 71.5 deg
Focal Length                    : 4.1 mm (35 mm equivalent: 25.0 mm)
Hyperfocal Distance             : 1.03 m
Light Value                     : 6.4

Por cierto, nunca me había fijado en la información guardada en los EXIF, pero solo le falta poner mi carnet de identidad; con esos datos, ahora mismo nos vamos a Google Maps o Earth y ya se puede saber donde saqué la foto.

Convertidor de video

Estaba buscando un convertidor de video para los pequeños videos que obtienes de muchos sitios. En general yo me limito al uso del GordianKnot para los Dvds, previo paso por DvdFab Decripter, y VirtualDubMod para los avis habituales (funciona perfectamente a través de Wine). Ahora bien, para algunas cosas, como los movs de la cámara de fotos y los flv de la red, o usas páginas Web, o estás atado en algunos casos a programas propietarios (QuickTime). Así que hoy, dando un repaso al boletín que recibo de vez men cuando de cdlibre.org, al que se puede uno apuntar aquí, vi la posibilidad de instalar WinFF, a GUI de ffmpeg. Ya veremos como funciona.
Al mismo tiempo quise instalar Google Earth, que no tengo desde la instalación limpia de Ubuntu 9.04. Tras su instalación (sh GoogleEarthLinux.bin) se alteró toda la apariencia gráfica en el monitor (no se veía nada), no respondía al teclado (no me dejaba cambiar resolución, ni rearranque gráfico ni reisub) y no me quedó más remedio que darle a la tecla de reset. Menos mal que arrancó sin daños aparentes y todo sigue igual (por ahora). Sin embargo, no fue así en un Windows2000 que, después de un corte de luz, muy frecuente aquí, no quiso arrancar más con el resultado habitual de Windows:

Hace ya mucho tiempo que no veía pantallazos azules. Antes, con Windows en mis ordenadores, cada 15 días uno (experimentaba mucho).
Para salvar los datos arranque con un CdLive de Ubuntu, y como no me dejaba montar los discos por haberse cerrado de forma incorrecta, así que lo monté como administrador

# mount -t ntfs-3g /dev/partición /media/nombre_disco

copié los datos fundamentales en un disco externo y luego los desmonté correctamente. Al volver a encender el ordenador ya funcionaba, con pérdida de algunas dll y todo lo que puede funcionar un ordenador antiguo con poca memoria y Windows de S.O. Mi recomendación fue el formateo e instalación de Linux, cualquier distribución, pero como estamos rodeados de racistas, prefirieron dejarlo en cambiar de antivirus y pasar el Spybot (3 virus y no se cuantas cosas de esas de Windows). Preveo un nuevo pantallazo azul antes de que se acabe Junio.

Probatinas en Linux

Probando el AviDemux el otro día descubro un error que, según leo por ahí, debe ser bastante común, y es que al intentar meter un segundo sonido en una película, no queda grabado. Para no ir a usar el ordenador con Windows (me resulta algo incomódo ahora usarlo) intento usar el VirtualDubMod en Ubuntu a través de Wine. Pues bien, perfecto, siempre que no se quiera recodificar, por que no detecta los codecs (Xvid etc...). Me permitió introducir perfectamente las nuevas pistas. Así que uno puede recodificar el video (si es necesario) con el AviDemux (aún no controlo ordenes de terminal para esto) y luego unir los sonidos con VirtualDubMod. Otra limitación que nos impedá abandonar Windows superada.
Mientras estaba con los sonidos y mirando mi nuevo Blog en la competencia (WordPress), estaba probando también el Pidgin. Un amigo mío estaba con su correo gmeliano y me detecto y estuvimos de chachara. Encuentro muy interesante el uso de Pidgin, ya que permite tener todas las cuentas abiertas, incluido la de Messenger, al mismo tiempo. Eso me permitió descubrir que yo tengo una cuenta en Messenger. Yo, que lo primero que hacía en Windows era desistalar el Messenger, descubro que tenía una cuenta (asociada a mi correo Live que tengo para usar el SkyDrive). A ver si resulta que a mi edad me hago adicto también del chat, al que siempre consideré el hermano pobre, inculto e inutil del eMail, es decir, la oveja negra de Internet.
Una última prueba fue el uso de SPSS para Windows en Linux a través de una máquina virtual (VirtualBox). La máquina virtual, perfecta, pero SPSS es insoportable, con lo que terminé haciendo toda la estadística con OpenStat (recomendado, y además gratis) con Wine (la versión para Linux no está terminada). Estas son mis últimas aventuras en Linux. Me olvidaba de decir que este último tiempo he estado usando aMule en mi casa y ya he superado ya la bajada lograda con eMule. Aún no he podido lograr que al picar los ed2k en Firefox se pase directamente a aMule, lo que me obliga a copiar la ruta de enlace y pegarla en aMule, pero es una dificultad menor.

Video de Youtube

Son casi las 3 de la mañana y aun estoy pensando en un video de Youtube que me a dejado impresionado. El que quiera verlo es aquí. Sí, es así, se llama y habla de un país de mierda. Es una descripción muy clara de lo que se puede hacer cuando se mira de manera sectaria y perdido por la ideología. Para comprenderlo mejor es bueno pasarse luego por esta página. No tengo nada más que decir. Como dice él, piensa en ello.