StreamDiffusion's IO queues decouple the input capture rate from the diffusion throughput via multiprocessing

Live sources (webcam, screen capture) produce frames at one rate; the diffusion pipeline consumes them at another, often slower, rate. Coupling them directly means the pipeline either blocks waiting for frames or drops outputs. StreamDiffusion decouples these with multiprocessing Queues: a capture thread appends PIL frames to a shared inputs list; an inference process drains it, batches a frame_buffer_size sample, and pushes output tensors to an output Queue; a viewer process reads from the output Queue and renders. This producer–consumer split keeps GPU saturated regardless of input jitter. The screen capture example (examples/screen/main.py) demonstrates all three processes spawned with ctx.get_context('spawn') for safe CUDA multi-process use.

Examples

# Inference process puts results:
queue.put(output_image, block=False)
# Viewer process reads:
if not queue.empty():
    image = queue.get(block=False)

Assessment

In the screen capture demo, what happens to output quality if the inputs list grows faster than frames are consumed? Identify which process owns the Queue and what block=False prevents.