PariVision

Demo

Run it on a clip

Pick one of our sample clips or an .mp4 from this camera. The whole pipeline runs in your browser, on this device, and nothing is uploaded. You get the event timeline, the tracked boxes over the video, the risk curve, an event table and a JSON file. Our rules are drawn for this one junction, so footage from anywhere else will give wrong answers.

Checking what this browser can run

Analyse your own clip

Any .mp4 works. The camera's own files are 10-bit 4:2:2 H.264: most browsers on Windows and Linux cannot play them, and Chrome on a Mac decodes them slowly, in software. In both cases we first convert the file here, in the browser, which in Chrome on our laptop takes about 40 s per minute of 4K. 8-bit H.264 at 1080p, the format of our sample clips, needs no conversion.

Or try a sample clip

Loading sample clips

Or run it live on a camera or a shared stream

How the browser run differs from our submission

  • The first run downloads the detector (38 MB) and the ONNX Runtime engine (14 MB for WebAssembly, 27 MB for WebGPU, less when the server compresses it). The browser keeps both in its cache for the next runs.
  • A file this browser cannot play, or decodes too slowly, is converted first by ffmpeg.wasm (a 33 MB download the first time): up to 10 minutes, 1920 px wide, 8-bit H.264 at CRF 23. The pipeline then reads that copy. On our Apple M5 Mac, Chrome converts 2 minutes of a camera file in 75 to 80 s. The converter is ffmpeg.wasm (MIT) around an FFmpeg core licensed GPL-2.0-or-later; its source is at github.com/ffmpegwasm/ffmpeg.wasm.
  • The detector runs on WebGPU where the browser offers it. Elsewhere it runs on the CPU through WebAssembly, which is slower. On our Apple M5 laptop a 30 s sample took 14 to 17 s on WebGPU and about 50 s on the CPU, in Chrome and in Firefox; a busy or slower computer takes longer. So on the CPU the page offers to analyse only the first 30 s of your clip.
  • It reads up to 10 minutes of a clip at 5 frames per second. The submission reads 10 frames per second.
  • The detector is YOLO26s at 960 px wide, 5 frames per second: the setting our submission falls back to on a machine without a GPU, and a fraction of the compute of its YOLO26m at 1280 px and 10 frames per second. On the two clips we could compare, it scores 0.351 against 0.339 (Score A, see the ablations). The smaller YOLO26n we used before scored 0.323 there and found fewer pedestrians (jaywalking F1 0.361 against 0.485).
  • To line the camera view up with our reference view, the page searches edge maps for the scale and shift that fit best and then refines them. The submission matches SIFT features.
  • Tracking, the signal reader, the event rules and the risk model are the same algorithms with the same settings, ported to TypeScript and checked against the Python output.