stream_stats

What a controller's page is told about its stream, the same on both transports.

Two messages carry it. stream_info describes the path a display's capture took -- the capture backend and whether it is zero-copy, the encoder and whether it is hardware, the GPU behind it, and the reason a faster path was declined -- as pixelflux reports it (ScreenCapture.stream_info), plus gpu_present, whether the server is exposed a GPU at all, and hardware_expected, whether the session asked for hardware on a server that has one: a software session somebody chose, and one on a host with no GPU, which is an ordinary deployment, are told apart from one that fell back. It is sent once when the capture settles and again when it changes, since a session can demote itself mid-stream.

stream_stats carries the numbers that move: the host's CPU, memory, and GPU, the rate and cost of the encode, how long a frame took from its capture to the wire (send_ms, the delivery the encode figures cannot see: the event loop, the relay, the pacer), the rate the video was sent at and its peak against the CBR target, and over WebSockets the round trip and whether the server is holding frames back (a WebRTC page measures its own link). It flows only to a connection that asked for it (the _stats,1 verb a page sends while its stats are on screen, _stats,0 when they leave), so a session nobody inspects sends nothing periodic. A shared viewer is sent neither message.

A pixelflux build without the report leaves stream_info unsent and the encode figures out of stream_stats; nothing else depends on them.