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.

"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.