showstack / protocols / freed
FreeD
Camera tracking data protocol originally from Vinten, carrying pan, tilt, roll, position, zoom and focus. The de facto interchange format between a tracked camera and a render engine in virtual production and AR graphics.
Control
Small, urgent, must arrive
Small messages that either repeat constantly or fire once. Bandwidth is almost never the problem.
What kills it. Latency and loss on the messages that fire once. A repeating level survives a dropped packet; a GO does not.
Ports
udp/6000
Common default; the port is configurable per system
No registered port: each vendor picks a default.
No registered port: each vendor picks a default.
What goes wrong
FreeD carries lens data as encoder counts, not as calibrated focal length. Without a lens calibration file the render engine cannot match the real lens, and the composite will not line up.
Several incompatible variants exist under the same name, differing in packet layout and unit conventions. "FreeD" between two vendors is a thing to test, not to assume.
It is a one-way broadcast with no acknowledgement. A dropped packet is a dropped frame of tracking, which is why the network carrying it should be dedicated.
What speaks FreeD (3)
| Product | Direction | Notes |
|---|---|---|
| Unreal Engine Epic Games |
in | FreeD camera tracking input via Live Link, the usual path in an LED volume. |
| Mo-Sys StarTracker Mo-Sys Engineering |
out | Camera position and lens data. |
| stYpe RedSpy stYpe |
out | Camera position and lens data. |
Typical use
- Feeding camera position to Unreal Engine in an LED volume
- Driving AR graphics from a tracked camera
- Virtual set and broadcast graphics
Sources
- Vinten camera robotics — Vinten primary
Understand the mechanism
Something wrong, or missing?
Known gaps on this entry: first_published, implementations, spec_url. If you can source one of them, that is a ten minute pull request.
Edit this entry on GitHub — one file, editable in your browser, and your handle goes on it permanently.