fix: remove FPS-based throttling from input source receiver loop#701
fix: remove FPS-based throttling from input source receiver loop#701
Conversation
The input source loop throttled frame reception based on pipeline FPS, creating a feedback loop: sleep(1/FPS) + receive_latency caused the effective input rate to always undershoot the target, driving FPS downward. For sources with non-trivial receive overhead (NDI, Syphon) this spiraled to ~5.6fps (v0.1.6) or ~2.8fps (v0.1.7). The v0.1.7 regression was caused by the batch-level FPS tracking (66e8d31) being more stable — the old per-frame jitter partially counteracted the spiral via temporary FPS overshoots. Now the loop receives as fast as the source provides, matching the WebRTC camera input path. Backpressure is handled by put_nowait() dropping frames when the queue is full. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> Signed-off-by: Rafał Leszko <[email protected]>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Comment Tip You can customize the high-level summary generated by CodeRabbit.Configure the |
🚀 fal.ai Preview Deployment
TestingConnect to this preview deployment by running this on your branch: 🧪 E2E tests will run automatically against this deployment. |
✅ E2E Tests passed
Test ArtifactsCheck the workflow run for screenshots. |
2 participants
The input source loop throttled frame reception based on pipeline FPS, creating a feedback loop: sleep(1/FPS) + receive_latency caused the effective input rate to always undershoot the target, driving FPS downward. For sources with non-trivial receive overhead (NDI, Syphon) this spiraled to ~5.6fps (v0.1.6) or ~2.8fps (v0.1.7). The v0.1.7 regression was caused by the batch-level FPS tracking (66e8d31) being more stable — the old per-frame jitter partially counteracted the spiral via temporary FPS overshoots.
Now the loop receives as fast as the source provides, matching the WebRTC camera input path. Backpressure is handled by put_nowait() dropping frames when the queue is full.