Key Takeaways
- Beyond 30 frames of occlusion at 25 fps, pure motion trackers such as OC-SORT and ByteTrack lose the ID because the Kalman prediction drifts.
- The governing rule is geometry first, ReID as fallback: short occlusion by motion, long occlusion by appearance.
- Post-hoc re-matching touches only track birth and death, so it costs almost no compute and is the default for edge deployment.
- A four-stage pipeline covering 0-5, 5-15, 15-30 and 30-120 frames keeps ReID calls rare without breaking identity.
OC-SORT with ReID is the standard fix when a target disappears behind an obstacle for more than about one second. In a 25 fps stream that means occlusion beyond 30 frames, where a pure motion tracker’s Kalman prediction drifts away from the observation and the track can no longer be reconnected. Re-identification supplies the appearance evidence needed to link the same identity across the gap. As of 2026 this pairing is the usual upgrade path for YOLO-based tracking on edge hardware.
Two ways to pair OC-SORT with ReID
The design principle is: geometric matching first, ReID as the safety net; short occlusion handled by motion, long occlusion by appearance; compute and accuracy tiered to the platform. Running heavy ReID on every frame is what causes the compute blow-up, so both patterns below avoid it.
1. Post-hoc re-matching (external, the engineering default)
The OC-SORT tracker itself is left completely unchanged. ReID only intervenes at two moments: when a track is lost, and when a new track is born.
- OC-SORT runs its normal per-frame detect, match and track cycle.
- When a track is lost to occlusion it is not deleted. It moves into a lost-track pool that keeps the pre-occlusion appearance feature and the last observed position.
- When a new candidate track appears, it is not assigned a new ID straight away. It is first matched against the lost-track pool by ReID similarity.
- Above the threshold the original ID is restored and OC-SORT’s ORU mechanism corrects the motion state; below the threshold a new ID is issued.
- Advantages: tracking and ReID stay fully decoupled, the change is small, the tracking algorithm can be swapped freely, and ReID is computed only at track start and stop, so compute cost is very low.
- Disadvantages: there is a 1-2 frame ID switch delay when the target reappears, which does not matter for most applications.
- Best fit: the large majority of security, people-counting and industrial scenarios, and the first choice for edge deployment.
2. Cascade matching (embedded, accuracy first)
Here the ReID appearance feature is folded into the cost function of every matching round, the way DeepSORT does it: each frame computes a joint cost from motion similarity plus appearance similarity.
- Extract a ReID feature for every detection box each frame.
- Match first on Kalman-predicted IOU, then cascade the unmatched remainder on appearance features.
- Keep the association alive with features throughout the occlusion, so the ID resumes directly on reappearance.
- Advantages: the best ID continuity, almost no switching, which suits behaviour analysis and trajectory tracing.
- Disadvantages: features must be extracted for every box every frame, so compute cost is high and edge hardware struggles.
- Best fit: server-side or high-end GPU deployments, or cases where ID continuity is critical.
For OC-SORT the post-hoc pattern is recommended first. Its own OCR mechanism already handles short occlusion well, so ReID is reserved for the long gaps, and that layered division of labour gives the best return per watt.
The optimal OC-SORT + ReID pipeline
Combining OC-SORT’s native ORU (observation re-update) and OCR (observation-centric recovery) mechanisms gives a four-stage matching pipeline that maximises reuse of motion and minimises ReID calls:
| Stage | Matched pair | Method | Occlusion covered | Compute |
|---|---|---|---|---|
| Stage 1 | Active tracks vs high-confidence detections | Native OC-SORT (IOU plus OCM direction constraint) | 0-5 frames (slight occlusion) | Very low |
| Stage 2 | Unmatched detections vs low-score detections | ByteTrack high/low-score strategy (optional) | 5-15 frames (missed-detection fill) | Low |
| Stage 3 | Unmatched detections vs short-term lost tracks | OCR observation-centric recovery (pure geometry) | 15-30 frames (short occlusion) | Low |
| Stage 4 | Unmatched new tracks vs long-term lost tracks | ReID appearance similarity | 30-120 frames (long occlusion) | Medium |
Three supporting mechanisms make the pipeline work:
- Split the lost-track pool: a short-term pool under 30 frames and a long-term pool from 30 to 120 frames, matched by OCR and ReID respectively, with anything beyond 120 frames deleted outright.
- ORU state repair: once ReID restores a track, OC-SORT’s ORU mechanism interpolates between the observations before and after the occlusion to correct the Kalman state, which avoids a velocity jump.
- Double check: after a ReID match passes, add a motion-consistency check on position and velocity direction to reject false matches caused by similar appearance.
Edge optimisation for the ReID module
ReID’s biggest cost is compute. For YOLO plus edge deployment there are four effective levers.
1. Backbone reuse: the near-zero-cost option
This is the most recommended approach on edge devices. Instead of deploying a separate ReID model, reuse the YOLO backbone to extract features and add only a lightweight ReID head.
- How: during YOLO inference, run ROI Align on each detection box, crop the corresponding region from the backbone feature map, and pass it through a small fully connected layer to produce the ReID embedding.
- Advantage: backbone computation is shared, so the extra compute cost is close to nothing.
- Caveat: the YOLO model must be trained with a joint ReID branch, or use an open-source pretrained weight set.
2. Lightweight model selection
If a separate ReID model is deployed, choose it against the compute platform:
| Platform | Recommended model | Feature dim | Relative speed | Use case |
|---|---|---|---|---|
| RK3568 / Raspberry Pi | OSNet_x0_25, MobileNetV2-ReID | 128 | Very fast | Extreme compute limits |
| RK3588 / Jetson Orin NX | OSNet_x0_5, ShuffleNet-ReID | 256 | Fast | Mainstream edge |
| Server / RTX GPU | OSNet_x1_0, BoTReID | 512 | Medium | High-accuracy needs |
Heavy ReID models such as Swin or Transformer variants are not recommended: the accuracy gain on edge hardware is small and the compute cost roughly doubles.
3. Trigger strategy
Avoid computing ReID for every target on every frame. Trigger it only at these moments:
- When a new track is born, extract the initial feature and store it in the feature library.
- When a track matches with confidence above 0.7, update the feature on a rolling basis.
- When a track recovers from the lost pool, run a ReID similarity check.
- In dense occlusion, compute ReID only for candidates that survive the IOU gate.
4. Feature library management
- Cap the lost-track pool, for example at 100 entries, and evict the oldest first on timeout or overflow.
- Update features with an exponential moving average: new feature = alpha times old feature plus (1 – alpha) times current feature, with alpha between 0.7 and 0.9, so a single jittery detection cannot pollute the template.
- Freeze feature updates during occlusion: never update from a partially occluded box, or background and occluder appearance leaks into the template.
Parameter tuning guide
Occlusion duration bands at 25 fps
- Short occlusion: under 30 frames, handled by pure motion.
- Medium to long occlusion: 30 to 120 frames, roughly 1 to 5 seconds, the ReID working range and the most common duration in real deployments.
- Very long occlusion: beyond 120 frames, roughly 5 seconds, where even pure ReID struggles. Combine it with business rules such as zone entry and exit logic.
Similarity thresholds
- Cosine similarity is the usual metric. For a single camera at a stable viewing angle, set the threshold to 0.55-0.65.
- Where lighting varies widely or viewpoints change, lower it to 0.5-0.55.
- Where targets look very similar, such as uniforms, raise it to 0.65-0.7.
Anti-mismatch checks
A ReID match must carry at least one geometric check:
- Position gate: the distance between the reappearance position and the lost position cannot exceed the maximum plausible travel.
- Direction gate: the motion direction cannot deviate from the historical direction by more than 90 degrees.
- Size gate: the target size cannot change by more than 50 percent.
Deployment plans by platform
High-end edge (RK3588 / Jetson AGX Orin)
- Plan: OC-SORT with use_byte enabled, a separate lightweight ReID model (OSNet_x0_5), and post-hoc re-matching.
- Layout: YOLO on the NPU, ReID on NPU or CPU, tracking logic on CPU.
- Measured result: with YOLOv8n the whole pipeline holds 40-60 fps and long-occlusion ID recovery exceeds 90 percent.
Mid-range edge (RK3568 / Jetson Orin NX)
- Plan: OC-SORT with use_byte disabled, ReID reusing the YOLO backbone, and post-hoc re-matching.
- Layout: shared YOLO backbone, ReID head quantised and deployed with YOLO, so no extra model is loaded.
- Result: frame rate drops modestly, since no additional model has to run.
Server side (RTX series)
- Plan: OC-SORT with cascade ReID and a high-accuracy ReID model.
- Layout: cascade matching on every frame for maximum ID stability.
- Best fit: smart security and behaviour analysis, where trajectory continuity requirements are strict.
Common pitfalls
- Do not reach for heavy ReID by default. A lightweight OSNet model is enough in most scenarios, and the accuracy gain from a heavy model is far smaller than the compute loss.
- Do not update features all the time. Stop updating during occlusion, low confidence and target overlap, or the template gets polluted.
- Do not rely on ReID alone. Combine it with geometric and motion constraints, otherwise lookalike targets are easily mismatched.
- Do not let the lost pool grow without limit. A larger pool means slower matching and a higher mismatch probability, so set a sensible cap per scenario.
Summary
For the large majority of long-occlusion scenarios, OC-SORT plus post-hoc lightweight ReID is the best answer. It keeps OC-SORT’s low weight and short-occlusion robustness, uses ReID only as a fallback for long gaps, requires little engineering change and keeps compute under control. That makes it the standard upgrade path for edge-deployed YOLO tracking systems.
Have questions about this article? Feel free to contact us at [email protected] — we’re happy to help!
Frequently Asked Questions
At what occlusion length does OC-SORT need ReID?
Around 30 frames at 25 fps, which is roughly one second. Beyond that the Kalman prediction drifts away from the observation and the track cannot be reconnected on motion alone, so appearance evidence becomes necessary.
Should I use post-hoc re-matching or cascade matching with OC-SORT?
Post-hoc re-matching for most deployments. It touches only track birth and death, so compute cost stays very low, and OC-SORT’s own OCR mechanism already covers short occlusion. Cascade matching is for servers where ID continuity is critical.
How much extra compute does ReID add on an edge device?
Very little if the YOLO backbone is reused, because feature extraction shares the existing computation and only a small ReID head is added. A separate ReID model costs far more and needs a mid-range or better NPU.
What cosine similarity threshold works for ReID matching?
0.55-0.65 for a single camera at a stable angle. Lower it to 0.5-0.55 when lighting or viewpoint varies widely, and raise it to 0.65-0.7 when targets look alike, such as people in uniform.
Why do track IDs still switch after a long occlusion?
Usually because the feature template was polluted during occlusion or because the similarity gate alone was trusted. Freeze feature updates while occluded, and always add position, direction and size checks before accepting a match.
About Aomway
Aomway is a radio-frequency engineering company that designs and manufactures long-range FPV video transmitters, antennas, goggles and UAV communication links, and it publishes technical notes on perception, tracking and embedded control. Its hardware is built for builders who need dependable links at range, and its documentation aims to explain the engineering behind each product.
