Skip to content

Diff detection

Jump to bottom
Caleb Trevatt edited this page Jan 12, 2023 · 2 revisions

12-01-2023 (Initial notes on diffing)

Pitch:

Imagine Git diffing for DaVinci Resolve renders...

Patchwork diffs your old renders with your current timeline and only re-renders changes you've made. Even with inter-frame compression codecs like h.264.

This was on the repo's README for a while. Truth is, this is really hard. It makes more sense to implement the patching logic with manually marked changes first, and once it's going steady, implementing the difficult diffing logic. Here's a few of my earlier ideas. Hopefully they leave some inspiration to come back to.

Timeline diffing

In order to patch our first deliverable, we need the deliverable rendered in full, along with a sidecar file that defines the settings that produced that deliverable. I.e. a timeline file. We can get this with every deliverable export by using a pre-encode script hook.

Fcpxml

.fcpxml is the best supported editorial format, easiest to parse, and retains a decent amount of timeline information. Unfortunately, it can't retain everything. Colour page data, OFX plugins, third-party plugins, fairlight data, fusion data, none of that is supported.

Davinci resolve timeline file

.drt files should contain everything necessary to reproduce a project in a different database. Unfortunately we can't simply hash exported .drt files because they have unique IDs in them that change for reasons that are difficult to discern. It's hard to tell this early on, but some values seem to change when:

  • machine is rebooted: session ids? OS provided drive mount-point ids?
  • UI is altered: panels resized, control focus switched, etc
  • new/updated/deleted render presets, project settings, etc, (no matter how relevant to open project)

Additional downsides:

  • .drt files are zipped - unnecessary waste of CPU and time to zip/unzip
  • .drt directory structure mirrors project structure in Resolve - must parse folder structure to determine "diff-worthy" keys (new/updated/deleted).

Query database

Reading the timeline data straight from the PostgreSQL database could be a decent option. ETL with Postgres should be easy. No complex parsing required. This way we get all the data we need to diff accurately. HOWEVER, we may run into similar "signal-to-noise ratio" issues as .drt parsing. Data structure also changes with each major release of Resolve. Meaning we need to supporting parsing multiple different versions of the database schema at once. This may also be true for .drt files.

An additional downside here is that not everyone uses PostgreSQL to host their Resolve database. Some use DiskDB or Blackmagic cloud.

Clone this wiki locally