Bound non-realtime RTSP frame buffering - #2959
Conversation
|
👋 Thanks for the pull request! Here is how automated Claude review works here, so you spend credits (and reviewer time) wisely. 🚦 This PR is marked Ready for review, so automated Claude review will run — and every pass spends real credits. Warning 💸 The Claude reviewer bills in credits, not vibesAutomated review spins up a real agent that reads real code and spends real credits on every pass. It is glad to help — but it is not a rubber duck, a linter you poke in a loop, or a substitute for reading the contributing guide. Treat it like an expensive senior reviewer whose time you booked, and show up prepared. Draft when unsure, Ready when you mean it:
However you get there, arrive prepared:
Reviews are not free. A draft costs nothing to review; a Ready PR is a promise that it is worth reviewing.
|
|
🤖 Claude review started at commit New commits are not auto-reviewed. Add the |
|
Review summary Skills: review-topic-concurrency-and-resource-safety, review-topic-test-hygiene (also considered review-topic-input-boundary-security for RTSP-URL credential handling). No dedicated surface skill covers Scope: the new Checked and clean:
No medium+ blocking findings; no open clarification questions. Not a versioned subsystem (not inference-models or Execution Engine, no public HTTP/SDK/workflow-block contract), so no changelog entry is required. Reviewed at HEAD: a110046 |
|
😎 PR passes the vibe-check and trust-me-bro verification. |
Description
Non-realtime RTSP processing can accumulate decoded frames faster than inference consumes them; bound its decoder queue to the existing 60-frame file-source capacity and pause decoding when full, preserving frame order and timestamps.
Type of change
How has this change been tested?
Any specific deployment considerations