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.