Does this introduce lag while editing?

What about for encoding? For example if you want to export a video from Resolve in its final form with AAC audio. The readme mentions decoding but not encoding.

And to bring up a likely reason: my impression is that H.264 and AAC still have active patents that apply to the major implementations, and those are not licensed gratis for all uses, and that applies more heavily to the encoding side. Raspberry Pi used to (and might still, I don't know) offer add-on license keys to unlock certain video codec support for what I assume was a similar reason. A lot of individual Linux desktop users just do their small-scale FFmpeg runs under the radar, but commercial software delivery is different.

With proprietary operating systems, the commercial entity behind the OS can negotiate for licensing. Some commercially-associated Linux distributions have efforts in similar directions, like Fedora for instance has some special secondary-repo stuff around H.264 support, but that's at minimum much more fragmentary as a target for an application developer concerned with the legalities.

Yep, but AAC is not, so you're still stuck needing to encode multiple times. This adds delay and also massive disk churn.

The problem with AV1 is it requires a massive amount of compute resources. This affects both recording (encoding) and playback (decoding) and certainly affects editing. My AMD RX 480 (8 GB) card doesn't even support AV1 encoding too.

Being able to edit without lag is really important, also keeping your CPU load reasonably low when recording is important to avoid dropped frames, or your recording streams becoming out of sync (ie. a webcam video with audio recorded from another input device while you record your desktop).

I noticed on Linux, if I do anything CPU or disk intensive while recording (even with an SSD), I often see these things get out of sync at the point of load. It's an easy fix usually by just cutting the video where it starts to get out of sync and shifting the audio track over ~200-300ms, but it's something that could happen many times so it becomes an issue in the end. I recorded thousands of videos on Windows and never had this problem but it happens every few videos on Linux just doing casual screenshare videos.

AAC vs Opus is similar, except audio related.

In general when recording videos I usually use x264 as mkv which is CPU bound because it produces a much better looking video vs using h264. That's using a bit rate and other settings that tries to balance quality with low disk space.

So? File size matters for delivery formats. But not for intermediate formats straight out of camera. For editing, bitrate and decode performance are often way more important.

Hardware decode support for AV1 and H265 is still pretty bad. If you use those formats, a lot of computers will stutter when you move the play head around while editing. On my mirrorless cameras, I much prefer filming in medium to high bitrate h264. I fill up my storage cards faster, but my camera batteries last longer recording like that and the footage is much easier to work with. I have a 4090, which supports h265 decode. But it only works for 4:2:0 footage. If I film in h265 422, my computer falls back to a software decoder. It's easier to just use h264, then I don't have to think about it.

If you want to ship high quality deliverables, you don't want resolve to do the final encode anyway. Resolve tries to use NVENC for encode, which is a much worse encoder than x264 and friends in ffmpeg. From resolve, output prores or something. Then use ffmpeg to do the final encode. I think there might also be ffmpeg encoding plugins.

tldr; Codec matters, but there's a lot more nuance to getting a good image than just picking the newest video codecs.