Hacker News Reader

I use this project to run Resolve Free/Studio on Linux: https://github.com/fat-tire/resolve

It helps you build and run Resolve in a Docker or Podman container. I’ve personally used it on Ubuntu, Debian, and Arch-based setups (well, CachyOS), and it’s worked great for me.

Right now it supports Nvidia very well. I’m also personally working on adapting it for AMD GPUs so I can run Resolve on my Strix Halo workstation.

One especially nice thing about this setup is that I can run multiple versions of Resolve on the same computer. If a new beta comes out, no problem — I can build a new container and try it out while keeping my stable version as my daily workhorse.

I recently used Resolve (just the free version) for a project. It was my first time seriously using the software but I ended up spending a lot of time with it - lots of timeline editing, keyframe animation, some simple Fusion compositions, and a fair bit of work in the Fairlight page, rendering out daily . I did all this on my beloved Arch Linux workstation, and frankly it was rock solid, apart from exactly one crash when using the timeline keyframe editor - something that was solved by upgrading Resolve to the latest version.

I was really impressed by how well it worked for me on Linux.

I think these things might have helped:

- I use an X11 desktop (Cinnamon), not Wayland. I've tried it out on a GNOME Wayland desktop but it seemed quite a bit more clunky and froze frequently.

- PipeWire runs the system's audio routing, so Resolve just appears as another ALSA client, and I can then use wiremix to send to my preferred speakers or headphones. (I haven't tried any audio input yet)

- I didn't try to install Resolve natively, I used davincibox [1] to install and update it within a container (it uses distrobox, which then uses podman).

I'll now be purchasing the studio version, which hopefully will work as well.

[1] https://github.com/zelikos/davincibox

You encouraged me to try again and somehow, blackmagically ;) it works this time. It may be that recent DaVinci version has made some improvement. I'm so happy!

Installation still requires workarounds and codecs support is limited, but having that aknowledged and accepted, the application is finally usable!

PS. I don't know where the h264 (and other codes?) limitation come from, since ffmpeg has full support of it. Or is it just business model? Weird.

For those seeking quick solution for missing codecs, here are bash scripts that use ffmpeg to convert any input clips (including these problematic h.265/h.264) to format acceptable for DaVinci

  #!/usr/bin/env bash
  
  set -euo pipefail
  
  INPUT_DIR="${1:-}"
  TARGET_FPS="${2:-30}"
  
  if [[ -z "$INPUT_DIR" ]]; then
      echo "Usage: $0 <directory with clips> [target fps (defaults to 30)]"
      exit 1
  fi
  
  if [[ ! -d "$INPUT_DIR" ]]; then
      echo "Error: directory does not exist: $INPUT_DIR"
      exit 1
  fi
  
  OUTPUT_DIR="$INPUT_DIR/conv"
  mkdir -p "$OUTPUT_DIR"
    
  EXTENSIONS=(
      mp4 avi wmv mpg mpeg mov
      mkv m4v flv webm ts mts m2ts 3gp
  )
  
  shopt -s nullglob nocaseglob
  
  for ext in "${EXTENSIONS[@]}"; do
      for file in "$INPUT_DIR"/*."$ext"; do
          filename="$(basename "$file")"
          name="${filename%.*}"
  
          output="$OUTPUT_DIR/${name}.mov"
  
          echo "Konwersja: $file -> $output"
  
          ffmpeg -y -i "$file" \
              -map 0:v:0 -map "0:a?" \
              -vf "fps=${TARGET_FPS}" \
              -vsync cfr \
              -c:v prores_ks -profile:v 1 \
              -pix_fmt yuv422p \
              -c:a pcm_s16le -ar 48000 \
              "$output"
      done
  done
  
  echo "Results in: $OUTPUT_DIR"

and then converting final exported video to h.265:

  #!/usr/bin/env bash
  set -euo pipefail
  
  INPUT="${1:-}"
  CRF="${2:-21}"
  PRESET="${3:-slow}"
  
  if [[ -z "$INPUT" ]]; then
      echo "Usage: $0 <input file> [crf=21] [preset=slow]"
      exit 1
  fi
  
  if [[ ! -f "$INPUT" ]]; then
      echo "Error: file does not exist: $INPUT"
      exit 1
  fi
  
  DIR="$(dirname "$INPUT")"
  FILE="$(basename "$INPUT")"
  NAME="${FILE%.*}"
  
  OUTPUT="$DIR/${NAME}_h265.mp4"
  
  ffmpeg -y -i "$INPUT" \
    -map 0:v:0 -map '0:a?' \
    -c:v libx265 \
    -preset "$PRESET" \
    -crf "$CRF" \
    -pix_fmt yuv420p \
    -tag:v hvc1 \
    -c:a aac \
    -b:a 192k \
    -movflags +faststart \
    "$OUTPUT"
  
  echo "Ready: $OUTPUT"

Great to hear!

I would guess the codec limitation might come from licensing requirements, as BMD would need to pay for h264/h265 licenses for Linux, and that can't really be sustainable for a free product. MacOS and Windows already come with licensed system codecs.

My project had ProRes source media, so there was no codec issue and everything worked very smoothly. I exported ProRes and used ffmpeg to transcode to whatever I needed.

I don't think I would have bothered trying to run Resolve on Linux were it not for finding that davincibox script. It was incredibly straightforward to install, and now I just start it by clicking on an icon like a regular application.

Have fun!

I use Resolve (paid) all the time on Arch with Gnome+Mutter+Wayland, works completely alright for me, except when it comes to anything generating 3D in Fusion, for some reason. Mostly use it for quick cutting and also audio mastering.

Got my license when I bought a second hand Blackmagic camera, must have been 5-6 major Resolve versions ago, and it still works as a charm! They're a rare star among a sea of trash in the software and (arguably bit less trash) hardware world.

As per my comment here: https://news.ycombinator.com/item?id=47765893

I run Resolve under CachyOS using the project I mentioned -- everything works afaict.

> It helps you build and run Resolve in a Docker or Podman container

Why though? I run it perfectly fine on Arch as-is, what problem does containers solve here? Install it to different paths and you have different versions working too.

How are you installing Resolve in Arch? I have not actually tried installing directly (in Arch at least). What problems are you having in the Fusion page too?

The AUR has Davinci Resolve and appears to be maintained. (Untested) [0].

[0] - https://aur.archlinux.org/packages/davinci-resolve

Resolve is only officially supported on Rocky Linux which is a rebuild of Red Hat Enterprise Linux. Red Hat, Debian, and Arch based distributions do things a lot differently than each other. Rocky/RHEL are pretty much de facto standards for Linux in the high-end video production and VFX market so it doesn't make much sense for Blackmagic to spend development resources supporting other Linux distributions.

I've been editing on linux with resolve since the launch of the BMPCC4K in 2018, were you trying to import MP4 footage? BMD can't be bothered to pay for the AAC audio codec for linux users even if they buy studio. So if you pay for studio you can read the h264 video stream but not the AAC audio. I end up converting everything to MOVs with pcm_le16 audio as a workaround.

The ALSA issues are beyond aggravating at this point. You do not want to actually run ALSA directly, you need it to connect to pulseaudio on 24.04. But I still have never been able to record audio within resolve. I've had mixed luck on newer wayland+pipewire setups with having to install the bridge packages to connect the different backends. Linux audio is cursed on its own so I don't fully blame BMD.

I exclusively run Kubuntu and have been using makeresolvedeb[1] for installing resolve and it has been pretty good.

[1] https://www.danieltufvesson.com/makeresolvedeb

Autodesk have been the same with Maya on Linux. The 2027 version has just been released, and it still doesn't have full Wayland support. The VFX Reference platform doesn't mandate Wayland support. And strangely enough, Maya versions prior to 2025 work perfectly fine on Wayland (they migrated to Qt 6 with 2025)

Yeah, sucks that VFX Reference can't just ensure broader Wayland support, would be amazing, but they/it tend to be very conservative, for good reasons too.

To be fair, most studios seems to still be using CentOS 7 and Rocky 8, latest Ubuntu version tend to be 20.xx, all of them relatively old from like 2020s sometime.

Yeah and even Unreal Engine 5 has RHEL/Rocky 8 as the minimum supported OS. With the Py 2->3.x and Qt 6 migrations now in the past, things are thankfully/mercifully stable and boring across Game/VFX pipelines, and will be for years to come. We've got things pretty good. That loss of flexibility with RHEL/Rocky 10 being the latest release and no X11 is real a pain for new pipelines/productions starting up, but yeah, not many projects are getting started in the Game/VFX industry these days...

Wonder what really stops them to have an agent dig for a night, and have this compatibility in place. Even if it means them say - this is very unstable, use with caution.

> Even if it means them say - this is very unstable, use with caution.

AFAIK, the entire point of that reference platform is that nothing is "very unstable" or even "unstable" but instead a stable target to develop against. I'm guessing adding something like that would defeat the purpose somehow, and risk getting studios vary enough to make it not worth it.

SideFX have some compatibility flexibility around this with Houdini but they're the exception. Autodesk have very tight annual release schedules for Maya (and other DCC), where the actual feature development only has months allocated (and several months for beta). They rarely skip years too with 2020 being the last one.

Exactly my thought. On Windows I used the free version for casual video editing and making memes. On Linux it just doesn't work. I managed to somehow fix the audio problem, then it had issues with codecs, and in general it was very miserable experience.

I wonder if https://github.com/zelikos/davincibox would make it easier and more stable, I haven't tried it myself yet.

I've used davincibox and found it to work great

I'm not sure how much this will help you, but it should work for Linux Mint, which is based on Ubuntu, so it probably works for Ubuntu as well https://www.virtualcuriosities.com/articles/1784/how-to-inst...

I got it working with the help of Gemini, here's my chat if you want to try again <https://gemini.google.com/share/50fa089e2f2c>

Thanks, but as far as I read it, it's all about the library file names mismatch, which is mostly covered by guides I mentioned earlier. I've done that and I got my DaVinci running. It was just audio output that did not work, despite hours spent on trying to get it work.