[grytchat]

Second piece of sharing several windows at once (GRYT-1905), after Gryt-chat/sfu#67.

API. addScreenVideoTrack, removeScreenVideoTrack, addScreenAudioTrack and removeScreenAudioTrack take an optional window index. Index 0, the default, is exactly today's path, so the client keeps working unchanged until it passes an index.

Later windows

• Each gets its own video and audio sender in extraScreensRef.
• It publishes on an SFU slot with publishOnSfuSlot, and never on the camera's m-line. The SFU gates that slot on share_video, so a window there would need the wrong permission.
• With no free slot, the window waits. screenSlotsRef goes up to index + 1, and renegotiate now carries {"screens": n} once n > 1. A 250 ms timer retries the waiting windows once signalling is stable again, which is after the SFU's new offer has been answered.
• It asks once per new count. An SFU from before sfu#67 never adds the slot, so the window just waits, with no stream of renegotiate requests.

Send budget. VideoRole is "camera" | "screen" | screen:${n}``, and the controller keeps its roles in a map, so setVideoSendSettings("screen:1", …) gives a window its own quality. The budget treats every non-camera role as a share. `check-video-budget` asserts that a second window gets a share's cap.

What to look at

• The camera-slot guard in addExtraScreenTrack: it takes the first video m-line in the SFU's offer as the camera's.
• The waiting retry when the SFU never adds slots: the window stays waiting until removeScreen* or a disconnect clears it.

Not tested end to end. That needs sfu#67 running and a client that shares two windows, which comes next. typecheck, lint (0 errors) and every JS check pass after a build.

🤖 Generated with Claude Code