Sequential frame reads, parallel camera processing, and live dashboard

[mprib]

Summary

• Sequential frame reads — FrameSource.read_frame_at() tracks decode position to avoid per-frame keyframe seeks. O(1) for sequential reads vs O(GOP) for random access. Three paths: fast (gap=1), small-gap (decode forward ≤10 frames), and seek fallback.
• Parallel camera processing — ThreadPoolExecutor processes all cameras concurrently within each sync index. Each camera gets its own FrameSource and thread. Callbacks remain single-threaded. parallel=True by default with serial escape hatch.
• Live dashboard — ETA display after 3s warmup, incremental coverage heatmap matrix updated O(1) per sync index with throttled signal emission every 5s.

Performance

Charuco profiling: 1.41x speedup (64.8 vs 46.0 cam-frames/s on 5-cam demo). GIL-bound OpenCV limits thread parallelism; ONNX expected to benefit more.

Key design decisions

• Incremental coverage matrix: O(1) per frame, not O(n) DataFrame rebuild
• Real cam_ids on heatmap labels (C{cam_id}), not index-based
• QueuedConnection for coverage_updated signal (worker thread → main thread)
• progress_updated signal extended: Signal(int, int, int) → Signal(int, int, int, str) for ETA string

Test plan

• 389/389 tests pass
• 60/60 stability runs clean
• 0 type errors (basedpyright)
• 6 new test_frame_source_sequential.py tests with pixel-exact assertions
• Visual verification: ETA + live heatmap during processing (manual)