Como Reproducir Videos a 1080p en GNU/Linux

Con el estreno de The Pacific he querido volver a ver Band of Brothers de nuevo como aperitivo. Ahora que la tecnología lo permite, estoy viendo la serie en alta definición a 1080 líneas. El problema con el que me encontré es que ni en Windows ni en Ubuntu podía reproducir el vídeo sin que se produjesen cuellos de botella. Todo el trabajo lo hace el procesador y encima sólo utiliza un núcleo, puesto que la aplicación todavía no está programada para multihilo.

Me puse a leer un poco y encontré la solución de cómo poder reproducir los vídeos sin que se produjesen pérdidas de fotogramas o cuellos de botella. En una de las últimas versiones de los controladores de NVIDIA (ATI también lo tiene) la empresa ha desarrollado un driver para reproducir vídeo que en lugar de dejar el trabajo al procesador y únicamente dedicarse a representar la imagen, lo que hace es pasar el trabajo de descompresión a la gráfica y posteriormente representarlo. El driver en cuestión se llama VDPAU (si recuerdo bien sólo está disponible para los modelos 8xxx en adelante). Si usamos GNOME, lamentablemente no he encontrado forma de que Totem haga uso del driver, sin embargo MPLAYER si viene con esta capacidad. Si abrimos Mplayer y vamos a Preferencias > Video, vemos que está en la lista de los posibles drivers. Si os pasa como a mí, que siempre que cambiais algo en esa pestaña Mplayer se cuelga (esto lleva así ya 3 o 4 versiones y no lo solucionan) podemos abrir el fichero de configuración de Mplayer y configurar directamente ahí la salida de vídeo que queremos. Así hacemos:

• $ gedit ~USUARIO/.mplayer/gui.conf
y modificamos el valor 'vo_driver'
• vo_driver="xv" >> vo_driver="vdpau"

Lamentablemente esto no es lo único que hay que hacer. Ahora podremos abrir el vídeo y verlo con cierta continuidad, cosa que antes no podía, pero de vez en cuando, sobretodo cuando los planos son cortos y con mucho movimiento, se sigue produciendo pérdida de fotogramas. Además, el programa sigue usando un núcleo de entre todos los disponibles. Lo bueno es que el filtro que se encarga de descomprimir el vídeo (ffmpeg) se puede configurar, y lo bueno es que podemos hacer que esos cambios sean permanentes.

Los cuellos de botella se producen porque el ancho de banda que necesita un vídeo a 1080p es enorme aunque esté comprimido. Es una densidad de píxeles gigantesca, 1920x1080, que tiene que mover esa cantidad de píxeles 24 veces por segundo (en este caso) y encima que tiene que aplicar determinados algoritmos para poder reconstruir la imagen; algoritmos que no es que sean precisamente simples. Lo que vamos a hacer es decirle a ffmpeg es que cuando decodifique un vídeo no tenga en cuenta los macrobloques (porciones en las que se divide el fotograma cuando se comprime para calcular el movimiento, redundancia, etc.) y que decodifique el fotograma entero como si fuera un único macrobloque. Con esto en teoría vamos a perder algo de calidad, sobretodo cuando haya mucho movimiento en la escena, quizás la división entre macrobloques se haga patente y tengamos algo de bracketing. Según mi experiencia no he notado esa perdida de calidad en el movimiento o los colores. Para establecer estas opciones hacemos:

• $ gedit ~USUARIO/.mplayer/config
y escribimos:
• lavdopts=threads=4:skiploopfilter=nonkey

La opción threads lo que nos habilita es la capacidad de que el decodificador use más de un núcleo, en este caso 4. Así que la idea es ajustar el número a la cantidad de núcleos que tengamos. Por otro lado skiploopfilter es el encargado de controlar el deblocking del video. Tenemos varias opciones, pero las más interesantes son all, nonkey, nonref y default. La primera deshabilita el deblocking para todos los fotogramas; nonkey lo desahabilita para todos los fotogramas excepto los claves -aquellos que no se comprimen-; nonref hace el deblocking únicamente en los de referencia y no en los clave; default obviamente habilita el deblocking siempre en todos los fotogramas. Dependiendo del ordenador que tengáis y de los recursos os interesará establecer una u otra. Las ordeno ahora de mayor a menor consumo de recursos: default > nonref > nonkey > all. Aunque no lo he notado, creo que es más conveniente, si dudamos entre nonref y nonkey, establecer nonkey porque los fotogramas siguientes se construyen a partir del clave, así tendríamos menos problemas a la hora de reproducir los vídeos.

Con estas opciones pasé de esta gráfica de consumo de CPU:

Fijaros como se nota que empiezo a reproducir el vídeo en torno al 30. A esta:

Un gran cambio :D.

Empate a Uno

Hace tiempo comenté, con el tema de visualizar archivos RAW en GNU/Linux, la importancia de pulir esos detalles en el pingüino para que sea un sistema un poco más accesible para todos.

En este caso es al revés. En una entrada que puse el otro día usé Google Translate para que me tradujese a hiragana el texto de agradecimiento a la gente del Sakura Hostel. Pero ayer, me metí al blog usando un Windows y me dí cuenta de que en lugar de los caracteres japoneses aparecen unos bonitos cuadrados con números; mientras que en GNU/Linux aparecen los hiraganas tal cual. No sé muy bien por qué puede ser esto, porque la codificación de la página la miré y era igual en ambos sistemas y en ambos se usaba Firefox. Pero este tipo de cosas sí que hacen bueno al sistema Libre evitando preguntas de 'por qué veo estos cuadraditos'.

Versión en GNU/Linux:

Versión en Windows:

Hoygan en Rawstudio

Estaba probando un programa de GNU/Linux que se llama rawstudio que sirve para revelar imágenes raw de cámaras de fotos digitales. Es un programa que había probado hace tiempo y no me gustó demasiado, pero han sacado la versión 1.0 hace un par de meses y me he animado a darle una segunda oportunidad.

Sigue siendo igual de lamentable que la versión anterior, desgraciadamente. Y eso que la idea, como programa, no está nada mal. Quiere emular un poco la filosofía de Aperture o Lightroom en el que tienes una biblioteca de imágenes junto al programa con que las revelas. Realmente lo único destacable del programa es el algoritmo de enfoque que usa, que es bastante bueno. He aquí una prueba de ello. Respecto de lo demás no merece nada la pena. Me sigo quedando con ufraw.

Lo divertido ha sido que mientras lo probaba me ha salido esto en un menú:

Hagamos zum todos juntos xD.

Con Ocho, Mejoras

El otro día, cuando hablamos sobre los programas y saber usarlos, dije que la única cosa que no me gustaba de GIMP y que me parecía mejor en Photoshop era la interfaz. Sin embargo acabo de darme cuenta de que hay algo que me fastidia muchísimo más. ¡El no poder manejar imágenes de 16 bits!

No me explico como a estas alturas aún no existe esa posibilidad en el programa. Lo peor de todo es que no parece ni planificado para la siguiente versión.

"Lo único que quiero es animar"

Esta misma reflexión la hice en el otro blog hace muchísimo, pero hoy leyendo una entrada en IonLitio me ha recordado la película y me he animado a reescribir la idea. La cuestión es que en el post se habla de los diferentes enfoques que puede adoptar un usuario al tener instalado GNU/Linux. Está la opción friki/entusiasta y está la opción de aquel que lo usa como si de un Windows se tratase. El artículo es interesante, pero la bombilla se me encendió al leer los comentarios de gente que decía que no migraba porque no podía instalar Photoshop o usar InDesign o cualquier otro programa.

Aunque en el caso de Photoshop ya no es verdad. Lo que realmente importa no es si puedes usar un programa determinado dentro del pingüino o no, sino si un programa de un determinado área tiene un buen reemplazo en GNU/Linux. Por poner un ejemplo, Internet Explorer tiene un buen reemplazo en el sistema con Firefox o Konqueror. Son programas, cuando menos de igual calidad y, en este caso, de mucha mejor. Mucha gente entiende, que es una de las lacras de la enseñanza informática, que únicamente sabe manejar el programa que él ha aprendido. Es decir, piensa que sabe manejar Photoshop, y que por lo tanto GIMP, Photopaint, etc. no los sabe usar y los desprecia (en un sentido no negativo). En una charla que dio Miguel Ángel Fuertes en un ArtFutura, se le hizo la típica pregunta: con qué programa 3D animas tú. Su respuesta fue: "A mí que más me da. Lo único que quiero es animar".

En mi opinión, trabajar con un programa no significa conocer ése programa determinado, sino entender una filosofía de trabajo con un determinado tipo de programas. Es decir, una persona que sepa editar vídeos con Avid, seguramente sabe usar cualquier otro programa de edición que le pongas; la razón es que él sabe que todo buen programa de edición tiene que tener unas filosofías comunes como son poder empalmar planos, poder hacer fundidos, poder mover planos dentro de la edición, etc. Lo único que le va a costar es saber donde están esas opciones en el nuevo programa y eso, creo que no se tarda demasiado en aprenderlo. Por ponerlo más claro: lo único en lo que se va a perder un mínimo de tiempo, es en buscar por lo menús dónde están las opciones para hacer algo que sabes que tiene que estar.

Pues con programas de retoque y edición creo que es lo mismo. Saber manejar Photoshop en mi opinión es una falacia, lo que realmente sabes son ciertas filosofías que por el mero hecho de estar frente a un programa de retoque esperas poder encontrar en él: contrastes, brillos, niveles, selecciones, capas, etc. Y es cuando no encuentras una de estas filosofías genéricas cuando yo creo que podemos decir: "este es un mal programa o este programa no tiene un buen reemplazo".

La diferencia de calidad en sentido positivo, entre diferentes programas de un mismo área, no viene dada por esas filosofías. Una vez estamos de acuerdo que 2 programas las comparten, la diferencia de calidad entre un programa y otro yo la defino como las facilidades que me da ese programa a la hora de trabajar, es decir, dicho en términos temporales: cuán productivo puede llegar a ser este programa respecto de este; o cuánto me ayuda en mi flujo de trabajo.

Por poner un ejemplo extremo. Creo que podemos estar de acuerdo todos, o tomar como base, que podemos maquetar una página o bien con un programa de maquetación diseñado ex profeso para ello, pongamos InDesign, o bien con un programa de edición y retoque de imágenes, pongamos Photoshop. Puede sorprender, pero si pensamos en las filosofías a las que hacía referencia antes, pensemos que un programa de maquetación trabaja fundamentalmente con texto (párrafos, negritas, etc.), con márgenes y distancias, y por último con imágenes. Pues bien, Photoshop, aunque simple, tiene una herramienta de texto que permite controles básicos sobre el mismo: cambios en el aspecto, negritas, cursivas, etc.; distintos tipos de justificaciones; y para la cuestión de los margenes, el texto al ser una capa más de la composición tenemos plena libertad de moverlo por la pantalla. Los márgenes de la página y entre noticias o textos nuevamente responden a lo mismo, cada cosa es una capa y por lo tanto podemos mover libremente cada una para tener los márgenes adecuados; además de tener las guías como forma de respetar siempre esas distancias. Por último, qué mejor programa que Photoshop para manejar imágenes, ¿no? Según este razonamiento es perfectamente posible diseñar exactamente la misma página tanto en InDesign como en Photoshop. ¿Cuál es la diferencia? Pues que InDesign es un programa pensado específicamente en la maquetación y por lo tanto todas las herramientas y utilidades que tiene están enfocadas en ayudar al usuario a maquetar. Tiene un procesador de textos relativamente potente, facilita la separación entre líneas en un párrafo, auto ajusta el texto a los bordes de una imagen, etc. Todo eso, al contrario, se tiene que hacer en Photoshop a mano. Por lo tanto podemos decir que para maquetar el InDesign es mejor programa, pero únicamente porque da las facilidades para la maquetación que otros programas no específicos no dan.

Una vez estamos en este nivel evidentemente hay preferencias. Pongamos InDesign y Quark. Habrá gente que le guste más uno que otro, pero no creo que sea porque no sepan manejar el opuesto (probablemente no lo haya ni intentado) sino porque las facilidades que le da uno de ellos no las encuentra en el otro y ve que su flujo de trabajo es mejor. Por lo tanto, toma una decisión que es, yo prefiero A sobre B, pero no digo que B no sea malo o no sepa usarlo, simplemente es que A me gusta más porque me ayuda más. Es decir, volvemos a lo que decía Miguel Ángel Fuertes: "Yo sólo quiero animar". En 3D hace años había un ejemplo clarísimo, había un axioma de facto que decía "Se modela en Maya, se anima en Softimage". La razón es que simplemente Maya a pesar de tener capacidad de animación no era tan potente como Softimage y viceversa, Softimage permitía modelar, pero las herramientas de Maya eran muchísimo más potentes.

Volviendo a InDesign/Photoshop vemos claramente la cuestión de la productividad y el flujo de trabajo. Para maquetar en InDesign una página normal quizás usemos 10-15 minutos, dependiendo. En cambio esa misma página en Photoshop nos puede llevar horas para que quede igual. Pero eso no significa que una página maquetada en Photoshop esté mal maquetada o que la persona que lo haya hecho no sepa maquetar. Maquetar (como otras aŕeas editar, diseñar, etc.) no es saber manejar un programa, es tener unas filosofías y unas ideas en la cabeza que el programa sólo te puede susurrar de forma intuitiva. A mí cuando alguien me dice que sabe montar porque ha hecho un curso de Avid me echo a reír, porque montar, y de eso los rusos saben algo, es mucho más que saber empalmar un plano tras otro.

Así que volviendo al tema, por cerrar. La gente que dice que no migra a GNU/Linux por que no se puede instalar Photoshop (o llámalo equis) es o bien por desconocimiento de que tiene un buen reemplazo: GIMP; o bien porque realmente le da pereza migrar, pero pone la excusa del programa para no decir: "No, estoy cómodo con Windows, no me des más la lata con el pingüino".

PD. A pesar de que uso GIMP, le veo una falla en estas facilidades que decía, respecto de Photoshop. La interfaz. En Photoshop presionando 'F' te pone el lienzo a pantalla completa y puedes moverlo a tu antojo. En cambio en GIMP, a pesar de que maximices la ventana esta te limita la capacidad de movimiento del lienzo a sus bordes por lo tanto pintar o acceder a zonas en los bordes de la imagen a veces es una tortura.

Previsualizar Ficheros RAW en GNU/Linux

Un apunte rápido y de los que me fastidian. Si tenéis alguna foto en formato RAW, da igual la marca de la cámara, habréis visto que GNU/Linux no os hace la previsualización del archivo, cuando el sistema realmente sí tiene soporte para esto. Se debe a que no viene instalado por defecto (he probado varias distribuciones y en ninguna viene) el paquete dcraw, que es el encargado de dar soporte a este tipo de archivos.

Esto es una de las cosas que menos me gustan del pingüino. Puede que una minoría use este paquete, pero son únicamente ~200kb y eso siempre cabe. Sobretodo si le quitas al usuario novel el tener que romperse la cabeza buscando la forma de previsualizar sus archivos RAW. Son en este tipo de cosas en las que fallan siempre las distintas distribuciones y son las que el usuario final más agradece. Además que no es que sea un programa poco usado, lo utilizan para procesar RAW, entre otros: Photoshop, ACDSee y Picasa.

Así que ya sabéis:

• yum install dcraw
• sudo apt-get install dcraw
• urpmi dcraw

O como quiera que sea en tu distro

HDR en Linux (I)

Una de las cosas que me ha traído loco desde que tengo cámara digital es poder crear imágenes de alto rango dinámico o HDRI, como se conocen en sus siglas inglesas (High Dynamic Range Images).

Ya conocía desde hace bastante tiempo este tipo de imágenes, había leído un montón de cosas sobre ellas en las Cinefex, y en la cinematografía de los últimos 5 años se han venido usando con bastante frecuencia. De forma que toda película medianamente actual cuyo presupuesto de efectos especiales sea casi igual al de las facultades en pinchos de tortilla, usará imágenes HDR durante la post-producción. De hecho, seguro que habéis visto a algún tipo que lleva una extraña bola de cromo sujeta por un palo pasearse por los decorados. A esa bola se la llama lightprobe, y el tipo lo que hace es medir la intensidad de la luz y elegir el tiro de luz para luego crear las imágenes HDR.

Pero qué son las imágenes de alto rango dinámico (HDRI). El concepto es realmente simple, son únicamente imágenes tomadas de un mismo sitio con diferente exposición (sea variando el diafragma o la obturación), luego esas imágenes se unen en un único archivo que las contiene todas. Una HDRI abierta con cualquier programa y vista no es más que una fotografía que en lugar de pesar 3-4MB pesa 30. Metiéndonos en cosas más técnicas podemos decir que las imágenes HDRI por el hecho de tener todos los datos de variación de luminancia y crominancia en 1 pixel dado es capaz, con la interpretación correcta, de reproducir la luz que emite ese mismo pixel para una determinada abertura. Es decir, se produce el proceso contrario, precisamente por tener X imágenes con todos los valores de luminancia y crominancia posibles, hace posible que para una exposición dada, es decir, tomar como base una de esas imágenes, se puedan extrapolar del resto la información lumínica de la misma y convertirla en luz dentro de, por ejemplo, un paquete 3D como Maya o Softimage. Además, el hecho de que las imágenes que la componen se hayan tomado variando la exposición hace que la respuesta de la HDRI sea logarítmica y no lineal y, por lo tanto, tengamos una salida físicamente realista con una HDRI.

Por otro lado, y para entender en conjunto las HDRI, hablemos del 3D. Uno de los grandes problemas del 3D es la iluminación. Aunque es relativamente fácil emular fuentes de luz realistas en un software 3D, es realmente complicado que esas luces se comporten físicamente igual a como lo hacen en la realidad. No es complicado por dificultad operativa, es decir, sea un problema difícil de resolver, sino porque es un tremendo costo en recursos tratar de emular una luz física. Dicho de otra manera, o tienes cientos y cientos y cientos de procesadores para renderizar imágenes o mejor que busques alguna técnica alternativa. Por otro lado, a la hora de integrar imágenes sintéticas con imágenes reales se plantea el problema de que ambos ambientes cuadren lumínicamente, es decir, es evidente que no puedes poner un personaje sintético iluminado como si fuera un atardecer dentro de un plano que sea a pleno sol de mediodía. Las HDRI vienen a paliar un poco ambos problemas, aunque más el segundo que el primero.

1. Al ser imágenes, el ordenador se evita algunos cálculos a la hora de calcular una iluminación global (los rebotes de la luz) pues no tiene que calcular cual es la intensidad de la luz desde cada punto, le viene dada por la imagen, solo tiene que calcular su resultado. El hecho de que tenga virtualmente todos los valores posibles de iluminación en una escena dada hace posible esto.
2. En el segundo aspecto una HDRI, al ser meras imágenes tomadas de un espacio real, son capaces de reproducir casi con total exactitud las condiciones lumínicas de ese espacio. Este último es realmente el gran avance que han supuesto las HDRI. Pues son una forma fácil, rápida y sobretodo, barata de resolver este problema. Es tan sencillo como hacer una serie de fotos (al menos 5 a distinta exposición) de un decorado y luego procesarlas para tener todo el ambiente lumínico del mismo de la forma más precisa posible, antes había que hacerlo un poco a ojo y con "luces truco".

Ahora volvemos a nuestro querido supervisor de efectos visuales y su lightprobe y es que este tipo lo que hace, como dijimos es calcular el punto desde el cual se pueda obtener el mejor "tiro de luces"; una vez elegido se pondrá la lightprobe sobre un pedestal a la altura que se estime oportuna y se harán las fotos que hagan falta. No hay que decir que hay que ser extremadamente preciso, pues cualquier movimiento de la cámara durante cualquiera de las exposiciones puede hacer que salga falseada la imagen.

Por último una cosa curiosa, y es que se usan estas bolas cromadas porque abarcan un ángulo de visión realmente amplio de más de 180º, por eso se fotografían estas bolas y se desprecia la oclusión de luz que pueda aportar la cámara, que evidentemente sale en las fotos, aunque hay algunas técnicas para borrarla. Por otro lado, aunque ya lo comentaremos, la mejor forma de tener nuestra lightprobe en casa, pues son bastante caras, es hacerse con una bola relativamente grande y plateada de navidad, de las del árbol. Otra opción, aunque no es muy recomendada es usar objetivos angulares (<18mm), porque causan aberraciones en la perspectiva y efectos de barrilete, que aunque se pueden corregir, es engorroso y lento.

Algunos enlaces interesantes:

• HDRI en la Wikipedia en español (y en inglés)
• Debevec, la web del tipo que invento las HDRI.
• OpenEXR, implementación libre creada por la ILM de las imágenes HDRI.
• Crear imágenes HDR con bolas de navidad
• Maxwell Render, un motor de render físicamente realista
• VRay otro motor de render con capacidad de tener entrada HDR. Por lo que se ha dicho, es fácil pensar que la arquitectura es uno de los puntos donde el HDR se mueve más y en la galería de VRay se da cuenta de ello.