How well is your project running on the system when you aren't trying to record? Do you have access to an external capture card on another system?

Also, do you specifically want 'live' interaction game play? Or would you be happy with a render of a pre-defined scripted interaction?

I can't offer any super solid suggestions that are specific to Unity as I only have a rather narrow bit of experience with it, but I can say that I've gotten nice results out of cheating a game play render in other projects, but it required a decent chunk of work to setup. (It also ate a mountain of drive space...)

We used modified versions of the game to allow command capture and modification, and then a play-back version that read from the detailed script. Basically it generated full res screenshots and dumped them in a folder with incremental file names, which were then imported into Adobe Premier, effectively creating a time lapse video. We could configure all the settings for where units were, what stats they were, AI states, etc, then either capture the user input or write it completely from scratch, then play it back in with various settings like live rendering, slow-mo, or screenshot mode.

This fake-playback-method of rendering was chosen early on in the projects, and was mostly aimed at being able to display clearly defined and targeted 'dramatic' events per specification, rather than trying to record random gameplay and then edit material down into something interesting. We wanted to be able to say "Well, all these things can happen in the game, so we'll start with this 'scene', then show off 'this effect', then this, then that other cool thing..." etc, and start the clip editing process with exactly what we were aiming at, rather than going in with "Well, there is an hour or two of recorded game footage, lets sift through and find the dozen clips or so that are usable..."

(Audio syncing was kind of interesting, given that audio and visual frames were generated in different passes and merged after the fact.)

- Being able to push steady frame rates with higher resolution rendering early on in the projects while performance kinks were still being ironed out was a handy bonus. Pre-programmed frame-by-frame script stepping also ended up being useful for some debugging purposes as well, so all in all it was an interesting tool.

It is however, probably not the best option for a lot of projects if they're already well underway. External capture card and live gameplay is a far saner option if the program isn't already in a state that is easy to reconfigure for such a purpose. - Maybe check out gaming LAN centres in your area if you need more hardware access? Libraries are also a potential for the capture hardware. May be a long shot, but the equipment and resources on hand at many libraries can be surprising.

So when I'm not recording the video, it's overall pretty good quality. What I'm trying to record is completely pre-scripted. This is me showing off art assets tbh.

I played around with the encoder settings and that does seem to improve results somewhat. It's not nearly as choppy/blurry with some tuned settings.

How does external capture card/live gameplay work? I have access to university resources that could maybe help out with setting up some of this stuff. We have like a graphics lab here.

I'm overlaying audio on top of the recorded video, so I'm not super worried about that I guess hahaha.

External capture is just an external device that takes a display cable as an input, and records what is passed to it. They can be a splitter/relay setup such that you take the cable that normally goes to the monitor and plug it into the capture input, then another cable from the capture device to the monitor. Others expect you to be able to have two outputs on the computer, and just configure them to mirror each other.

Either way you just start recording on the external capture device, and play the game normally while your screen is then captured and recorded without any further input or resource usage of the main system.

If you have access to that kind of hardware, then I would strongly encourage trying that route over the round about screenshot-time-lapse idea, (Unless your code is already looking like it would be easy to rework for it and you want the debugging step through. Just remember that anything to do with delta-time needs a weird overhaul. Speaking from experience not enabling the revamped delta time handling does result in some hilarious animations.)