// the find
whitphx/streamlit-webrtc
Real-time video and audio processing on Streamlit
streamlit-webrtc puts a WebRTC peer connection inside a Streamlit component, letting you pipe webcam/mic frames through a Python callback with a few lines of code. It's aimed at data scientists and CV researchers who want to demo real-time inference without building a web server. The abstraction is genuinely well-designed for that use case.
The frame callback API is the right primitive — you get an av.VideoFrame, mutate it, return it, done. The threading model is honest about itself: the README explains exactly why st.* doesn't work in callbacks and shows the lock-based workaround rather than hiding the complexity. The lifecycle hooks (on_video_ended, factory track scoping with lifecycle_scope) show real attention to resource cleanup, which most similar components ignore entirely. Active maintenance with a CI pipeline, a test suite covering loopback and process paths, and a structured refactoring roadmap (the refactoring/ docs) — this isn't abandoned glue code.
Deployment is genuinely painful and the docs undersell it: STUN alone fails on Streamlit Community Cloud, so you need a paid TURN server (Twilio) before any public demo works, and the README buries this. The threading model leaks into every non-trivial app — users will write racy code before they read the lock section, and there's no guard against it. The API is explicitly unstable until v1.0, and the class-based API is deprecated but not yet removed, so the examples repo and StackOverflow are full of conflicting patterns. Streamlit's rerun-on-every-widget-change model fights WebRTC's stateful connection model at a fundamental level; you feel that friction as soon as you add more than one widget to an app that's streaming.