Speed up frame reading with sequential access optimization#970
Merged
Conversation
…board Phase 1: FrameSource.read_frame_at() with sequential access optimization. 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), and seek fallback. Phase 2: ThreadPoolExecutor for per-camera processing within each sync index. Each camera gets its own FrameSource and thread. Callbacks remain single-threaded (invoked from the sync-index loop, not pool threads). parallel=True by default with serial escape hatch. Phase 3: ETA display after 3s warmup, incremental coverage heatmap matrix updated O(1) per sync index with throttled signal emission every 5s. Coverage content panel shown during processing for live feedback. 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 better. 389/389 tests pass, 60/60 stability runs clean, 0 type errors.
FrameSource.__del__ guard (added in 07c4c2e) surfaced 17 warnings from tests that created streamers via create_streamer() or SynchronizedStreamManager but never called close()/cleanup(). Added cleanup calls at end of each test.
Widen adaptiveThreshWinSizeStep from 10 to 20, reducing threshold passes from 3 to 2 for ~2x faster failure paths. Add per-camera mirror hint (_last_mirrored dict) to try the previously-successful orientation first, avoiding the ~107ms wrong-orientation penalty. Combined with parallel processing from prior commit, this brings throughput from 64.8 to 162.6 cam-frames/s (2.5x improvement) with zero detection rate regression.
The heatmap rendering is trivially cheap (~15 fillRect calls for a 5-camera grid), so the conservative 5s throttle made the display feel frozen. At 2 updates/second the heatmap visibly fills in during processing, providing useful real-time feedback.
The collection thread creates a dedicated FrameSource and reads frames sequentially (indices [0, 10, 20, ...]). get_frame() acquires a lock and seeks from a keyframe on every call — designed for concurrent random access. read_frame_at() has no lock and uses an O(1) sequential fast path, which matches the single-owner in-order access pattern exactly.
_process_camera() creates a dedicated single-owner FrameSource and iterates frames sequentially. Same access pattern as intrinsic collection — read_frame_at uses the O(1) sequential fast path instead of get_frame's lock-and-seek.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
IntrinsicCalibrationPresenter._run_collection()andapi._process_camera()both create a dedicated single-ownerFrameSourceand read frames sequentially (every Nth frame). They were usingget_frame(), which acquires a lock and seeks from a keyframe on every call.read_frame_at(), which has no lock and uses an O(1) sequential fast path for in-order reads.FramePacketStreamercalls left unchanged — those involve concurrent access (peek methods called from UI thread) and genuine random-access seeks, whereget_frame()is correct.Test plan