But test the end-to-end time. A theoretically better source is not useful if every night of the trip becomes a two-hour proxy wait.
If your system can handle it, keeping the source live is much more flexible. An intermediate can still make sense when performance is poor or the rest...
Check whether the machine has hardware decode support for the exact codec/profile/bit depth and whether the editor is actually using it.
I would test the exact camera files you own rather than choose from feature lists alone.
Yes, a flat/Log recording is not supposed to look finished straight from the camera. The important part is using the correct transform or grading work...
File organization first, then frame-rate planning. You can correct color differences later, but missing files and ambiguous card dumps destroy time.
I would want camera model, firmware, recording mode, where the GPS came from, file/container, editor version, whether extraction is required, and whic...
Do not delete the original. Test the converted file in the telemetry tool/editor you plan to use and compare it against the source. A successful video...
For a long project I would only preprocess the clips that actually need telemetry. That reduces extra renders and keeps the main edit simple.
I would treat telemetry as a separate workflow unless your exact Resolve setup has a tool/plugin that reads the camera data you need. That keeps expec...
That would be useful. The separate extraction step is what usually makes me stop using telemetry for quick edits, so a direct path matters more to me ...