H.265 Davinci Resolve
Frederic Laureano
Just finished editing my latest video and it was plain painful. Partly my fault, with the replacement drone I forgot to change video setting so I recorded everything in h.264 instead of h.265. Just zooming the timeline gets the CPU to 100%.
But even with h.265 footage I hit some issues. Most can be resolved by reducing the playback resolution and things like that, and starting to play with fusion has me hitting a brick wall and videos that I have tried that include anything other than the absolute basics wont render.
I am using he free version. From some research I have done today I believe that in the free version that the GPU is not used for h.264 but that is not the case for h.265 which would tally up with my limited experience so far.
I have an old laptop (6 years) with 32gb ram. I find that if I generate proxy media (takes about an hour for 3-4 mov files) then then when I drag the sliders there is no lag. Without proxy media it lags.
if you are running an i5-6600 the best you can hope for is probably the i7-7700k, while they use the same 1151 socket, i believe the 9900k would require a new motherboard because your current chipset would not support the 9900k.
like the previous post says, your 1050ti is a very budget friendly option, unfortunately the sky is the limit when it comes to pc parts, the more you pay the more you get. you can pick up a decent rtx 3060 new for around 275 or used for 175 which according to user benchmark is about 225% faster than your 1050ti.
Firstly though, regarding your 265 footage - are you creating optimised media which should make it nice and easy to use even on your setup.
In addition, set the timeline to a lower resolution, do all your edits there, there just bump it back up to your desired output pre-render.
To run DaVinci Resolve, it is required to use suitable OpenGL and OpenCL drivers. Open-source OpenCL drivers are currently unsupported, with the exception of intel-compute-runtime as of 25/08/2023 (check this issue. for instructions, you'll have to compile mesa and compute-runtime yourself, and export some envvars).
You can run davinci-resolve-checker script, which will tell you if your configuration is suitable for running DR (doesn't work for Intel iGPUs - says OpenCL driver is unsupported, though you can make it work). In good configurations it should output:
Compression of the Davinci Resolve package takes a significant amount of time because the binary is quite large. You can instruct makepkg to use a different compression algorithm, which in this case disables compression altogether, speeding up the process tremendously.
There may be reasons you may want to not install davinci resolve package to the system. For example, you do not want such big package to take space in system partition. Or you want to quickly switch between different versions of application: free and studio, current and previous versions. To do this, just unpack the contents of the needed versions package in the directory you want, and directly run the opt/resolve/bin/resolve from that directory.
DR supports scripting. Free version support launching the scripts only from within dr itself, while with Studio version you can also invoke scripts externally. To allow it, go to Preferences -> System -> General -> External scripting using. You can choose: None (similarly to Free version, only from within dr), Local (allow invokes from local host), and Network (allow invokes from remote host).
Another workaround (working in X11 (and Xwayland), is worse and sometimes skips events) of this problem, you can use IMWheel utility. It can remap modifiers only for the application described by regular expression.
When you exit application, the terminal prompt is returned to you, but suddenly the terminal is polluted with "Socket disconnected" message. To prevent this, pipe output of main process via cat. See here for explanation.
It's a misconception that DaVinci Resolve free does not support the MP4 container type. It is more accurate to say DaVinci Resolve free does not support decoding or encoding H.264 and H.265 video, regardless of the container type.
You can automate this task using incron. It will automatically convert files appeared in specified folder. See setup example on this article. Another alternative is to write a resolve script for that purpose. See documentation for Resolve Scripting (linked in the see also section) for more information.
Both H.264 and H.265 video is supported by Studio, but AAC audio is not. You can transcode the audio from the unsupported AAC format, into a supported lossless format without destructively re-compressing the video, or separating the audio from the video.
Some plugins are available for Windows, but not available for Linux, so you may want to use Davinci Resolve via wine. Also, wine version could potentially workaround the linux-only problem of mp4 format issues. Wine 6.5 brings OpenCL 1.2 support, which is required for DR. Unfortunately, there was no success to start DR via wine.See test results here. In 17.4.1 DR cannot see the list of available gpus (wine 6.21). Probably, need some hack to make wine present gpus to applications. In dr 18.5b1 with wine 8.7-1 I get the rocm error (5.4.3-1) that is filed here.
If the application simply is not starting, even after showing installer and "tour" successfully your OpenCL Version may not match your NVIDIA driver. If you have installed nvidia-440xx make sure to install opencl-nvidia-440xx as well.A possible error message:
If you are experimenting with driver installation, you may want to start from the welcome tour and onboarding screen, which checks your system and graphics card. You can achieve that by removing configs directory:
DaVinci interfaces the ALSA directly, so if you use pulseaudio you need to install pulseaudio-alsa or pipewire-alsa. Alternatively you can redirect it to use PulseAudio yourself by creating asound.conf in /etc/ with the following content:
In DR Studio for Windows and Mac OS there is Workspace -> Workflow Integrations menu. Workflow Integration plugins are written in JavaScript (electron applications). As noted in documentation (you can reach it in Help -> Documentation -> Developer), Linux currently is not supported (checked in 17.4.3). They say Integration Scripts are supported in Linux, this is most probably a mistake, because they did not provided a path where to put them and still the menu is missing (it is that same Workspace -> Workflow Integrations).
If dr hanged, fails to release a terminal when you press ctrl + c (to send sigint), and when its window is not shown and you cannot open dr again (it is saying another instance is already running), you can still fix it. Open task manager (ctrl + esc in KDE), then search for process named "GUI", then kill it (send signal 9). Now you can start dr normally.
Another workaround is to remove a few libs from Resolve's directory. This way Resolve will be forced to use system libs, not the ones packaged with it. See also the AUR comments for the packages and the PKGBUILD itself for more information on this trick.