Technical report

We built a detector-plus-rules system that runs fully offline and produces valid, deterministic output for every video, inside the 3x time budget on a 4 GB laptop GPU. On the four organizer samples it finds red-light runs, stop-line violations, stopped vehicles and vehicles not yielding at the crossings; we checked every class by eye. Part B never raises a false alarm on the samples, but we had no accident footage to calibrate its early warning against.

What we built

A YOLO11m detector and ByteTrack produce tracks; kinematics turn them into speeds normalised by vehicle size; fourteen explicit rules turn tracks into segments; post-processing enforces the output contract. Part B runs its own online copy of detector and tracker on every third frame and combines time-to-collision, braking, swerving, wrong-way motion and pedestrian conflicts in a logistic score. The scene (lanes, stop lines, crosswalks, zones) is drawn once in scene.json; where it is missing, the road surface, lane flow and busy crossing points are learned from each video's own tracks.

On the organizer samples

The samples show one signalised Tashkent intersection at noon and at dusk. We drew the scene once (carriageway, stop line, three crossings, two signal heads, the junction box) on one frame; every video is aligned to that drawing by SIFT and a RANSAC homography, so a slightly moved camera does not move the lines. There are no labels, so we reviewed our own predictions frame by frame: start, middle and end frames with the involved tracks highlighted.

ClassReviewedCorrectUnclearWrongWhat we changed
red light3300nothing
stop line3210nothing
stopped vehicle2200nothing
failure to yield4310segments now run from "vehicle enters the crossing" to "leaves it" (were 0.3 to 1 s, now 0.7 to 4.5 s)
near miss2011a pair now needs a motor vehicle (two pedestrians had been flagged)
jaywalking1001a jaywalker must walk 1.5 body lengths on the road (a person waiting at the kerb had been flagged)

This measures precision only. Nobody watched the full 18 minutes for missed events, so recall is unknown; data/review_samples.json in the repository lists every verdict.

Real crash clips

The samples contain no accidents, so we tested the accident rule on four public CCTV clips from other intersections: three real crashes and one dense-traffic clip without events. We labelled the crashes with the task's conventions and scored them, together with our two development clips, with the official evaluator.

ClipGround truthRoadSight
Rollover, downtown junction, day5.85-8.50 saccident 5.95-8.43 s (matched even at tIoU 0.7)
T-bone, junction, day (6 s clip)0.70-5.00 smissed
Head-on, junction, night2.00-4.00 smissed
Three normal-traffic clipsno eventsno events

Before this test the rollover was reported as a near miss and no clip produced an accident. A vehicle that spins or rolls breaks its track, so a track vanishing mid-junction at the moment of contact now confirms the impact, the new IDs of the same wreck extend the crash until it stops, and a near miss is dropped when an accident is confirmed for the same pair. Accepting any speed jolt at contact would also have caught the T-bone, but it produced three false accidents in dense stop-and-go traffic, so the rule stays conservative. The night head-on is lost in headlight glare. Part B does not anticipate these crashes. Replaying its recorded tracks showed why: before the rollover, time to collision only becomes finite 0.2 s before impact, and nothing rises before the night head-on, while on the organizer's camera a finite time to collision appears in 47% of normal frames (queues and perspective make "about to touch" routine). No setting of our hand-made features separates the seconds before these crashes from everyday traffic at the test camera, so we did not tune Part B on three clips: that would raise false alarms on the camera that matters. A real improvement needs a learned anticipation model trained on a crash dataset.

What worked

Ablations

Measured during development on two public traffic clips with no events (a 4K highway clip and a 1080p city underpass), so every event or alarm there is a false positive.

Kinematic noise

ChangeMeasureHighwayCity
Foot-point kinematicsAcceleration, 1-in-1000 low tail, BL/s²-4.08-18.1
+ track splitting, border rows, box-top velocitysame-1.59-10.3
Foot-point kinematicsHeading change in 1 s, 99.9th percentile158°180°
+ same fixessame55°180°

Detection coverage

Detecting at 960 px instead of 640, feeding low-score boxes to ByteTrack and starting tracks at 0.3 instead of 0.6 took the city clip from 95 to 419 tracks, and from 4.5 to 23.8 tracked objects per processed frame. The new tracks are mostly small and faint, so the rules only use the 308 tracks with mean confidence of at least 0.4 and a median size of at least 2.5% of the frame height.

False events and alarms

ChangeMeasureHighwayCity
Near-miss rule with fixed thresholds (640 px)False events02
+ size filter, closing speed, noise-relative evasionsame00
960 px detection, lower track thresholdssame09
+ reliable tracks, ID-switch checks, displacement before a stopsame01
+ wider border margin, braking must cut speed by 40%same00
Risk v0 (moving-average velocity)Frames above the 0.5 alarm6.7%80.2%
+ least-squares velocity, reliability filters, noise floorsame0.0%5.6%
+ conjunction featuresame0.0%2.3%
Final detector, track-confidence filter, bias -5.0same0.0%1.2% (one alarm)

Runtime

ClipLengthPart APart BBoth / length
Loading.

The organizer's harness on an RTX 3050 laptop GPU (4 GB). YOLO11m FP16 at 960 px for events (~12.5 frames per second of video) and 640 px for risk (~8 per second). Most of Part B is the harness decoding every 4K 10-bit frame. The limit is 3x the video length.

What did not work

Next steps