Cómo habilitar la aceleración por hardware en navegadores Linux

Si usas Linux a diario es muy probable que alguna vez hayas notado que al reproducir vídeos en el navegador el ventilador se dispara, la CPU se pone al 100% y el portátil parece que va a despegar. Eso suele ser síntoma de que la aceleración de vídeo por hardware no está bien activada: el procesador acaba haciendo el trabajo que debería hacer la GPU y el resultado es más ruido, más temperatura y menos batería.

La buena noticia es que hoy en día Firefox, Chromium y casi todos sus derivados ya incluyen soporte real de VA-API y aceleración por hardware en Linux, aunque raras veces viene bien afinado de fábrica. En esta guía vamos a repasar, paso a paso y con todo lujo de detalles, cómo preparar los drivers, cómo activar VA-API en los principales navegadores y cómo comprobar de verdad que el vídeo se está decodificando en la GPU y no en la CPU.

Qué es la aceleración por hardware de vídeo y por qué te interesa activarla

Cuando hablamos de aceleración por hardware en navegadores nos referimos a descargar en la GPU el trabajo pesado de decodificar y procesar vídeo, en lugar de dejarlo todo a la CPU. En la práctica, esto implica que al reproducir contenido multimedia (YouTube, Netflix, Twitch, etc.) la tarjeta gráfica se encarga de descomprimir y procesar los fotogramas del vídeo, mientras que la CPU queda mucho más libre.

La tecnología que hace de puente entre aplicaciones y GPU en Linux para vídeo se llama VA-API (Video Acceleration API), y es el estándar de facto en el escritorio del pingüino. Muchos programas la soportan: navegadores, reproductores como VLC u OBS Studio para codificar/decodificar con la gráfica, e incluso herramientas de edición y captura.

Las ventajas prácticas de tener la aceleración de vídeo funcionando en condiciones son bastante claras en el día a día: menos uso de CPU, menor consumo energético, temperaturas más contenidas y una reproducción más estable, especialmente en portátiles antiguos o con procesadores modestos (2C/4T, por ejemplo).

Como contrapartida, hay algunas desventajas y limitaciones que conviene tener en mente desde el principio: muchas GPUs antiguas han dejado de recibir soporte para códecs modernos, algunos navegadores limitan la resolución cuando se usa H.264 en vez de VP9/AV1, y una implementación floja de VA-API puede provocar artefactos, pantallas verdes o tirones en ciertos vídeos.

Además, en Linux el soporte sigue siendo algo más delicado que en Windows: el combo drivers + VA-API + navegador no siempre funciona a la primera, y la situación puede ser muy distinta según uses Intel, AMD o NVIDIA y según la distro. Por eso es clave entender primero qué hardware tienes, qué drivers estás usando y qué códecs soporta tu GPU.

Revisar qué GPU tienes y qué drivers usa tu Linux

Antes de tocar nada en Firefox o Chromium tienes que saber exactamente qué gráfica tienes instalada y qué driver está cargando el kernel. Esto es fundamental para escoger el paquete VA-API correcto y evitar errores raros después.

Para identificar la GPU en un sistema basado en Linux basta con lanzar en un terminal algo como: lspci -k | grep -EA3 'VGA|3D|Display'. La salida te dirá el modelo de la tarjeta y el módulo del kernel que está usando, por ejemplo una Intel UHD Graphics 600/620 con el driver i915.

Si tu equipo solo tiene una GPU verás normalmente un dispositivo tipo “VGA compatible controller” y el driver en uso, mientras que si tienes un portátil híbrido (iGPU Intel + dGPU AMD/NVIDIA) aparecerán dos dispositivos gráficos. Esto es importante porque en escenarios multi-GPU hay dos dispositivos DRI de renderizado implicados.

Para confirmar qué dispositivos de render tienes, lista el contenido de /dev/dri con: ls /dev/dri. En un equipo sencillo verás algo como card0 y renderD128; en uno híbrido aparecerán también card1 y renderD129.

Si quieres ir un paso más allá y saber qué driver está asociado a cada dispositivo DRI, puedes consultar /sys/kernel/debug/dri/128/name, /sys/kernel/debug/dri/129/name, etc. Por ejemplo, un fichero que contenga “i915” te indica que ese render node corresponde a la iGPU Intel, mientras que uno con “radeon”, “amdgpu” o “nouveau” representará a la GPU AMD o NVIDIA utilizada por el sistema.

Drivers VA-API en Ubuntu y distros derivadas: Intel, AMD y NVIDIA

Una vez identificada la GPU, el siguiente paso es instalar el driver VA-API adecuado para que la gráfica pueda decodificar vídeo por hardware. En distribuciones basadas en Debian/Ubuntu esto se hace vía apt con unos pocos paquetes clave.

Para GPUs Intel existen básicamente dos familias de drivers VA-API: la “clásica” i965 y la más moderna iHD (intel-media-driver), y además suelen ofrecerse variantes libres y “non-free”. A grandes rasgos:

• i965-va-driver: driver libre para VA-API soportado en generaciones Cantiga, Ironlake, Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake y Cannon Lake.
• i965-va-driver-shaders: variante privativa para esas mismas generaciones, con ciertas optimizaciones.
• intel-media-va-driver: driver VA-API libre recomendado para Broadwell en adelante (Skylake, Kaby Lake, Coffee Lake, Whiskey Lake, Cannon Lake, Ice Lake, Alchemist, Meteor Lake, etc.).
• intel-media-va-driver-non-free: versión privativa del anterior, que añade funcionalidades extra como codificación por hardware en códecs modernos tipo H.265, dependiendo del hardware.

En un portátil típico con Intel UHD 600/620, por ejemplo, puedes instalar la variante moderna y privativa con: sudo apt install intel-media-va-driver-non-free vainfo. El paquete vainfo sirve para inspeccionar después qué códecs exactos soporta tu GPU.

Tras la instalación deberías tener en /usr/lib/x86_64-linux-gnu/dri/ un fichero iHD_drv_video.so (para intel-media-driver) o i965_drv_video.so (para i965). Estos binarios son los que VA-API carga internamente cuando un navegador u otra aplicación solicita aceleración de vídeo.

Para AMD Radeon y GPUs NVIDIA usando el driver libre Nouveau, en Ubuntu la pieza central es mesa-va-drivers, que instala los backends VA-API necesarios para estas tarjetas. En el caso de tarjetas NVIDIA con driver propietario la película se complica: VA-API como tal no está soportado directamente, sino a través de un puente VDPAU→VAAPI (por ejemplo con vdpau-va-driver), y aun así los navegadores prácticamente no se apoyan en VDPAU hoy por hoy.

Si tienes un equipo híbrido Intel + AMD o Intel + NVIDIA con drivers libres, lo normal es instalar tanto el driver VA-API para Intel (iHD o i965) como mesa-va-drivers, de forma que puedas elegir qué GPU se encarga de la decodificación de vídeo. Más adelante veremos cómo seleccionar un dispositivo DRI concreto vía variables de entorno.

Drivers VA-API en Fedora y su peculiaridad con NVIDIA

En Fedora el planteamiento es similar, pero cambia el gestor de paquetes y algunos nombres de paquetes específicos. Para gráficas Intel el soporte VA-API suele pasar por instalar:

En una terminal, con privilegios de administrador, puedes tirar de: sudo dnf install libva-intel-driver intel-mediasdk intel-media-driver. Así te aseguras de tener tanto el driver clásico como el nuevo y las bibliotecas asociadas.

Si utilizas AMD Radeon o NVIDIA con el driver libre Nouveau, el soporte VA-API viene incluido en el paquete mesa-dri-drivers, que en Fedora Workstation suele instalarse por defecto. Aun así, en algunos equipos el resultado real con VA-API sobre AMD/Nouveau puede ser irregular o incluso fallar.

La ventaja de Fedora respecto a Ubuntu en el terreno NVIDIA propietario es que el puente VDPAU para VA-API (como libva-vdpau-driver) suele estar disponible directamente en los repos oficiales. Por ejemplo, puedes instalarlo con sudo dnf install libva-vdpau-driver, aunque eso no garantiza que los navegadores hagan uso real de VDPAU en la práctica.

Comprobar con vainfo qué códecs soporta realmente tu GPU

Instalar los paquetes no basta: necesitas saber qué códecs y qué modos (codificación/decodificación) soporta tu GPU a través de VA-API para no pegarte con ajustes imposibles. Aquí entra en juego vainfo, que lista perfiles soportados para un dispositivo DRI y un driver VA-API concretos.

La forma más robusta de lanzar vainfo es indicando explícitamente el nombre del driver y el dispositivo render de interés, por ejemplo: LIBVA_DRIVER_NAME=iHD vainfo --display drm --device /dev/dri/renderD128. Así evitas confusiones en equipos con varias GPUs o varios drivers instalados.

La salida típica de vainfo arranca indicando la versión de VA-API y el driver, y a continuación muestra una larga lista de “profile y entrypoints”. Cada línea suele tener un perfil de códec (MPEG2, H264Main, H264High, HEVCMain, VP8, VP9, AV1…) y un modo de entrada/salida.

Lo que nos interesa para reproducción de vídeo es que aparezcan entradas del estilo VAEntrypointVLD para el códec deseado, ya que eso significa que la GPU puede decodificarlo por hardware. Por ejemplo, ver VAProfileH264High : VAEntrypointVLD implica soporte de decodificación H.264; ver VAProfileVP9Profile0 : VAEntrypointVLD implica soporte VP9 por hardware, y así sucesivamente.

En GPUs veteranas verás normalmente soporte cómodo para H.264 pero ausencia de VP8, VP9 o AV1, lo que obliga a tirar de extensiones en el navegador para forzar a las webs a servir H.264 en lugar de códecs más recientes. Ojo porque si el vídeo solo existe en VP9/AV1, no hay truco mágico: se decodificará por software.

Si vainfo devuelve errores del tipo “va_openDriver() failed” o no es capaz de inicializar el driver solicitado, es probable que tu GPU no sea compatible con ese backend concreto. En ese caso, suele funcionar cambiar de iHD a i965 en Intel viejas, o comprobar que el paquete Mesa correspondiente está correctamente instalado para AMD/Nouveau.

Configurar variables de entorno para fijar driver VA-API y dispositivo DRI

Muchos tutoriales dan por sentado que el primer dispositivo DRI (renderD128) es siempre la iGPU y que el sistema elige el driver correcto sin más, pero en la práctica, sobre todo en portátiles con varias GPUs, esto puede no cumplirse. De ahí la importancia de fijar algunas variables de entorno antes de arrancar el navegador.

Las tres variables más usadas para controlar VA-API y el back-end gráfico de Firefox en Linux son:

• MOZ_WAYLAND_DRM_DEVICE: ruta al dispositivo DRI que debe usar (por ejemplo, /dev/dri/renderD128 o /dev/dri/renderD129).
• LIBVA_DRIVER_NAME: nombre corto del driver VA-API que debe cargarse (i965, iHD, nouveau, r600, radeonsi, etc.).
• MOZ_X11_EGL / MOZ_ENABLE_WAYLAND: indicadores enteros (0/1) para habilitar el uso de EGL y la ruta específica según estés en Xorg o Wayland.

Por ejemplo, para lanzar Firefox en una sesión X11 usando una Intel HD con driver iHD podrías usar algo como: MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD128 LIBVA_DRIVER_NAME=iHD MOZ_X11_EGL=1 firefox. En Wayland la variante sería similar pero con MOZ_ENABLE_WAYLAND=1 en lugar de MOZ_X11_EGL.

Para no tener que escribir esto en cada arranque, muchos usuarios añaden LIBVA_DRIVER_NAME=iHD (o el que toque) al fichero global /etc/environment, de modo que el sistema entero tenga por defecto ese driver VA-API. Aun así, mantener MOZ_WAYLAND_DRM_DEVICE y MOZ_X11_EGL/MOZ_ENABLE_WAYLAND en el lanzador o script de Firefox sigue siendo recomendable en portátiles híbridos.

En escritorios como KDE Plasma puedes editar el lanzador de Firefox y anteponer “env” seguido de las variables a la orden de ejecución para no depender siempre del terminal. Algo del tipo Exec=env MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD128 LIBVA_DRIVER_NAME=iHD MOZ_X11_EGL=1 firefox %u suele funcionar bien.

Activar la aceleración por hardware en Firefox (VA-API + WebRender)

Mozilla introdujo soporte VA-API oficial en Firefox para Linux empezando por Wayland y extendiéndolo después a X11, pero durante mucho tiempo venía desactivado por defecto o a medio cocinar. Por eso muchos tutoriales recomiendan retocar varias preferencias internas para sacar todo el jugo.

Lo primero es entrar en la famosa página de configuración avanzada: escribe about:config en la barra de direcciones, acepta la advertencia y usa el buscador de la parte superior. A partir de ahí, hay varios grupos de ajustes relevantes.

Para habilitar el compositor moderno basado en GPU deberías activar el motor WebRender o forzar el uso de OpenGL: busca gfx.webrender.all y ponlo a true, y si lo prefieres, también puedes forzar layers.acceleration.force-enabled a true para asegurarte de que Firefox intenta tirar de la GPU.

En segundo lugar, hay que asegurarse de que Firefox utiliza FFmpeg con VA-API en lugar de sus decodificadores internos cuando corresponda. Para ello localiza estas claves y ajusta sus valores:

• media.ffmpeg.vaapi.enabled → true (permitir el uso de VA-API vía FFmpeg).
• media.ffvpx.enabled → false (deshabilitar el decodificador interno FFVPX para obligar a usar FFmpeg).
• media.av1.enabled → false si tu GPU no soporta AV1 por hardware, dejando que la web ofrezca preferentemente otros códecs más “amigables”.
• media.rdd-vpx.enabled → en GPUs modernas con soporte VP9 por hardware puede ir a true; en gráficas antiguas es preferible dejarlo en false.

En máquinas con varias GPUs y drivers libres (Intel + AMD, por ejemplo) se puede además jugar con las variables MOZ_WAYLAND_DRM_DEVICE y LIBVA_DRIVER_NAME para decidir si el vídeo se decodifica en la iGPU o en la dGPU. Por ejemplo, apuntando a /dev/dri/renderD129 con LIBVA_DRIVER_NAME=r600 o radeonsi para usar la Radeon como aceleradora de vídeo.

En sistemas donde, aun tocando estos parámetros, VP9 y AV1 sigan resultando demasiado pesados, una solución práctica es forzar el uso de H.264 con extensiones como h264ify o Enhanced h264ify. Estas extensiones bloquean VP8/VP9/AV1 en sitios como YouTube y piden específicamente flujos AVC1 (H.264), que casi todas las GPUs con VA-API decodifican sin despeinarse.

Una vez hechos los cambios, cierra Firefox por completo, arráncalo con las variables de entorno adecuadas y prueba a reproducir un vídeo de YouTube a 1080p60 mientras monitorizas la carga de CPU y GPU. Notarás especialmente la mejora en equipos de hace más de una década, donde la CPU ya va muy justo para procesar vídeo en alta resolución por software.

Verificar que Firefox está usando la GPU para decodificar vídeo

No basta con que “parezca” que el navegador va más suave: conviene comprobar de forma objetiva que VA-API se está utilizando y que los fotogramas se descodifican en la GPU. Hay varias formas de hacerlo en Firefox bajo Linux.

La primera es simplemente mirar la salida del terminal desde el que has lanzado Firefox con las variables de entorno configuradas. Si todo va bien, deberías ver mensajes de libva info indicando que va_openDriver() returns 0 y referencias al driver cargado (por ejemplo, i965 o iHD) sin errores posteriores.

Si usas GPUs Intel puedes recurrir a intel_gpu_top (parte de intel-gpu-tools) para ver secciones de actividad específicas, como “Video”, que representan el porcentaje de uso del motor de decodificación. Sin VA-API verás esa columna a cero aunque el vídeo vaya a tirones; con VA-API activa, debería mostrar un porcentaje notable mientras el vídeo se reproduce.

En gráficas Radeon, la herramienta equivalente es radeontop, que muestra barras de uso de GPU y VRAM. Aunque no siempre separa un apartado explícito para la decodificación de vídeo, sí es fácil ver cómo la actividad sube cuando VA-API está funcionando y se dirige correctamente el driver (por ejemplo, r600 o radeonsi) al dispositivo DRI Radeon.

En entornos con varias GPUs, además, puedes necesitar añadir opciones como --bus en radeontop para monitorizar sólo la tarjeta adecuada. En cualquier caso, el patrón es el mismo: si la CPU baja y la GPU tiene más trabajo cuando reproducimos vídeo, vamos por buen camino.

Por último, repetir la misma prueba con extensiones tipo h264ify activadas y desactivadas permite comprobar el impacto real de cambiar VP9/AV1 por H.264 en el consumo de recursos. Las mediciones realizadas en equipos con i5-2450M y i7-7700HQ muestran reducciones de uso de CPU que, en procesadores modestos, pueden llegar a la mitad cuando VA-API entra en juego.

Aceleración por hardware en Chromium, Chrome y derivados (VA-API + flags)

Chromium 88 marcó un antes y un después al introducir soporte “serio” de VA-API en Linux, aunque con matices: fuerte dependencia de Xorg, necesidad de usar ciertos flags y mejor soporte para Intel y NVIDIA que para Radeon. Aun así, ese soporte se ha ido heredando a toda la familia: Google Chrome, Edge, Brave, Vivaldi, Opera, etc.

El primer paso en cualquier navegador basado en Chromium es revisar la página de flags interna, accesible con chrome://flags en Chrome y Chromium, brave://flags en Brave, edge://flags en Edge, vivaldi://flags en Vivaldi u opera://flags en Opera. Una vez dentro, busca y activa al menos:

• Override software rendering list → Enabled (obliga a ignorar la lista negra de GPUs y forzar características aceleradas).
• Hardware-accelerated video decode → Enabled (habilita la decodificación de vídeo por hardware).

Tras activar estas opciones el navegador te pedirá reiniciar para aplicar los cambios; hazlo y luego visita chrome://gpu (o la variante para tu navegador) para comprobar el estado de “Graphics Feature Status” y “Video Acceleration Information”. Lo ideal es que todo lo relevante aparezca como “Hardware accelerated”.

El siguiente punto clave en Chromium y derivados es cómo se arranca la aplicación desde la línea de comandos. En sesiones Xorg suele ser recomendable añadir el flag --use-gl=desktop, mientras que en sesiones Wayland donde el navegador corre sobre XWayland, a menudo se usa --use-gl=egl para evitar problemas.

Además, hay un conjunto de flags relacionados con VA-API en Chromium que conviene añadir, ya sea a la orden de ejecución o a un archivo de configuración de flags:

• --enable-accelerated-video-decode
• --enable-accelerated-video-encode
• --enable-features=VaapiVideoDecoder
• --disable-features=UseChromeOSDirectVideoDecoder

Por ejemplo, en Xorg con Google Chrome estable podrías lanzar algo como: google-chrome-stable --use-gl=desktop --enable-accelerated-video-decode --enable-accelerated-video-encode --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder. El mismo patrón se aplica a Brave (brave-browser), Vivaldi (vivaldi), Opera (opera) o Edge (microsoft-edge).

En distros como CachyOS, Arch y similares, muchos navegadores permiten centralizar estos flags en ficheros tipo ~/.config/chromium-flags.conf, ~/.config/brave-flags.conf o análogos. Otra alternativa común es editar el fichero .desktop del navegador, copiarlo de /usr/share/applications a ~/.local/share/applications y añadir los flags a la línea Exec=.

Una vez más, si quieres que todo sea persistente y no depender de la terminal, lo mejor es editar ese .desktop o el lanzador en el menú del entorno de escritorio para que siempre añada los flags correctos. Así al abrir el navegador desde el menú o el dock siempre se respetan las opciones de VA-API.

Comprobar la decodificación por hardware en navegadores Chromium

En la familia Chromium hay dos formas principales de verificar que la decodificación de vídeo está ocurriendo por hardware. Una es más genérica y la otra aprovecha las herramientas de desarrollo.

La vía rápida es visitar chrome://gpu (o el equivalente de tu navegador) y revisar que en “Video Acceleration Information” aparezcan entradas con estado “Hardware accelerated”. Esto da una visión global de las capacidades, pero no te asegura que un vídeo concreto use realmente la GPU.

Para comprobar un caso real, abre un vídeo (por ejemplo, en YouTube), después entra en las herramientas de desarrollador con F12 o Ctrl+Shift+I y busca la pestaña Media (si no aparece, la encontrarás en el menú de pestañas adicionales). Dentro de Media, selecciona el player del vídeo que estás reproduciendo.

En la información detallada del reproductor verás un campo que indica el tipo de decodificador de vídeo utilizado y si el “Hardware decoder” está a true. Lo ideal es ver un decodificador asociado a VA-API/GL y con hardware decoder activado; si en cambio ves nombres como VpxVideoDecoder, FFmpegVideoDecoder o Dav1dVideoDecoder sin referencia a hardware, es probable que se esté tirando de software.

En algunas versiones antiguas se recomendaba usar chrome://media-internals para esta misma comprobación, y revisar campos como kVideoDecoderName, donde un valor tipo MojoVideoDecoder indicaba uso de aceleración por hardware frente a los decodificadores puramente software. Con las herramientas modernas la pestaña Media del DevTools ha relevado a esa página en gran medida.

Por último, puedes combinar esta verificación con herramientas de monitorización de GPU similares a las vistas en Firefox (intel_gpu_top, radeontop, amdgpu_top, nvtop, etc.), asegurándote de que cuando el navegador reproduce vídeo, los motores de vídeo de la GPU muestran actividad real.

Codificación y códecs: H.264, VP9, AV1 y extensiones como h264ify

Un detalle que suele pasar desapercibido es que, aunque la GPU soporte VA-API, si el códec del vídeo no está implementado en el hardware, terminarás en el terreno de la decodificación por software sí o sí. Es aquí donde entran en juego extensiones y configuraciones extra.

H.264/AVC1 es el códec “comodín” que prácticamente todas las GPUs con unos años a sus espaldas manejan bien vía VA-API, mientras que VP8, VP9 y AV1 sólo están hardware-acelerados en generaciones relativamente modernas. Esto se ve claramente en la salida de vainfo, donde GPUs antiguas muestran soporte sólo para H.264 y poco más.

Plataformas como YouTube, sin embargo, priorizan VP9 o incluso AV1 para los navegadores modernos, quedando H.264 como opción secundaria o sólo para resoluciones concretas. Por eso, aunque tengas VA-API configurado, si YouTube decide servirte VP9 y tu GPU no lo soporta, la CPU se llevará el castigo.

Ahí es donde extensiones como h264ify y sus forks (Enhanced h264ify, etc.) son tremendamente útiles: bloquean VP8/VP9/AV1 y fuerzan a la web a usar el perfil H.264 disponible cuando existe. Eso sí, si no hay versión H.264 de un vídeo concreto, no podrán inventársela.

Conviene tener presente que YouTube, cuando se ve obligada a usar H.264, limita a menudo la resolución máxima a 1080p a 60 FPS, mientras que con VP9/AV1 puede ofrecer 1440p, 4K y frame rates altos. Por tanto, activar h264ify implica a veces renunciar a la máxima resolución posible a cambio de tener una reproducción más fluida y menos agresiva con la CPU.

En el caso de códecs de nueva generación como AV1, sólo las GPUs muy modernas cuentan con soporte real de decodificación por hardware, de modo que en la mayoría de PCs actuales sigue siendo mejor desactivarlo en el navegador si notas que tus ventiladores se convierten en turbinas al ver cualquier vídeo.

Impacto real en rendimiento: cuándo compensa pelearse con VA-API

Las pruebas empíricas hechas en portátiles con CPUs de 2 núcleos y 4 hilos (por ejemplo, un i5-2450M de hace años) muestran que activar VA-API y delegar la decodificación de H.264 en la GPU puede prácticamente reducir a la mitad el uso medio de CPU durante la reproducción de un vídeo 1080p60 en Firefox. Esto se traduce en equipos más frescos y silenciosos, y en una experiencia mucho más estable.

En máquinas más recientes con procesadores de 4C/8T o superiores (como un i7-7700HQ), la diferencia en porcentaje de CPU es menos dramática, a veces del orden de un 3-6% menor. Aun así, la carga tiende a repartirse mejor y se reducen los picos extremos de uso que pueden provocar pequeños tirones.

Curiosamente, si se compara la reproducción en navegador con VA-API frente a un reproductor como VLC configurado también con VA-API, se observa que el consumo de CPU del navegador suele ser sensiblemente más alto. Esto sugiere que aún hay margen de mejora en la forma en que los navegadores integran VA-API y gestionan la transferencia de datos entre CPU y GPU en Linux.

En cualquier caso, para portátiles humildes o de hace varios años, dedicar un rato a dejar bien afinada la aceleración por hardware puede marcar la diferencia entre tener que renunciar a vídeos a 1080p y poder consumir contenido en alta resolución sin que el sistema sufra. En equipos potentes la mejora existe, pero es más sutil y en muchos escenarios quizá no valga la pena complicarse demasiado si ya te va “suficientemente bien”.

Lo que sí parece claro es que la combinación Linux + navegadores modernos + VA-API está aún un poco por detrás de la experiencia que se consigue en Windows, donde los caminos para delegar el vídeo en la GPU están más pulidos y estandarizados. Aun así, con los pasos adecuados se puede lograr un comportamiento muy digno también en el escritorio del pingüino.

Si has llegado hasta aquí, ya sabes que habilitar la aceleración por hardware de vídeo en Linux no consiste sólo en marcar una casilla en el navegador, sino en alinear bien drivers VA-API, variables de entorno, flags internos y elección de códecs para que Firefox, Chrome, Brave y compañía trabajen codo con codo con tu GPU en lugar de castigar la CPU sin necesidad.