Resizable Streams

Overview

A WebRTC/native server started with webrtc_resizable=True treats width / height as the maximum and takes the current resolution from each frame's dimensions. The SDK never resizes on its own: it delivers the client's validated request through on_resize_request and the application re-renders at the new size. SHM and CUDASHM behave this way always; RTSP never does. See the stream-messages skill for the message flow and the streaming-frames skill for the frame contract.

webrtc_fit_client=True delivers the resolution each connecting client requests through the same on_resize_request callback, so the first frame already matches it. On a non-resizable stream it instead becomes the fixed resolution, and the buffer rules below do not apply.

Buffer rules

With frame copying disabled the encoder registers the application's buffer directly, which imposes two rules:

• The buffer is a persistent allocation at the maximum size; each frame is a sub-region with the maximum pitch, so a resize never reallocates. The encoder may still read a slot after stream_video returns, so keep a small ring rather than rewriting the slot just submitted.
• The allocation is plain device memory (cudaMalloc / cudaMallocPitch). The encoder cannot register memory from a CUDA memory pool (cudaMallocAsync, Warp's default allocator); stream_video rejects such frames on a resizable stream with an explicit error. In Warp, allocate under wp.ScopedMempool(device, False).

Source: examples/python/app_stream/app_stream/frames.py snippets frame-ring and stage-frame

Register, debounce, clamp, apply