Script for DaVinci Resolve to import and sync audio and video from the 101
Version tested in parenthesis
- DaVinci Resolve Studio (18.1 build 16)
- Python (3.10.10) and (3.11.1)
- pip install pywin32
- PyUSB
- libusb-package
- Create a Project setting named Debrief in Resolve
- Create a UI Layout named Debrief in Resolve
- Clone or copy the script to the folder
C:\Users\username\AppData\Roaming\Blackmagic Design\DaVinci Resolve\Support\Fusion\Scripts\Comp\VRDreplay - Change DaVinci Resolve setting
DaVinci Resolve -> Preferences... -> General -> System -> External scripting usingtoLocalorNetwork - Create a Windows shortcut to python.exe "C:\..\Import_VRD.py" with icon set to Helicopter.ico
- PYTHONPATH = C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting\Modules
- RESOLVE_SCRIPT_API = C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting
- RESOLVE_SCRIPT_LIB = C:\Program Files\Blackmagic Design\DaVinci Resolve\fusionscript.dll
The script is available through the menu Workspace -> Scripts -> Comp -> VRDreplay -> Import_VRD. Invoking the script will automatically locate the VRD disk connected to the USB adapter and create a new project with a timeline containing all the recordings. If there is a significant period without recordings (multiple sorties) additional timelines will be created.
While writing this script, the following references have been used (not an exhaustive list)
- Unofficial DaVinci Resolve Scripting Documentation
- ResolveDevDoc’s documentation
- C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting\README.txt
- basuke/create-vlog-project.py
- Info on how to set timeline framerate
- Undocumented Resolve API functions - (trackIndex and recordFrame)
- Looking up Timeline item properties
Both the video and audio media files are stored as .mkv files with an accompanying .tag file with identical root file names. The .mkv file holds the media while the .tag file holds timing information on each frame to be used when syncing for playback.
The Matroska file format. Note that the byte order is BIG ENDIAN.
The video .tag files contain data as shown in the table below, while the .tag files accompanying the audio only has frame, unix time and nanoseconds, no additional data.
| Line no | Text | Description | Decode |
|---|---|---|---|
| 39166 | 62.759998 | Frame at second | 62.76 |
| 39167 | 1661781846 | Unix timestamp | Aug 29 2022 14:04:06 |
| 39168 | 919834895 | Nanoseconds to be added to timestamp | 0.919834895 sec |
| 39169 | 7 | Lines of additional data | |
| 39170 | 3008 | Unknown data 1 | |
| 39171 | 3008 | Unknown data 2 | |
| 39172 | 3012 | Unknown data 3 | |
| 39173 | 3012 | Unknown data 4 | |
| 39174 | 3008 | Unknown data 5 | |
| 39175 | 2952 | Unknown data 6 | |
| 39176 | 924 | Unknown data 7 |
The event files holds a timestamp for when the event switch has been toggled in the cockpit or by the SO. It also holds additional information that still is not fully reversed. See the document Reversing the Event file for details.
There seems to be multiple problems with the .mkv video files. The following are beeing investigated.
- Duration is one frame to short
- For files in the Recovered_Segments folder, the file header is missing segment size
- Missing frames
- Codec issue during playback
- QUAD video has a timing issue
Segment information -> Duration (element ID 0x4489) is one frame too short. Typically each video file is 7500 frames but duration is set to 7499. The duration is given in ticks as a double and seems to be 1ms per tick. The exact value for ticks can be found in Segment information -> Timestamp scale (element ID 0x2AD7B1) and is given in nanoseconds per tick. This script will assume 1ms pr tick and increase the duration of every file with 40ms to reveal the lost frame at the end of the clip.
| No of frames | No of ticks | Element ID | Size Length | Length | Double as hex |
|---|---|---|---|---|---|
| 7501 | 300 040 | 44 89 | 8 | 8 | 41 12 50 20 00 00 00 00 |
| 7502 | 300 080 | 44 89 | 8 | 8 | 41 12 50 C0 00 00 00 00 |
If the recording has ended abnormally, the file will likely be in a folder named Recovered_Segments without Duration ID 0x4489 set correctly. In offset 0x160 you will rather find a void space of 11 bytes: EC 01 00 00 00 00 00 00 02 00 00. The fix for this is the same as above but we also need to write the Element ID 0x4489 as well as element size 0x88 followed by the 8 bytes of duration.
Both of these duration related problems are handled by the fixMkv module.
It seems that video files in the Recoverd_Segments folder has segment size set to 01 FF FF FF FF FF FF FF (unknown). fixMkv will change this to the size of the remainder of the file.
| Offset | Element ID | Size Length | Size |
|---|---|---|---|
| 0x2F | 18 53 80 67 | 01=(7 bytes) | FF FF FF FF FF FF FF |
| 0x2F | 18 53 80 67 | 01=(7 bytes) | File size - 59 bytes * |
*) Offset 0x2F + 4 bytes Element ID + 8 bytes length descriptor = 59 bytes
The files seems to be of variable framerate close to 25 fps resulting in approximately 40ms pr frame. However, multiple frames in each clip are less than 0.05ms resulting in missing frames in DaVinci Resolve. This script handles this problem by assuming 25fps and cutting each file in multiple subclips based on the timings given in the .tag file effectively removing the missing frames.
The following has been observed when playing back the video files
| Software | Version | Observation |
|---|---|---|
| Windows 11 photo app | 2023.11050.16005.0 | Plays video with no noticeable problems. |
| VLC | 3.0.18 | Garbled image on lower half of the video. SOLVED by disabling hardware acceleration in settings |
| DaVinci Resolve (Free) | 18.1.4 | The missing frame is rendered as a red banner with the text Media Offline, the following frames are rendered correct |
| DaVinci Resolve Studio | 18.1.4 | The missing frame is rendered as a solid grey frame, the following 5 frames are rendered grey with small artifacts |
Occasionally the quad video has a timing issue. It seems like the video is split into the normal 7500 frames per file but instead of the normal 5 minutes it contains 6 minutes of material, resulting in 20.83 frames per second. When edited in a video editor with 25fps the video needs to be slowed down to 83.333%.
It is not known if the problem is always exactly 6 minutes of video in a 5 minute file or if the timing differs between sorties. Normally though, the quad video is exactly 5 minutes with 7500 frames.
In one sortie the problem was exactly 360 seconds per 7500 frames. No problem on the sortie before or after.
By investigating one of the .tag files from that sortie it seems that there are four frames of duration 40ms before one frame of duration 80ms. This patterns seems to be repeating.