motcpp

Multi-object tracking in Python works for research but fails in production: a ByteTrack running at 45 FPS in Python is the bottleneck, not the detector. Robotics and autonomous systems need tracking that runs well under 5ms per frame, leaves headroom for the full perception pipeline, and doesn’t pull in a Python runtime on edge hardware.

The alternative — writing a C++ tracker from scratch — means re-implementing Kalman state machines, IoU matching, track lifecycle management, and ReID embedding pipelines. Every team that needs tracking ends up solving the same problem.

motcpp implements 10 state-of-the-art trackers — from SORT to BoostTrack — behind a single unified API. Switching between trackers is a one-line change; the update(detections, frame) call signature is identical across all of them.

Inspired by BoxMOT’s algorithmic breadth, the library brings the same coverage to C++ with zero-copy Eigen matrices for hot paths, CMake find_package / FetchContent integration, and an ONNX Runtime ReID backend that accepts any appearance model as an .onnx file. Camera motion compensation (ORB, ECC, SoF) is built in for moving-camera scenarios.

Detection matrix [x1, y1, x2, y2, conf, class_id] → tracker update() → track matrix [x1, y1, x2, y2, track_id, conf, class_id, det_idx].

Motion-only trackers (SORT, ByteTrack, OC-SORT, UCMCTrack, OracleTrack) use Kalman predict + IoU assignment without appearance. ReID trackers (StrongSORT, BoT-SORT, DeepOC-SORT, HybridSORT, BoostTrack) additionally run the ONNX appearance model on each crop and update an EMA embedding store per track.

Track state machine: Tentative → Confirmed → Lost → Deleted. All trackers share the same base lifecycle; each overrides the association step.

MOT benchmark tooling is built in: motcpp_eval CLI evaluates on MOT17/MOT20 sequences with pre-generated YOLOX detections and FastReID embeddings available in the GitHub releases.

MOT17 ablation split — Intel i9-13900K, single thread, YOLOX detections + FastReID embeddings:

Tracker	HOTA	MOTA	IDF1	FPS
SORT	62.4	75.2	69.2	1250
ByteTrack	66.5	76.4	77.6	1100
OC-SORT	64.6	73.9	74.4	850
UCMCTrack	64.0	75.6	73.9	980
StrongSORT	66.2	75.8	77.1	95
BoT-SORT	66.8	76.2	78.3	85
BoostTrack	67.5	77.1	79.2	75

C++ vs Python speedup — same tracker, same hardware:

Tracker	C++	Python	Speedup
ByteTrack	1100 FPS	45 FPS	24×
OC-SORT	850 FPS	32 FPS	27×
StrongSORT	95 FPS	8 FPS	12×

• 90% GoogleTest coverage across all components

• CI-verified on Linux, macOS, and Windows

The biggest design decision was the unified update() API. Early versions had separate call signatures for motion-only vs. ReID trackers. Collapsing them to one interface — even when the frame argument is unused by motion-only trackers — made benchmark harnesses and downstream integrations far simpler to write and maintain.

Kalman state space choices (XYSR vs. XYAH vs. ground plane) are not interchangeable between tracker families. Mixing them silently produces wrong predictions; the test suite that validates each tracker against a reference Python implementation was the only reliable guard against this class of bug.