Instalas DaVinci Resolve en Linux, arrastras un MP4 del móvil a la línea de tiempo y ocurre una de dos cosas: no aparece nada, o bien se muestra la pista de audio y la imagen es negra. El archivo se reproduce perfectamente en VLC, en el navegador y en cualquier otro sitio. En Resolve, no.
No has hecho nada mal. DaVinci Resolve en Linux no sabe abrir H.264 ni H.265, que es el formato en el que está grabado prácticamente todo lo que sale de un móvil, de una cámara de acción o de una réflex. Tampoco entiende el audio en AAC, que acompaña a esos mismos ficheros.
Lo sorprendente es que el mismo programa, en su versión gratuita, sí los abre en Windows y en Mac. No se trata de que la versión de Linux esté peor programada: es que le faltan piezas a propósito, y el motivo no es técnico.
Vamos a analizar qué le falta exactamente, por qué le falta, qué puedes hacer hoy para trabajar igualmente y qué tendría que hacer Blackmagic para que todo esto dejara de ser un problema. Que es más sencillo de lo que parece.
Para leer más tarde...
Los tres problemas, por orden de gravedad
1. Los códecs: el que te va a doler
Esta es la parte más grave y conviene tenerla clara antes de instalar nada:
- Versión gratuita en Linux: sin H.264 ni H.265. Ni para leer ni para exportar. Da igual el contenedor: si dentro va H.264, Resolve no lo toca.
- Versión Studio (la de pago): sí lee y exporta H.264 y H.265. Pagar arregla el vídeo.
- El audio AAC no funciona en ninguna de las dos. Ni siquiera pagando. Y AAC es lo que lleva dentro casi todo lo que graba un móvil.
En resumen, la versión de pago soluciona el problema de la imagen, pero deja el sonido a medias.
2. La distribución: oficialmente, casi ninguna
Blackmagic ofrece soporte oficial únicamente para Rocky Linux 8.6 y CentOS 7.3. Y punto. Hasta la versión 20 no publica paquetes .deb ni .rpm para Ubuntu, Debian o Linux Mint, que es donde se encuentra la inmensa mayoría de los usuarios.
Lo que ofrecen es un instalador .run diseñado para un entorno específico de estudio de postproducción. Funciona fuera de ese entorno, pero te toca a ti resolver las dependencias, y es ahí donde surgen los errores de bibliotecas que no cuadran y los cuelgues al arrancar.
3. La instalación: manual y frágil
Esto es consecuencia de lo anterior. En Ubuntu hay que pelearse con paquetes que el instalador busca y no encuentra; en Arch se recurre a un paquete de la comunidad; en Fedora ocurre algo similar. Ninguna de esas rutas es oficial, y cualquier actualización de Resolve o del sistema puede volver a romperlo.
intel-compute-runtime en los Core Ultra, por ejemplo).Por qué pasa esto: no es pereza, son patentes
La explicación de los códecs no está en el código, sino en un despacho de abogados.
H.264, H.265 y AAC están cubiertos por patentes. Para distribuir un software capaz de descodificarlos, es necesario pagar una licencia a los consorcios que las gestionan, y dicho pago se realiza por copia distribuida. En el caso de un producto que se regala a millones de personas, el coste se dispara.
Entonces, ¿por qué sí funcionan en Windows y en Mac? Porque en esos casos Blackmagic no pone los códecs: los pone el sistema operativo. Microsoft y Apple ya han pagado esas licencias y las ponen a disposición de los programas que se ejecutan sobre ellos. Resolve se limita a pedirle al sistema que descodifique el fichero.
En Linux no existe ese señor que ya ha pagado. No hay ningún códec del sistema con licencia al que recurrir, por lo que la factura le caería entera a Blackmagic. Y, al tratarse de un producto gratuito, no la paga.
Y el otro motivo, el que nadie dice
Fuera del tema de las patentes, existe un motivo comercial: el Resolve de Linux no está pensado para ti. Está diseñado para estudios de postproducción que utilizan hardware certificado, adquieren la versión Studio, tarjetas de captura Blackmagic y paneles de color, y configuran su estación de trabajo completa con la distribución que indique el fabricante.
Para ese cliente, «solo Rocky Linux» no es una limitación, sino una ventaja: un único entorno que soportar. El problema es que el resto del mundo también quiere usarlo y, en ese sentido, Blackmagic no ha movido un dedo.
Qué puedes hacer hoy
Mientras Blackmagic se decide, existen cuatro salidas. Van desde la más aburrida hasta la más elegante.
1. Transcodificar antes de editar
Es la solución tradicional y la que nunca falla: consiste en convertir el material a un formato que Resolve sí reconozca antes de añadirlo a la línea de tiempo. Los formatos habituales son DNxHR y ProRes.
ffmpeg -i entrada.mp4 -c:v dnxhd -profile:v dnxhr_hq -c:a pcm_s16le salida.mov
Y para procesar una carpeta entera, se puede usar un bucle de los de toda la vida:
for f in *.mp4; do
ffmpeg -i "$f" -c:v dnxhd -profile:v dnxhr_hq -c:a pcm_s16le "${f%.mp4}.mov"
done
Este método funciona, pero conlleva dos inconvenientes que conviene conocer: los ficheros se multiplican de tamaño —un DNxHR HQ ocupa varias veces lo que el H.264 original— y añades un paso a cada proyecto. En el caso de un vídeo largo grabado durante varios días, esto supone un fastidio considerable.
-c:a pcm_s16le no está de adorno: convierte el audio AAC a PCM sin comprimir. Si no lo incluyes, arrastras el problema del sonido al nuevo fichero.2. Pagar la versión Studio
Un pago único de unos 300 euros. Te resuelve H.264 y H.265, pero no el AAC, por lo que en muchos casos seguirás transcodificando el audio. Si vives de esto, se amortiza; si estás empezando, es mucho dinero para arreglar medio problema.
3. El plugin de ffmpeg
Esta es la vía más interesante y la menos conocida. Resolve admite IOPlugins, un sistema de complementos para leer y escribir formatos que el programa no trae de serie. Y ya existe un IOPlugin de ffmpeg que le enseña a Resolve a abrir cualquier cosa que ffmpeg sepa abrir, que es todo.
Lo fundamental de este enfoque es que el códec lo pone el usuario, no Blackmagic. Así, la patente deja de ser un problema para la empresa y el mecanismo es oficial, no un parche.
4. El Flatpak de la comunidad
Ya existen intentos de empaquetar Resolve como Flatpak —siendo resolve-flatpak el más conocido— y sirven para demostrar que la idea funciona: el Flatpak se lleva por delante el problema de la distribución, ya que el paquete incluye sus propias bibliotecas y es indiferente si usas Ubuntu, Fedora o Arch. Además, este proyecto ya empaqueta el IOPlugin de ffmpeg como extensión aparte.
Qué tendría que hacer Blackmagic (y por qué Flatpak lo arregla casi todo)
Si unimos las piezas del capítulo anterior, vemos que la solución ya está inventada. Blackmagic solo tendría que recogerla.
Flatpak resuelve el problema de la distribución de un plumazo
Un Flatpak se lleva sus propias bibliotecas dentro. Así, deja de importar si el usuario utiliza Ubuntu, Fedora, Arch o Mint, y tampoco importa la versión de cada dependencia que tenga. Blackmagic pasaría de ofrecer «soporte para Rocky Linux 8.6» a mantener un paquete que funciona en todas partes, lo cual supone menos trabajo, no más.
Así desaparecerían de golpe los problemas 2 y 3: la distribución no soportada y la instalación frágil.
Y el códec deja de ser su problema
Aquí está lo elegante. En el modelo Flatpak, los códecs con patentes se instalan como extensión aparte —org.freedesktop.Platform.ffmpeg-full es precisamente eso—, y quien la instala es el usuario, no el fabricante.
Blackmagic distribuiría un Resolve sin códecs propietarios, exactamente como hace ahora, y quien lo necesite añadiría la extensión mediante un comando. Es el mismo modelo que usan Fedora y Flathub desde hace años para el resto de programas, y nadie ha ido a la cárcel.
Si a esto le sumamos el IOPlugin de ffmpeg, que ya existe y es un mecanismo oficial de Resolve, el problema de los códecs pasa de ser «imposible por patentes» a convertirse en «un paquete opcional».
Lo que de verdad lo está bloqueando: un formulario
Y aquí llega lo que me parece más absurdo de todo este asunto. La razón por la que no hay un Resolve en Flathub no es técnica ni legal: es que el sistema de compilación de Flathub no tiene acceso a la red durante la construcción y Blackmagic obliga a rellenar un formulario de registro para descargar el programa.
Es decir, no hay una URL directa y estable que permita a un empaquetador descargar el instalador. Todo el asunto se desmorona por ahí.
Lo que Flatpak no arregla
Para no vender humo, hay tres cosas que seguirían dando guerra:
- Las gráficas NVIDIA con el driver propietario exigen que la extensión de Flatpak coincida con la versión del driver del sistema. Se resuelve solo casi siempre, pero cuando falla, cuesta.
- El acceso al hardware desde el sandbox —tarjetas de captura, paneles de color, la llave USB de Studio— necesita permisos y reglas de udev bien puestas.
- AAC seguiría dependiendo de que el usuario instale la extensión. Mejor que hoy, pero no automático.
Ninguna de las tres supone un impedimento: son tareas de empaquetado, y es el trabajo que la comunidad ya ha hecho gratis para demostrar que es posible.
Fuentes
