What we built, what worked, what did not

What we built

A detector-tracker-rules pipeline behind the official solution.detect_events interface. A fine-tuned YOLO finds road users and signal heads, ByteTrack links them into tracks, and a scene map of the junction is aligned to each clip with a SIFT homography. Seven per-class rule modules turn tracks and zones into time segments. The same entry point backs the live demo. See the approach for the diagram and every rule.

What worked

• Signal heads as detector classes. Red and green heads come out of the same detector pass, so red_light and stop_line need no extra model. The phase strip on the EDA page shows when each head is visible.
• Measuring the camera shift before trusting the map. The “fixed” camera moved by up to 38 px (at 720p) between clips. The alignment step brings the residual under 0.5 px on every sample, and it falls back to the original map with a logged reason when a match is unreliable.
• One shared scene map. Lanes, crossings, island and stop lines drawn once cover all 14 classes' spatial needs and carry over to the hidden set from the same camera.

What did not work, or not yet

• Seven classes have no detector: accident, near_miss, wrong_way, illegal_u_turn, stopped_vehicle, road_obstacle and fire_smoke. Part B (accident anticipation) is not implemented, so its score is 0.
• Our dev set is small. We manually labelled all four provided clips and merged overlapping segments of the same class. It contains 22, 18, 29 and 11 event intervals respectively. Results on these clips may not generalise to unseen traffic or weather.
• Label definitions are ambiguous at the edges. Our first pass had long failure_to_yield and jaywalking spans that merged many people. Under the task's one-segment-per-overlap convention these become single long events, which is correct but hard to match at IoU 0.7.
• 4K decoding dominates runtime on CPU. Building this site's 540p previews from the 140 Mbit/s originals took several times real time on a 4-core laptop, before any detector ran. The GPU judging machine has the budget, but the CPU demo must limit clip length.
• Part of C3896 does not decode cleanly. ffmpeg reports corrupt H.264 packets in the original file. Decoding recovers and the clip plays to the end, but some frames can come out damaged, so a reader should expect failed reads and rules should not treat a missing frame as a stopped vehicle.

What we would do next

1. Have a second reviewer audit the four labelled clips, then tune thresholds against F1 at IoU 0.7.
2. wrong_way and stopped_vehicle next: both are direct rules on existing tracks plus the lane directions we already measured with optical flow.
3. Part B with time-to-collision between track pairs, calibrated so 0.5 means “probably within 5 s”. This also gives near_miss candidates.
4. Decode on the GPU (NVDEC) and batch the detector to widen the time margin.

Links

• Repository: https://github.com/hvsniddin/traffic-analyzer
• Sample predictions: predictions_samples.json
• Weights: weights/
• Demo API contract: README