OC-SORT Explained: Observation-Centric Tracking Without ReID

Key Takeaways

OC-SORT is a pure-motion multi-object tracker from CVPR 2023 that needs no appearance model and no ReID network.
It reaches HOTA 63.2 on MOT17 and 62.1 on MOT20, the strongest no-ReID results of its generation.
Three mechanisms do the work: ORU re-updates the filter after occlusion, OCM adds a direction-consistency penalty, and OCR matches lost tracks on their last real observation.
Tracking alone runs at over 700 FPS on a single CPU; paired with YOLOv8n it holds 60–110 FPS on CPU.
It ships natively in Ultralytics, so enabling it costs one argument: tracker="ocsort.yaml".

OC-SORT stands for Observation-Centric SORT, and it is the point where the SORT family stopped trusting its own filter. As of 2026 it remains the performance ceiling for lightweight tracking without re-identification, and the reason is a single design decision: keep the real observations in charge instead of the predictions.

What OC-SORT Is, and What SORT Gets Wrong

OC-SORT belongs to the tracking-by-detection paradigm and is a purely geometric tracker. It uses no appearance features whatsoever — only the position, size and motion pattern of detection boxes — to associate tracks. Its design goal is to improve SORT and ByteTrack’s robustness under occlusion and non-linear motion without adding compute.

The classic SORT family is estimation-centric: the Kalman filter’s state prediction drives the tracking process. Once a target is occluded and detection is lost, the filter can only extrapolate linearly, and over time that produces velocity drift and accumulating position error. When the target reappears it no longer matches its original track, which shows up as an ID switch or a lost track.

The specific failure modes are:

Error accumulation during occlusion: with no observation, the Kalman filter predicts alone, and velocity and position error grow with time.
Noisy velocity estimates: jitter in the detection box contaminates the filter’s velocity state, so the direction estimate is unreliable.
Hard recovery: when the target reappears, matching against an already-drifted prediction rarely finds the original track.

OC-SORT’s core idea is to pull tracking’s centre of gravity from the filter’s estimate back to the real observation, using historical observations to correct the filter’s accumulated error.

The Three Mechanisms

ORU: Observation-Centric Re-Update

This is the central innovation, and it solves post-occlusion error accumulation.

When a target reappears after occlusion and a detection box re-matches its track, the conventional approach simply updates the Kalman state with the current frame. But the filter’s internal velocity and covariance have already drifted badly during the observation gap, and a single update cannot repair that.

ORU instead:

records the last real observation before occlusion and the current observation at re-match, using both as anchors;
interpolates a virtual trajectory between the two anchors, filling in virtual observations for every missing frame;
re-runs the Kalman update over those virtual observations in time order, correcting the velocity and position error accumulated across the whole occlusion window.

In plain terms: conventional tracking reconnects the broken line, while OC-SORT repaves the missing section before driving over it. The filter state returns to the correct trajectory, so there is no velocity jump or position offset when the target reappears.

OCM: Observation-Centric Momentum

This solves noisy velocity estimation and mis-association under non-linear motion.

SORT matches on IoU alone. When a target turns suddenly, the predicted and actual positions diverge and the match easily lands on a neighbouring target. The filter’s own velocity output is heavily contaminated by detection jitter and cannot be trusted for direction.

OCM instead:

ignores the filter’s velocity state and computes motion direction directly from historical real observations separated by Δt frames, which is lower noise because it comes from actual detections;
adds a direction-consistency penalty to the matching cost: the more a candidate box’s direction deviates from the track’s history, the higher the cost;
uses a final cost of −IoU + λ × direction angle difference, with the inertia parameter controlling the penalty weight.

This makes the tracker far more tolerant of sudden acceleration, turning and curved motion, and cuts mis-association sharply in dance, sport and aggressive UAV manoeuvre footage.

OCR: Observation-Centric Recovery

This solves the difficulty of recovering a lost track.

Conventional tracking matches lost tracks against new detections using the Kalman prediction. The longer a track has been lost, the further that prediction has drifted, so it can never match and the track is deleted and a new ID created.

OCR instead matches recently lost tracks using the last real observed position rather than the prediction. A real observation is far more accurate than a drifted prediction, which greatly improves re-identification after short occlusions. Combined with ORU, once the track is recovered the accumulated error is corrected automatically, giving a seamless continuation.

The Five-Stage Pipeline

The full pipeline runs in five stages, all online and computed forward per frame:

Track prediction: the Kalman filter predicts the next-frame position and velocity state for every active track.
First association: high-confidence detections are matched to predicted tracks using a cost that fuses IoU similarity with OCM direction consistency, assigned by the Hungarian algorithm.
ORU state correction: for tracks that matched successfully but had previously been lost, ORU is triggered and the filter is re-updated along the virtual trajectory.
OCR second-pass recovery: unmatched detections are matched against recently lost tracks using their last real observed positions, recovering targets lost to short occlusions.
Track lifecycle management: create new tracks, delete tracks lost beyond the timeout, and update track states.

Optional extension: the Ultralytics implementation exposes a use_byte switch which, when enabled, reuses ByteTrack’s high/low-score second-pass matching to raise recall in dense scenes.

Benchmarks and Speed

The paper reported state-of-the-art results among no-ReID trackers of its generation:

MOT17: HOTA 63.2, ahead of every contemporary pure-motion tracker.
MOT20: HOTA 62.1, with a clear advantage in dense crowds.
DanceTrack: the largest improvement, on a dataset built specifically for highly non-linear motion.
Speed: over 700 FPS for the tracking stage alone on a single CPU; with YOLOv8n detection it holds 60–110 FPS on a single CPU, close to ByteTrack and far faster than DeepSORT.

How It Compares

Algorithm	Needs ReID	Main strength	Main weakness	Difference from OC-SORT
SORT	No	Fastest, simplest logic	ID switches on any occlusion; poor under non-linear motion	OC-SORT fixes occlusion and non-linearity at almost no speed cost
ByteTrack	No	High recall in dense scenes, mature engineering	Many ID switches after occlusion; moderate motion robustness	OC-SORT keeps BYTE matching optional and improves occlusion robustness by 30%+
DeepSORT	Yes	Stable IDs through long occlusion	Slow, compute heavy, ReID porting is complex	OC-SORT is 3–5× faster, comparable on short occlusions, and needs no extra model
BoT-SORT	Optional	Balanced accuracy, good camera-motion compensation	Slower than OC-SORT, more complex to implement	Similar performance; OC-SORT is lighter and better under non-linear motion

The core advantages in summary:

No extra model: pure geometry, no ReID training, no NPU or AI accelerator budget consumed, edge friendly.
Occlusion robust: ORU plus OCR means short occlusions almost never produce an ID switch.
Handles non-linear motion: OCM’s direction constraint keeps fast-turning and curved trajectories stable.
Cheap to engineer: a SORT extension with little code, easy C++ or Python porting, and seamless fit with the YOLO ecosystem.

Running It With YOLO

Ultralytics YOLOv8 and YOLOv11 integrate OC-SORT natively — the third officially supported tracker after ByteTrack and BoT-SORT — so enabling it needs no development work:

from ultralytics import YOLO

model = YOLO("yolov8n.pt")

# enable OC-SORT tracking directly
results = model.track(source="video.mp4", tracker="ocsort.yaml")

Its dedicated parameters

Parameter	Default	What it does	How to tune
inertia	0.2	Weight of the direction-consistency penalty	Raise to 0.5–0.8 for lots of non-linear motion; lower to 0.1–0.3 for smooth motion
delta_t	3	Frame interval used to compute motion direction	Raise to 3–5 for high frame rates and fast targets; lower to 1–2 for low frame rates
use_byte	True	Whether to enable ByteTrack-style low-score second-pass matching	On for dense scenes; off if you want maximum speed
max_age	30	Maximum frames a lost track is retained	Raise for long occlusions; lower if you see false matches

Edge Deployment Notes

RK3588 / Jetson Orin NX: deploy OC-SORT first. It runs on CPU alone, consumes no NPU budget, and tracks visibly better than ByteTrack.
Lower-power platforms (RK3568, Raspberry Pi): disable use_byte and reduce delta_t to approach SORT’s speed while keeping basic occlusion resistance.
C++ porting: the core logic is only a few hundred lines, so it can be moved to embedded Linux quickly from the official C++ source.

Where It Fits and Where It Doesn’t

Best suited to

Security scenes with frequent occlusion: malls, metro gates, corridors and lift lobbies, where short occlusions are constant and OC-SORT switches IDs far less than ByteTrack.
Non-linear motion: sports venues, dance capture, and drone or counter-drone tracking, where targets manoeuvre and turn hard.
Small targets and jittery detection: aerial footage and long-range surveillance, where box instability is the norm and observation-noise robustness matters.
Compute-constrained edge devices: where a ReID model will not fit but better stability than ByteTrack is required.

Not the right choice for

Long complete occlusion: if a target disappears for more than about ten seconds, a pure motion model cannot distinguish identity and a lightweight ReID is needed.
Highly similar, extremely dense targets: at a crowd of ten thousand, pure geometric matching hits its ceiling and ReID-based methods win on accuracy.

Tuning priority in practice

Improve YOLO detection first — fewer misses and more stable boxes beat any tracker change.
Then tune the OC-SORT basics, inertia and delta_t, to the scene’s motion characteristics.
Enable use_byte in dense scenes to reuse low-score detections for recall.
Only if ID switches persist, add a lightweight ReID module rather than switching to a heavier algorithm.

Have questions about this article? Feel free to contact us at [email protected] — we’re happy to help!

Frequently Asked Questions

What problem does OC-SORT actually solve?

ID switches and lost tracks after occlusion. Conventional SORT relies on Kalman prediction during an observation gap, and that prediction drifts; OC-SORT uses the real observations before and after the gap to repair the filter state.

Does OC-SORT need a ReID model?

No. It is purely geometric, using box position, size and motion history. That is why it runs at over 700 FPS on a single CPU and consumes no NPU budget on an edge device.

What are ORU, OCM and OCR?

ORU re-updates the Kalman filter along an interpolated virtual trajectory after occlusion. OCM adds a direction-consistency penalty to the matching cost. OCR re-matches lost tracks using their last real observed position instead of a drifted prediction.

How accurate is OC-SORT on standard benchmarks?

HOTA 63.2 on MOT17 and 62.1 on MOT20, the best no-ReID results of its generation, with the largest improvement on DanceTrack, which is built for highly non-linear motion.

How do I enable OC-SORT in Ultralytics YOLO?

Pass tracker="ocsort.yaml" to model.track(). It is natively supported in YOLOv8 and YOLOv11, so no extra installation or training step is required.

About Aomway

Aomway has been developing and manufacturing video transmission and UAV radio hardware for over 15 years, producing equipment for any frequency band from 1 GHz to 9 GHz at power levels from 3W to 15W. We build high-power FPV video transmitters, directional and circularly polarised antennas, digital links, fiber-optic tether systems and detection hardware for pilots, integrators and commercial operators worldwide.