Instalas DaVinci Resolve en Linux, arrastras un MP4 del móvil a la línea de tiempo y pasa una de dos cosas: no aparece nada, o aparece la pista de audio y donde debería ir la imagen hay negro. El fichero 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 como está grabado prácticamente todo lo que sale de un móvil, de una cámara de acción o de una réflex. Y tampoco entiende el audio en AAC, que acompaña a esos mismos ficheros.
Lo llamativo es que el mismo programa, gratis, en Windows y en Mac sí los abre. No es 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 ver 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 gorda, 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.
O sea que la versión de pago te resuelve la imagen y te deja el sonido a medias.
2. La distribución: oficialmente, casi ninguna
Blackmagic da soporte oficial a 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 está la inmensa mayoría de la gente.
Lo que te dan es un instalador .run pensado para un entorno concreto de estudio de postproducción. Fuera de ese entorno funciona, pero te toca a ti resolver las dependencias, y ahí es donde aparecen los cuelgues al arrancar y los errores de bibliotecas que no cuadran.
3. La instalación: manual y frágil
Consecuencia de lo anterior. En Ubuntu hay que pelearse con paquetes que el instalador espera y no encuentra; en Arch se tira de un paquete de la comunidad; en Fedora, otro tanto. Ninguna de esas rutas es oficial, y cada 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, está en un despacho de abogados.
H.264, H.265 y AAC están cubiertos por patentes. Para distribuir un programa que los descodifique hay que pagar licencia a los consorcios que las gestionan, y se paga por copia distribuida. En un producto que regalas a millones de personas, esa cuenta se dispara.
Entonces, ¿por qué sí funcionan en Windows y en Mac? Porque ahí Blackmagic no pone los códecs: los pone el sistema operativo. Microsoft y Apple ya han pagado esas licencias y las ofrecen a los programas que se ejecutan encima. Resolve se limita a pedirle al sistema que le descodifique el fichero.
En Linux no existe ese señor que ya ha pagado. No hay un códec del sistema con licencia al que llamar, así que la factura le caería entera a Blackmagic. Y por un producto gratuito, no la paga.
Y el otro motivo, el que nadie dice
Al margen de las patentes, hay una razón de negocio: el Resolve de Linux no está pensado para ti. Está pensado para estudios de postproducción con hardware certificado, que compran Studio, tarjetas de captura Blackmagic y paneles de color, y que montan la estación entera con la distribución que les diga el fabricante.
Para ese cliente, «solo Rocky Linux» no es una limitación, es una ventaja: un único entorno que soportar. El problema es que el resto del mundo también quiere usarlo, y ahí Blackmagic no ha movido un dedo.
Qué puedes hacer hoy
Mientras Blackmagic decide, hay cuatro salidas. Van de la más aburrida a la más elegante.
1. Transcodificar antes de editar
Es la solución de toda la vida y la que funciona siempre: conviertes el material a un formato que Resolve sí entienda antes de meterlo en la línea de tiempo. DNxHR y ProRes son los habituales.
ffmpeg -i entrada.mp4 -c:v dnxhd -profile:v dnxhr_hq -c:a pcm_s16le salida.mov
Y para una carpeta entera, con 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
Funciona, pero tiene dos peajes que conviene saber: 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. Para un vídeo largo grabado en varios días, es un fastidio considerable.
-c:a pcm_s16le no está de adorno: convierte el audio AAC a PCM sin comprimir. Si no lo pones, arrastras el problema del sonido al fichero nuevo.2. Pagar la versión Studio
Unos 300 euros de pago único. Te resuelve H.264 y H.265, pero no el AAC, así que en muchos casos vas a seguir 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 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 lo que ffmpeg sepa abrir, que es todo.
Lo importante de este enfoque: el códec lo pone el usuario, no Blackmagic. La patente deja de ser problema de la empresa, y el mecanismo es oficial, no un parche.
4. El Flatpak de la comunidad
Existen ya intentos de empaquetar Resolve como Flatpak —el más conocido es resolve-flatpak—, y son la demostración de que la idea funciona: el Flatpak se lleva por delante el problema de la distribución, porque el paquete trae sus propias bibliotecas y le da igual si estás en Ubuntu, en Fedora o en Arch. Además, ese 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)
Juntando las piezas del capítulo anterior, 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. Deja de importar si el usuario está en Ubuntu, en Fedora, en Arch o en Mint, y deja de importar qué versión tenga de cada dependencia. Blackmagic pasaría de mantener «soporte para Rocky Linux 8.6» a mantener un paquete que funciona en todas partes, que además es menos trabajo, no más.
Con eso desaparecen 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 justo eso—, y la instala el usuario, no el fabricante.
Blackmagic distribuiría un Resolve sin códecs propietarios, exactamente igual que hace ahora, y quien lo necesite añadiría la extensión con 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.
Sumado al IOPlugin de ffmpeg, que ya existe y es un mecanismo oficial de Resolve, el problema de los códecs pasa de «imposible por patentes» a «un paquete opcional».
Lo que de verdad lo está bloqueando: un formulario
Y aquí viene 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.
O sea que no existe una URL directa y estable desde la que un empaquetador pueda bajar el instalador. Todo el asunto se cae por ahí.
Lo que Flatpak no arregla
Para no vender humo, 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 es un impedimento: son trabajo de empaquetado, y es el trabajo que la comunidad ya ha hecho gratis para demostrar que se puede.
Fuentes
