Support more than one receiver at a time

[nbkdoesntknowcoding]

Today

One receiver. A second is refused with busy, and the refusal is deliberate rather than a limitation nobody got around to.

It is enforced in WebSocketServer, and the reasons are structural:

• One encoder, one bitrate. AdaptiveBitrateController sets a single target from a single receiver's reports. Two receivers on different links have different answers and there is nowhere to put the second one.
• One send gate. SendGate bounds a single outstanding send. Its whole model is one socket that may be slow.
• Keyframe requests are global. Any receiver asking for an IDR gets one produced for everybody, so a receiver with a decode error costs every other receiver a bandwidth spike.

Why it is worth doing

The obvious case is a second monitor from a second laptop. The more interesting one is a demo: several people watching the same screen without a meeting tool in the middle.

The design question that decides everything

Simulcast or shared stream?

Shared stream — one encode, fanned out. Cheap on CPU, and the bitrate controller has to serve the worst link, so one bad Wi-Fi connection degrades everyone. The send gate becomes per-client, and a slow client must shed its own frames without holding the others.

Simulcast — an encoder per receiver, each with its own bitrate. Every receiver gets what its link can carry, at N times the encode cost. VideoToolbox will do several 1080p sessions on Apple Silicon, but "several" needs measuring rather than assuming, and the capture is shared so FrameQueue becomes one producer with many consumers.

There is a middle path — encode twice, at two rates, and put each client on whichever fits — which is what conferencing systems settle on and is more work than either extreme.

A proposal that picks one and says why is more valuable than a patch. Getting this wrong means either a stream that degrades to the worst viewer, or a Mac that gets hot serving three.

Also has to be answered

• Pairing. Each device pairs separately today, which already works; the PIN flow assumes one prompt at a time.
• Input. Two receivers both pressing F8 would both drive the Mac. Someone has to hold that token, and handing it over needs to be visible on both.
• The refusal must keep working. Whatever replaces the one-at-a-time rule, exceeding the new limit has to say so clearly — see fix: the receiver erased the one thing that explained the failure #70 for how badly that goes when the reason gets lost.