A collaborative editing workflow in Resolve

Overview

Before DaVinci Resolve expanded into audio (Fairlight), VFX (Fusion), or even editing, the software was intended purely for high end color correction. Because they were targeting use at highly-networked color grading facilities, it was always built around a database model with multiple simultaneous or nearly simultaneous users in mind. This would allow a colorist to be “in session” in one room with a client, while a color assist could prep, do renders, or even do color cleanup in another room on the same project, if they were pulling from the same shared media.

While the setup was originally a bit complicated for the average user, with the release of Resolve 14 in 2017, Blackmagic started to take shared-user workflows more seriously, with a host of new tools that allow for very sophisticated collaborations, and with a toolset to make even the initial setup easy for post professionals who might not necessarily be computer engineers, but who can walk through a bit of IP network setup.

Resolve comes at two price points: the free software, which is actually incredibly powerful, then “studio,” which costs $299 and has a few upgrades that generally make the price well worth it. On top of noise correction and some other plugins, one of the big benefits of Studio is that it enables shared user features, and will be required for setting up a shared resolve environment.

The whole concept of sharing in Resolve is built around a central database, which is something that sometimes confuses new users to resolve since all your resolve projects are stored in a database of some form.

Working with a Database

Most post production applications work with a project file that is independent of the program and can be moved from machine to machine relatively easily. With the .avp and .avb formats from Media Composer, or .fcp projects from Final Cut 7 and Premiere Pros .prproj, the concept of a “project” is something most posties have a handle on.

Resolve does have a project file, the .drp (Da Vinci Resolve Project), but it’s only used as a method of backing up your work and moving it to a new machine. If you double click a .prproj file, it’ll launch premiere and keep working from and saving to that project file. If you double click a .drp, it will launch Resolve and load that project, but it loads it into your Resolves database and works from and saves it there. It doesn’t keep updating that .drp file.

Resolve keeps all of its files in a database to make it easier to share. If you set up a shared database correctly, all users on the system can log in to the database and open the same project at the same time. Since the database server is a sophisticated tool that allows for reconciling multiple versions of the project in a powerful way, this allows for a number of powerful collaboration tools that don’t show up in other systems that rely on read-only modes to enable opening the same file at the same time.

Resolve can actually deal with two sorts of databases:a disk database stored on the user’s local machine and a SQL database, which can either be “served” from your local machine or from a machine on the network you are attached to. The default behavior is a disk database, and that’s how the vast majority of users who work with Resolve and learned it in the last few years are used to working. But if you open up the tab to the left of the projects in your database, you’ll see it’s possible to attach to a “PostgreSQL” database, which is necessary for a shared workflow.

Setup

Blackmagic have actually made it easier than before to create a shared database with the new “Da Vinci Resolve Project Server” application. Whereas before it required entering the terminal, which can potentially make some users nervous, with the app you can set up a shared database quite quickly.

However, before launching the database, you need to make sure that your hardware is se tup correctly. First, you need a machine dedicated to “serving” the database, ideally a machine that can be always on on your network that will run PostgreSQL and share the database with other users on the network that need it.

On top of that, you need to be able to assign a fixed IP address to that machine, so that other computers can find it. Generally, most smaller networks assign IP addresses dynamically: every time a new machine logs into the network, via ethernet or wifi, an IP address is randomly assigned to it. For shared databases to work, you want to assign a static IP address to the machine serving the database, and ideally to the machines that will be looking for it. This allows the connection to stay in place even if a machine or the network is restarted. While assigning static IPs is a bit beyond this guide as it’s different for every router type, it should be easy to find information on how to do it on your network.

Once you’ve fixed the IP addresses, you can launch Da Vinci Resolve Project Server, which comes with Resolve Studio. This application has only one function: creating a shared user database. You’ll want to launch it on the machine you are using to “share” your database, but that machine doesn’t need to continue running Resolve or in fact keep any application “open.” The database server software runs in the background.

From that application, you can both create a new SQL database, you can also enable sharing and, importantly, create a database password. This is a powerful tool, since many facilities need to worry extensively about who has access to what. Let’s say you are working on promo material for both the new DC movie and the new Marvel movie, as you might in a trailer or advertising company. Both clients will want to be sure that only the creatives assigned to the team have access to the projects. Thus you might create a dedicated “DC” server and a dedicated “Marvel” server to keep the projects completely separate, and only distribute passwords to the right team members.

Back at your workstation, you then would click “Add Database” under the database list, and log in to the database server using the IP address of the database server hardware. This is why static IP addresses are vital, since your workstation will be using the IP address to look for the shared database.

Shared Storage

Like most shared workflow solutions, Resolve works best when working off of a shared media storage solution, such as a server. That way, every single user is looking for media at the same place.

Many users, when setting up their shared resolve database, are initially inclined to focus on setting up the fastest possible shared database server, but in reality sharing the database is nowhere near as intense as sharing the media between multiple machines. In fact, it is not uncommon to see an older server, or even a Mac Mini, set up to serve the database, since, while some CPU power is important, as is maxed-out RAM, the server doesn’t really need to be a powerhouse, especially in GPU power.

Your shared storage, however, should be ready to play out media with enough speed to handle as many users as will be working on the project, and that is where some investment is worth it. Some systems, such as the Jellyfish by LumaForge, even come with a shared Resolve server built in. However, if your shared media server isn’t ready to play easily with a shared Resolve database, a used Mac Mini will do just fine.

Read-Only Mode and Locking

Once you have your media on a shared media server, and two or more workstations logged into the shared database server, it’s time to start experiencing the power of multiple users on the same project at once. One of the important concepts to understand that enables the system to function is “read only” or “locked” versus available resources. While Resolve doesn’t “lock” entire projects as other applications might, it does “lock” certain sections within a project when it’s being used by a given user.

To turn on project sharing, you right click on the project in the projects window and enable project sharing. That allows multiple people to log in to the same project at the same time. If another user logs in to the same database, they should see the project there with a little symbol indicating it is available for multi user work.

Editing and Timeline Compare

It is within the project that this becomes more complicated. Resolve doesn’t let two people actively edit the same timeline at the same time. When the first user logs in, they take control of the timeline, and other users can only view that timeline in a read-only mode that allows full viewing, but no changes.

For most workflows, this is a very useable solution. For instance, a lead editor can be busy working away on a timeline, and the assistant can come in check on progress, or to confirm for VFX that yes, actually, a certain shot has been cut. You can copy from that locked timeline into other timelines, or most powerfully, you can also create a new version of that timeline to work with. At the end of a session, the owner of the timeline can then go through an “integration” step to compare changes from both timelines and “commit” the changes from the second user to the master timeline.

Resolve has built a powerful view that shows the changes in the timelines graphically, as well as a list view, making it easy and fast to commit or reject changes that a second editor might have been experimenting with in the timeline.

Multiple Colorists on the Timeline at once

While navigating multiple editing timelines is relatively easy, navigating and then merging multiple color sessions would be much more complicated. For instance, when color grading a shot, there are literally hundreds of things you can do to manipulate it; creating a merge session window if two colorists were working on the same timeline would create a list thousands of items long by the end of a day.

Resolve solve this problem by not color locking at the timeline level but at the shot level. When working in a multi user project, when the colorist is working on a shot, only that individual shot is locked, but the shots around it are not. Another user won’t be able to work on the same shot at the same time, but the shot before or the shot after is of course fair game.

This is a powerful tool but also a dangerous one. Of course, colorists are in the habit of doing a final watch down (or three) to ensure that all grades are what they want them to be, but this multi user workflow does allow for a colorist to be working on shot 10 while another colorist makes tweaks to shot 3 that the lead colorist might not notice. Shared workflow coloring requires a highly trained team who are used to working together and have developed clear protocols for who is doing what within a project.

Realtime Chat

One of the nicest features that Resolve has added to help users communicate who is doing what is a realtime chat window built within the interface. When multiple users are logged in, the chat icon appears in the lower right, and allows for chatting to occur with any other user currently in the project.

While, yes, many chat applications exist, if you are in a room with a client, you never want to leave your primary software. Having the ability to chat within Resolve, rather than switch over to gmail and explain “oh, we use gchat, I’m not checking my personal email” is a huge benefit to users.

This allows a colorists to ping an assistant “hey, I’m having trouble tracking shot 8 but want to move on with client, can you clean up the roto by hand?” and keep moving on creative work with a client without worrying about drawing the absolutely perfect shape. Or an assistant editor can ping the lead editor “hey, done with the stringouts on that line if you want to look at options.” By default, it comes up with your computer name, but you can of course change it to whatever else you might like.