Repository navigation
A client can ask for a screen pair per window it shares (GRYT-1905) - #67
Merged
Merged
Conversation
…905)
renegotiate may carry {"screens": n}; the SFU adds receive-only video and audio pairs up to n,
at most 8, before re-offering. The added pairs answer to share_screen like the first.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First piece of sharing several windows at once (GRYT-1905). Forwarding is already dynamic: every track in a room gets its own
AddTrackon each subscriber. Ingest wasn't. Each peer got four receive-only transceivers at join (mic, camera, one screen video, one screen audio), and since the SFU makes every offer, a second window had no m-line to arrive on.What changes
renegotiatemay carry{"screens": n}. An emptydata, which today's clients send, behaves exactly as before.maxScreenShares). That isn't a product limit, it bounds what one client can make the SFU allocate. Each window costs the sender an encoder and upload long before it gets near 8.sync.Map, andslotOfreports them asslotScreenorslotScreenAudio. SorefusedBygates them onshare_screenlike the first pair, and never onshare_video. The entries are deleted when the peer is cleaned up.Where to look
slotOfinhandler_join.go: an extra receiver is recognised by registry lookup, not by position. Forwarded tracks share the same peer connection, so index alone can't say what a later transceiver is for.ensureScreenSlotsruns even while the peer isn't stable. The renegotiation is deferred as before, and the new transceivers ride along in the next offer.refusedByand its tests.Tests:
screenslots_test.gocovers a pair per window, no growth on a repeat or smaller request, the ceiling, the second window's video and audio gated onshare_screen, and cleanup.go test ./...passes.Not in this PR: the client side.
@gryt/voicestill has one screen sender, and the server and client still track one share per person. Those come next, and nothing sendsscreensuntil they land.🤖 Generated with Claude Code