streamlit-webrtc

Factory helpers like create_video_source_track(), create_audio_source_track(), create_video_sink_track(), create_audio_sink_track(), and create_pcm_audio_source_track() cache their objects in st.session_state using the provided key. This ensures tracks survive Streamlit reruns.

By default, these tracks are scoped to the active WebRTC session. When the session ends (e.g., user clicks STOP or closes the page), the object is stopped and removed from st.session_state.

To keep a track alive across multiple WebRTC sessions within the same Streamlit session, set lifecycle_scope="streamlit-session".

from streamlit_webrtc import create_video_source_track

# Default: scoped to the WebRTC session
video_track = create_video_source_track(
    callback=video_source_callback,
    key="video-source",
)

# Opt-out: survives multiple WebRTC sessions in the same Streamlit session
video_track = create_video_source_track(
    callback=video_source_callback,
    key="video-source",
    lifecycle_scope="streamlit-session",
)

The workflow operates in two distinct phases based on GitHub events:

1. Triage Phase (claude-issue-triage.yml)

Triggered by issues.opened. Claude analyzes the issue and performs one of the following:

• needs-info: Automatically applies this label if information (reproduction steps, environment, etc.) is missing. Claude posts a comment requesting the missing details.
• triaged: Automatically applies this label if the report is actionable. Claude posts a 3-5 line summary.
• out-of-scope: Automatically applies this label if the issue belongs to another project (e.g., Streamlit core, aiortc) or is a support question. Claude posts a redirection comment.

Note: Bot-authored issues are automatically skipped.

2. Implementation Phase (claude-issue-implement.yml)

Triggered by issues.labeled. This phase is driven by manual maintainer actions:

• ai-implement: When a maintainer applies the ai-implement label, Claude creates a branch (claude/issue-<number>), runs tests/linters, adds a changelog fragment, and opens a PR.
• wontfix: When a maintainer applies the wontfix label, Claude posts an explanation and closes the issue.

To read data generated inside a callback (e.g., processed images or analysis results) in the main Streamlit thread, you must handle thread-safety and polling.

Key requirements:

1. Thread-safety: Use threading.Lock to protect shared mutable objects (like a dictionary or queue) accessed by both the callback thread and the main thread.
2. Polling: Because the main script execution stops at the bottom while streaming, use a while ctx.state.playing: loop to continuously poll for updates from the callback.

import threading
import cv2
import streamlit as st
from matplotlib import pyplot as plt

from streamlit_webrtc import webrtc_streamer


lock = threading.Lock()
img_container = {"img": None}


def video_frame_callback(frame):
    img = frame.to_ndarray(format="bgr24")
    with lock:
        img_container["img"] = img

    return frame


ctx = webrtc_streamer(key="example", video_frame_callback=video_frame_callback)

fig_place = st.empty()
fig, ax = plt.subplots(1, 1)


while ctx.state.playing:
    with lock:
        img = img_container["img"]
    if img is None:
        continue
    gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
    ax.cla()
    ax.hist(gray.ravel(), 256, [0, 256])
    fig_place.pyplot(fig)

The webrtc_streamer() function manages the lifecycle of a WebRTC connection by coordinating five distinct concerns. Understanding this flow is helpful for debugging connection issues or lifecycle events:

1. Context Management: Retrieves or creates a WebRtcStreamerContext in st.session_state using the provided key.
2. Frontend Rendering: Renders the Streamlit component and wires up the on_change plumbing.
3. State Restoration: Restores the component value snapshot to ensure survivability across Streamlit rerun() calls.
4. Worker Lifecycle: Manages the WebRtcWorker (stopping on idle, creating on incoming offers, and flushing SDP answers).
5. Callback Updates: Forwards updated user-provided callbacks (like video_frame_callback) to the running worker.

If you encounter issues where the connection drops or state is lost during a rerun, the issue likely resides in the interaction between the State Restoration and Worker Lifecycle steps.

This workflow uses GitHub Actions and anthropics/claude-code-action to automate issue triage and implementation. To enable it, you must register an Anthropic API key, provision specific labels, and configure GitHub Actions permissions.

1. Register the Anthropic API key

Store your key as a repository secret:

1. Navigate to Settings → Secrets and variables → Actions.
2. Click New repository secret.
3. Name: ANTHROPIC_API_KEY.
4. Value: Your Anthropic console API key.

2. Provision Labels

Run the setup script to create the required labels idempotently:

bash scripts/setup-issue-labels.sh

3. Configure Action Permissions

To allow the ai-implement job to open Pull Requests, ensure the following settings are enabled in Settings → Actions → General → Workflow permissions:

• Read and write permissions must be selected.
• Allow GitHub Actions to create and approve pull requests must be enabled.