Table of Contents Show
For those who don’t know the tool: Blackmagic Design spans acquisition, live production and postproduction, with DaVinci Resolve combining editing, Fusion VFX and motion graphics, Fairlight audio and colour finishing. The two updates here sit at opposite ends of that chain: Resolve’s scripting API gives pipeline tools more context inside editorial and delivery, while Blackmagic Cinema Camera 6K gains pre-record at acquisition, before the resulting media enters editorial, VFX, grading and mastering.
Blackmagic documents API scripting support for reviewing selected timeline clips in Resolve 21.0.4, but the more revealing production tests come from colourist and finishing supervisor Poul Waligora. His hands-on examination of the Resolve 21.0.4 scripting API tests the calls directly in Resolve’s Console and exposes several behaviours that the documentation does not spell out. His broader DaVinci Resolve Python scripting guide provides useful context for how Resolve’s scripting objects fit together. We’ll refrence him here, because he is clearly smarter then us.
The headline version of this update is simple: scripts can now obtain the current timeline selection, obtain a Timeline object from a Media Pool timeline entry and configure additional render settings. The production version is less tidy.
Selection means selection
The most important new call is Timeline.GetSelectedClips(). It gives scripts access to the timeline items currently selected by the operator. For pipeline developers, that closes a important gap. Scripts could already inspect timeline contents, but building a tool around “the clips the editor has selected right now” required workarounds. A tool might operate on the whole timeline, use markers or clip colours as an improvised selection mechanism, or ask the user to identify the same clips again somewhere else.
The new call lets the Resolve interface remain the selection interface. An editor or finishing artist highlights the relevant items and the script receives those objects as its input. That is useful for VFX pulls, metadata operations, QC helpers, review exports and other tools where human judgement identifies the shots while automation handles the repetitive work afterwards. The artist still decides what matters. The script no longer has to guess.
It is important to keep the scope precise. This is API access to the existing selection state. Blackmagic has not announced a new timeline-selection algorithm or a complete programmable selection system. That sounds like pipeline plumbing because it is pipeline plumbing. Good plumbing is generally most interesting just after you discover how long you have been carrying buckets.
Three clips can become fifteen
The returned selection also needs filtering. In the hands-on test, selecting three video clips returned 15 timeline items because each video item had four linked audio items. The exact number obviously depends on the timeline, but the consequence is : a script should not assume that a visually selected set of three shots will produce three objects.
A production tool needs to inspect the returned timeline items and filter for the track types it intends to process. Otherwise an operation intended for three video clips can quietly expand across linked audio. That becomes particularly important once the script starts creating render jobs, modifying metadata or performing other operations with persistent consequences. Selection access saves interaction, but it does not remove the need to understand what Resolve considers part of that selection.
There is another naming trap. Resolve now has two calls named GetSelectedClips(). The Media Pool version operates on selected Media Pool clips. The new Timeline version returns selected timeline items. They belong to different objects and return different contexts.
A wrapper or internal library should therefore make that distinction obvious rather than exposing both under an ambiguous helper name. Calling the right method on the wrong object is a wonderfully efficient way to automate nothing.
Free Console, Studio outside
Scripting availability also needs careful wording. Resolve’s scripting environment includes Python and Lua access within the application (and has done so for years), while external scripting forms part of the Studio workflow. For facilities, this creates a distinction between an artist running an in-application helper and an external service controlling Resolve from another process.
The former can be a small productivity script launched inside Resolve, or talking to the MCP. The latter becomes deployment infrastructure, with licensing, environment configuration, application state and error handling to consider. The update therefore does not introduce scripting to Resolve. It expands an existing API in places that make artist-driven automation easier to construct.
That difference is worth retaining because “Resolve now supports scripting” would be wrong. It has supported scripting for years. What changed is what a script can see and control.
Media Pool to timeline
Another addition is MediaPoolItem.GetTimeline(), which allows a timeline represented in the Media Pool to provide its corresponding Timeline object. That is a smaller change, but potentially valuable in structured projects. A facility tool can navigate Media Pool organisation and move from the timeline entry it finds there to the Timeline API object it needs for further operations.
Previously, scripts could already iterate project timelines. The new route is quite interesting because Media Pool organisation can itself carry workflow meaning. Episodic versions, language masters, conform timelines, reviews and deliverables live in carefully organised bins, ideally.
A script can therefore use that structure as part of its navigation rather than assuming that the currently open timeline or a numerical timeline index is always the correct target.
Handles enter the API
The render side adds more consequential controls to SetRenderSettings(). The documented keys include UseFullExtents, AddFrameHandles and DataBurnIn. These fill gaps that matter for automated VFX pulls and delivery workflows.
Handles are an obvious example. A VFX turnover may require additional source frames before and after the edit. If the handle count can be defined programmatically, a tool can construct that requirement as part of the job rather than relying entirely on a manually prepared Deliver-page preset.
Full extents similarly affect which portion of the source enters the render. Data burn configuration matters for review, reference and internal delivery material where identifiers or other burn-in information must accompany the image.
Resolve already had the underlying render concepts. The change exposes more of their configuration through the scripting API. Nobody needs a revolutionary new method for setting twelve-frame handles. They need the twelve-frame handles to still be twelve frames on job number 63.
True is a negotiable concept
The most important warning concerns SetRenderSettings() and its Boolean return value.
Testing by Poul Waligora (Again, read his stuff!) showed partial application when multiple settings were submitted together. An invalid key could be discarded while a valid key in the same dictionary was still accepted. Conversely, a call returning False could still leave valid settings from that same request applied.
That means a return value should not be treated as transactional confirmation of an entire compound settings dictionary. True does not establish that every requested setting was accepted. False does not establish that Resolve left all settings untouched.
For unattended delivery systems, that difference is substantial. A clean failure is relatively easy to handle. Partial configuration can put a render job into the queue carrying a mixture of expected and previous state.
Read-back is the awkward bit
Validation becomes more difficult because the render-job information available through the API does not provide convenient read-back for all of the newly exposed controls.
Job information includes established fields such as timeline marks, target directory, format and codec. The tested API behaviour did not expose corresponding render-job fields for handles, full extents or data burn that would let a tool simply read those values back and prove that the job contains exactly what was requested. That is the point where “scriptable” and “safe to leave running all night” begin to diverge.
A production wrapper can validate its own inputs, isolate sensitive setter calls and monitor render-job status. What it cannot assume is that a successful setter response gives complete, externally verifiable proof of every new parameter attached to the job.
Ten minutes of hindsight
At the other end of the pipeline, Blackmagic Camera 10.2.2 adds pre-record to Blackmagic Cinema Camera 6K. Blackmagic documents selectable pre-record intervals of 5, 10, 20 and 30 seconds, plus 1, 2, 5 and 10 minutes. The camera continuously records to the media while pre-record is active, then adds the configured amount of preceding material to the start of the recorded file when the operator presses record. So the camera has not developed foresight.
The obvious applications are documentary, news, events and other unscripted work where reality has declined to coordinate itself with the record button. If something important happens before the operator commits to recording, the configured preceding interval can still become part of the take. At the full ten-minute setting, the camera can retain enough recent history to cover a substantial delay between the beginning of an event and somebody deciding that perhaps this would be a good time to roll.
Depending on the production, it may also capture the entire conversation about whether the camera was already rolling. The answer, technically, is now “sort of.”
It records while waiting
The implementation detail is important. Blackmagic says the camera continuously records to its media while pre-record is operating. Only the configured preceding portion is preserved when the operator starts a recording.
That should not be casually described as the camera simply holding ten minutes in RAM. The documented behaviour involves continuous recording to the media card and preservation of the relevant cached section.
The attraction for post is simpler. Blackmagic says the cached section is added to the beginning of each recorded file. Editorial therefore receives the preceding action as part of the take rather than through a separate recovery workflow. Nothing has to be reconstructed simply because the operator was late to REC. The file is just longer at the front, which is arguably the most civilised possible implementation.
Ten minutes is not always better
Pre-record duration is configurable for a reason. A few seconds may be ideal for an interview reaction or an event where the trigger is obvious but human response is not instantaneous. Minutes make more sense when the relevant action can develop for some time before the operator knows that it needs to be retained.
Longer is therefore not automatically better. The correct window depends on what the crew is trying to protect against. Pre-record also should not replace normal recording discipline. It is a safety mechanism for unpredictability, not an acquisition strategy based on never deciding when a take begins.
Ten minutes of hindsight is useful. Ten minutes of everything becoming editorial’s problem is merely a different department’s workflow.
https://wildlion.media/davinci-resolve-scripting-api-21-0-4/
https://wildlion.media/davinci-resolve-python-scripting-the-complete-guide-to-the-api/
https://www.blackmagicdesign.com/products/davinciresolve
https://www.blackmagicdesign.com/products/blackmagiccinemacamera
| Product | DaVinci Resolve |
| Developer | Blackmagic Design |
| Relevant version | DaVinci Resolve 21.0.4 |
| New timeline API | Timeline.GetSelectedClips() returns selected timeline items |
| Timeline access | MediaPoolItem.GetTimeline() provides the Timeline object for a Media Pool timeline entry |
| New render controls | UseFullExtents, AddFrameHandles, DataBurnIn |
| Camera | Blackmagic Cinema Camera 6K |
| Camera software | Blackmagic Camera 10.2.2 |
| Pre-record intervals | 5 s, 10 s, 20 s, 30 s, 1 min, 2 min, 5 min, 10 min |
| Pre-record behaviour | Continuously records to media and adds the configured preceding interval to the start of the recorded file |
| Download | Blackmagic Design Support |
