Resolve Media Pool / Ingest
Thin router; depth stays in the kernel.
- Live tool mechanics —
docs/kernels/media-pool-ingest-kernel.md(themedia_poolingest boundary) +docs/guides/multicam-setup-guide.md. - Offline media front-end —
resolve-advanced/README.md→ themediatool.
Two servers — verify offline, import live
| Job | Server | Tools |
|---|---|---|
| Import / organize / relink in a running Resolve | davinci-resolve (Python, live) |
media_pool (`safe_import_media |
| Verify / inventory / hash-seal a card with no Resolve open | davinci-resolve-advanced (Node) |
media (needs ffmpeg + ffprobe on PATH) |
Offline media actions
ingest_verify— hash seal / verify / dupes-by-hash (chain of custody).media_inventory— fps / codec / colorspace / TC + card-gap report.sync— picture↔sound TC alignment + drift / MOS.relink_manifest,rename_plan(refuses camera originals) /reel_normalize,turnover_package,project_hygiene.
Rule of thumb: verify + inventory the card offline before importing, then import and organize live.
Boundaries & safety (AGENTS.md)
- Non-media files are not imported; the kernel never creates proxies, transcodes, or derivatives of source media.
- Native multicam clip creation/flattening is not in the public API — the setup helper preps a stacked timeline you convert in Resolve's UI (see the guide).
ImportMediahas no destination parameter — clips always land in the current folder, and an unrecognized destination argument is silently ignored. Create the bin,set_current_folderto it, then import. Getting this backwards puts clips wherever the current folder happened to be, which is routinely somewhere an automated step moved it.MediaPoolItem.GetTimelineis 21.0.4+ (issue #131) and is not reachable through this server yet. A media-pool entry that is a timeline cannot be turned back into a timeline object on older builds — checkresolve_control check_version_supportrather than assuming.- Never rename or derive camera originals without explicit approval;
rename_planrefuses them by design.