Screen sharing

Document: SPEC-023. Revision: 1.11. Date: 2026-11-03. Lifecycle: approved design under D-128–D-134; D-134 selects P-035 with game-audio capture initially on and delegates documented/tested engineering completion. Baseline: alpha.23, local commit c0fdcb5. Delivery: screen sharing shipped in alpha.24, preview fixes in alpha.25; D-144/D-145 Linux application sound shipped in alpha.27 under D-146. D-164 output-device sound ships in alpha.32. D-165 selects Quality up to 4K and per-share resolution/frame-rate ceilings in alpha.33. D-166 adds adaptive encoding, held-picture recovery and direct Start in alpha.36. Native/desktop fixtures pass; physical KDE audiovisual acceptance remains open.

Approved video-delivery successor — D-167

D-168/SPEC-024 revision 1.1 additionally supersedes the old native adaptation recovery/pressure counting and 250 ms held-status timing below. D-167 approves all recommendations in the video requirements audit. SPEC-024 is the authoritative scoped successor for presentation timing, native pre-SFU delivery improvements and the future managed profile. It supersedes mandatory microphone lockstep/150 ms microphone-relative drops, fixed 200 ms presentation residence, universal native/SFU enforcement equivalence and the requirement to copy native wire/queue/adaptation mechanisms into managed RTP. Existing screen-media/1 framing, native leases/policing and security remain active where SPEC-024 explicitly retains them. Managed SFU is not yet enabled. See SPEC-024.

Authority and scope

R-117–R-121 record the human's requested outcomes. D-129 selects channel-specific server-admin relay exceptions, optional application/system sound alongside microphone voice, and responsive voice taking priority when video cannot remain synchronized. D-130 selects a combined desktop view, microphone-only PTT and listener-configurable ducking of game sound to half volume during PTT or another participant's speech. D-134 selects the reviewed completion profile; its technical details below are recorded under the delegated implementation authority in SPEC-000.

D-134 subsequently selects the reviewed completion profile throughout this document and delegates codec, packet, clock, queue and related technical completion to implementation/testing. Platform/capacity facts still require validation. Game-audio capture starts on in the popup, superseding the earlier off recommendation; it remains optional, can be disabled before starting, and never bypasses explicit capture/source consent. The technical sections below complete the profile. Platform and capacity acceptance remain validation gates.

This document owns the shared screen-media contract and selected policy schema. SPEC-005 owns capture, chooser, presentation and playback responsibilities; SPEC-008 owns authoritative settings, grants and enforcement. SPEC-003 owns identity/encryption, SPEC-004 microphone/media semantics, SPEC-016 key lifetimes, SPEC-017 existing voice routing, SPEC-018 direct/group consent and lifecycle, and SPEC-022 ordinary-channel access. These boundaries continue to apply.

Confirmed scope includes ordinary channels and direct/ad hoc channels between users. Direct communication remains E2EE. Channel properties can allow or disallow screen sharing and set bitrate limits. This does not authorize webcam publication or replace the existing meeting restriction.

D-128 resolves the previously open direct-screen-sharing product scope in SPEC-001 and Q-24. The alpha.23 implementation still has no screen-sharing capability. SPEC-004's original V1 exclusion describes the earlier delivery profile; it does not veto this requested successor. Existing microphone PTT, mute, capture and 200 ms residence rules remain authoritative. D-129 expressly preserves responsive voice rather than expanding that bound to wait for video.

Confirmed bitrate semantics

• The host selects the normal maximum allowed bitrate for relayed screen traffic. A channel administrator can set a channel limit within that normal limit. Setting a higher channel relay limit requires host server-administrator authority.
• D-129 permits a server administrator to grant a channel-specific exception without raising the normal limit for other channels. The separate infrastructure safety ceiling still applies; an exception cannot make an unsupported configuration valid.
• On an eligible direct peer path, server/channel bitrate settings serve as defaults which the presenter may exceed to meet the chosen priorities. This exception concerns bitrate, not permission to publish, channel access, encryption, source consent, moderation or membership.
• The presenter can choose a preferred bitrate/limit in the sharing popup and see the relevant channel/server constraints.
• D-132 selects 8 Mbps for the normal server relay limit. D-133 selects a 4 Mbps initial client presentation limit, adapting downward with room for optional game audio and transport overhead, and sharing enabled on servers with channels inheriting.

Selected initial client rate — D-133

Start at 4 Mbps, reduced to any lower applicable inherited default/relay ceiling. Treat this as the presentation budget, with room reserved for optional presentation sound and the final profile's counted framing/transport overhead. The video encoder target must therefore be lower than the enforced combined budget. Adapt downward when the network or encoder cannot sustain it; do not increase the user's chosen limit automatically. A presenter may choose 2 Mbps to save bandwidth. Higher quality may use a larger explicitly selected budget within the applicable relay limit, or the permitted direct-path rules.

The recommendation behind D-133 assumes 720p gaming, particularly 60 fps. At the same codec/settings, 4 Mbps provides more encoding budget for motion and detail than 2 Mbps; perceived quality still depends on content, codec, hardware and latency settings. Amazon IVS's H.264 guidance lists up to 4.5 Mbps for 720p at 30 or 60 fps. That is external streaming guidance, not a guarantee for this application's codecs or latency profile. The local synthetic test exercises 2/4 Mbps requests but does not establish perceived gaming quality.

Selected completion of policy and accounting

Use decimal bit/s in storage/API and Mbps in the interface. A presentation budget covers the combined screen video and optional presentation audio, excluding separately reserved microphone voice. Multiple monitors share one composed-video budget; they cannot each claim the full rate. On the relay, sum all renditions uploaded for that presenter against the relay ingress presentation budget; count fan-out separately against aggregate egress. On direct paths, apply the selected presentation limit per recipient, with independent total sender-resource bounds. The presenter's explicit limit remains a limit, including on P2P; exceeding a server/channel default never authorizes exceeding the presenter's own chosen ceiling.

Let H be the infrastructure presentation ceiling, S the normal server relay ceiling and C the nullable channel override. The selected relay ceiling is min(H, C ?? S). The host validates C <= S for channel administrators; a server administrator may explicitly set C > S while C <= H. Represent and audit an approved exception so a later unrelated edit cannot accidentally create or erase one. A moderator can lower/remove an exception; any new value above the current server ceiling requires server authority. The channel exception is exact-scope and does not silently authorize descendants.

Lowering H clamps live exceptions before forwarding continues and exposes the reduced effective ceiling. Lowering S does not convert an ordinary override into a privileged exception: clamp unprivileged values, while explicitly authorized exceptions remain within H. Raises never increase a presenter's explicit chosen limit. The revision-checked persistence and UI acknowledgement contract is implemented by server/screen-policy.ts and the scoped settings endpoints.

Selected role mapping uses the existing host owner for server administration and existing admitted moderator/owner authority for channel settings. No new role or imported home-server privilege is implied. Direct/group creation does not grant server administration; their host policy applies even when the creator is an ordinary member. Direct/group creators cannot edit inherited host policy; presenters retain their own bitrate and intent controls.

Keep three quantities distinct: requested encoding rate, enforced presentation traffic rate, and aggregate infrastructure ingress/egress. An encoder bitrate hint alone is not hard enforcement. The protocol must define counted bytes, accounting windows/burst allowance, cryptographic/framing overhead, retransmission accounting and bounds for malicious senders. Fan-out charges every forwarded copy to aggregate egress even when the presenter uploads one copy. Numeric limits are not a claim about measured capacity.

Direct, relay and mixed delivery

Retain SPEC-017's eligibility matrix: public channels of either encryption mode and private server-readable channels remain relayed; private E2EE calls may use direct paths with both endpoints' permission. Respect the existing relay-only preference for the whole presentation so enabling screen sharing cannot unexpectedly disclose peer addresses. This extension of the voice preference requires an accurate UI label.

Classify the actual selected path. A TURN-relayed peer connection is relayed traffic, not a P2P exemption; unknown route type uses relay restrictions. Direct bitrate exemptions apply only to verified non-relay participant paths. Resource/decoder limits continue to apply on every path.

Mixed delivery may provide a higher-rate direct rendition and a capped relay rendition. Do not send excess bitrate to the relay during failover: activate the bounded rendition and revalidate current authority before delivery, or pause that delivery if no compatible rendition is available. Clear obsolete queued frames and reestablish decoder state with a suitable keyframe. Direct recovery may use the presenter's selected higher ceiling, within measured network/codec capacity. Neither route transition changes the capture source, publication permission or call identity.

The initial implementation uses separate direct and relay encodings when their limits differ. Do not promise one encoding for differently capable receivers. Audio has scheduling priority; a congested video recipient must not block other recipients or the microphone stream.

Capture and presentation intent

CONFIRMED D-128: the presenter receives a popup with All screens, One screen and One window, including selection of the relevant screen/window. It also offers Productivity apps / Games and videos, Quality / Speed, and a bitrate limit within the applicable route constraints. These are two independent intent choices, not a mandatory manual codec selector.

Selected flow: open the chooser from the active channel/call, display the destination and acting account, choose capture scope and intent, explicitly Start sharing, and obtain platform permission for the selected source(s) before publication. D-166 removes the separate mandatory preview confirmation; the picker preview or optional all-screen assembly preview remains available. Cancel releases any newly acquired capture tracks. Receiving a share does not enable a microphone. Text navigation and merely opening settings do not publish or move a call. Starting from another call must use the existing explicit call-movement flow.

The application popup cannot replace OS/browser permission UI. Never assume that a browser source hint selects a particular display or restricts the permission picker. Verify the granted source before publication and explain a mismatch. Do not silently replace a closed window with a display, include a newly attached monitor, or resume capture after permission loss/reconnect/account movement. Stop/reselect remains explicit. Share status and Stop stay visible while browsing other text, and changing the alpha.23 same-channel voice identity ends the old share before any new identity can publish.

CONFIRMED D-130/Q-65: All screens produces one combined desktop view, not separate viewer-selectable screen streams. Selected completion preserves the relative physical arrangement, orientation and aspect ratio of the explicitly granted displays, with pan/zoom at the receiver and a local preview/source count. Resolve mixed DPI, gaps, negative monitor coordinates and maximum composite dimensions in the capture profile. Do not add newly attached monitors without new consent. Partial permission grant must not be reported as sharing all screens. A source/size limit cannot silently omit a monitor while displaying All screens. One screen/window remains a single selected source.

Selected intent mapping:

Negotiate codecs against encoder/decoder availability and real-time performance, not only a preferred codec name. Hardware support is device-dependent. The selected profile probes AV1, VP9, VP8 and H.264; none is assumed available on every device or intrinsically best. Display the effective codec, rate, resolution, frame rate and route in details, with a concise reason for a constrained result. Codec changes must preserve E2EE and synchronization; absence of a compatible codec produces explicit unavailability, never plaintext fallback.

Audio and synchronization

D-167 supersedes D-129 microphone lockstep: synchronize video with optional application/system sound where available; microphone alignment is best effort and cannot alone pause a valid presentation. Preserve responsive independent voice. Moderator Mute for everyone continues to stop every audio role under D-019 while permitted video may continue.

CONFIRMED D-130/Q-66: PTT controls the microphone only. Explicitly enabled application/system sound can continue with PTT released. Starting screen sharing cannot silently unmute or enable microphone transmission. Application versus whole-system capture must be described accurately; never capture all system sound when only one application's sound was consented to. Avoid feeding received call audio back into the presentation. If the platform cannot isolate the requested source, offer an explicit supported alternative rather than relabeling a broader capture. This resolves SPEC-004's auxiliary-audio/PTT question for screen presentation only; participant-wide moderator mute still applies to every audio source.

Linux application sound — D-144/D-145

The Linux desktop adapter offers explicit Application sound checkboxes independently of the selected screen/window. D-145 requires mixing several applications, for example a game and a music player. List currently available playback streams using their application/stream names; the presenter selects one to eight streams, with no sound source selected automatically. Show that only selected streams are mixed. An application with multiple playback streams may appear more than once. Start playback and refresh if an application is absent. Window selection alone is not sound consent. D-164 adds an explicit Output devices mode alongside Applications (the initial mode). Output mode lists PipeWire Audio/Sink nodes by description/name, independent of application process identity. Select one to eight outputs or use Select all listed outputs when at most eight are listed. This is a fixed snapshot: do not automatically include new devices or follow a changed default. D-192 supersedes inclusion of own playback: share eligible application streams routed to the selected outputs, excluding Sloppy Voice's process tree. Explain that own-call and notification playback is excluded, and that unidentifiable streams cannot be safely included. Older unfiltered wrappers must show update guidance rather than claim exclusion. Do not mix application and output selections. Changing mode or refreshing clears selections; no choice persists. On older desktop adapters, explain that output capture requires a desktop update.

Use one native PipeWire input stream/helper per selected output stream, bound to the exact PipeWire instance and object serial. Never reconnect to a replacement stream, default output or microphone. In application mode, exclude Sloppy Voice's own process tree and streams whose process identity cannot be established. D-192 replaces raw sink-monitor capture with a filtered mix of identifiable application streams linked to the selected sink; it excludes own-process playback, never selects a microphone and never widens an application selection. Track routed playback changes without following a changed default or replacement output. Preserve original application playback. Create no virtual input/output device and do not change defaults, routing, volumes or system permissions. Native PipeWire and a session manager with stream-linking policy are runtime requirements. PulseAudio compatibility is needed for PulseAudio applications and Electron's existing playback, not for this native capture path itself. Missing support produces an actionable error without broader capture.

The selected service's main frame receives single-use sound selections valid for 60 seconds. Starting the group additionally consumes the explicit display-capture gesture/selection and a ten-second sound-consent window. Cancel/reset, loss of any selected video/audio source, navigation, renderer loss, suspend/lock, helper failure or stopping the share releases the entire capture group. Renderer renewal every second extends the group lease by five seconds; each helper independently expires after five seconds without a parent heartbeat or on stdin closure. Lease-expiry checks run once per second. Cancellation also revokes a pending native start before its capture identifier is returned. The main process uses a monotonic lease clock. No capture choice persists. The separately versioned desktop capability is applicationAudioVersion: 1; older wrappers retain video-only Linux behavior. List at most 128 choices per mode from a bounded helper inventory of 256 nodes of that mode. Output support is independently advertised as outputAudioVersion: 1 with outputAudioSources(), preserving applicationAudioVersion 1 and older renderer semantics. Helper --list-outputs / --capture-output accept only Audio/Sink nodes; existing flags accept only application playback nodes. Both use the same instance/serial validation, capture leases and PCM contract.

Adapter constants: request 48 kHz stereo with 10 ms PipeWire latency. Each helper writes a fixed 3856-byte local packet: SVAP, little-endian uint32 sequence, uint64 monotonic microsecond timestamp at the first sample, and 480 interleaved stereo float32 samples. Anchor the first sample to the callback's monotonic time minus the buffer duration, then advance by the 48 kHz sample count so callback jitter cannot create gaps in the mix. Re-anchor and discard a partial packet when the observed buffer time differs by more than 20 ms, including after a capture stall. Nonblocking output drops excess data rather than delaying the source. Retain at most one partially written packet so pipe/socket backpressure cannot corrupt framing; newer packets are dropped until its remaining bytes can be written. The main process caps parsing at 128 KiB per helper, queues at most four packets per source and permits one unacknowledged frame per source. Drop input older than 100 ms. None of these local PCM frames goes directly onto the network or into persistent logs/storage.

Map the helper clock to renderer performance time using the best of three IPC round trips, refusing initialization if the best exceeds 50 ms; map that time into the existing presentation AudioContext. The encoder worklet acknowledges each accepted/dropped source packet and bounds each source queue to ten packets. Preserve 10 ms sample continuity using the packet sequence (including gaps for dropped packets) while mapped timestamps remain within 20 ms; re-anchor beyond that bound. This removes render-block quantization jitter without accumulating stale audio. Align sources on that common timeline with a fixed 40 ms mixing allowance for direct application capture; D-192 output mixes advertise an 80 ms allowance including native collection, sum selected streams and clamp the stereo output to [-1,1]. Missing/late source samples are silence; never replay backlog. Encode the combined 20 ms frames with their capture timestamps through the existing Opus, authorization, encryption, bitrate and listener-ducking path. PTT still gates only microphone audio. Normal capture adds no microphone delay or server/protocol permission. These are bounded adapter constants, not persisted settings or a measured end-to-end latency promise.

Validate capture/exclusion and cleanup in a private PipeWire graph with generated game, music, call and unrelated-app tones, then exercise the real Electron bridge and Opus encode/decode. Physical KDE/game and 60-second audiovisual acceptance remain separate evidence. The considered virtual-device bridge was rejected because a session manager could select it as a default microphone; the implemented path exposes no such device.

Listener-side game-sound ducking

CONFIRMED R-121/D-130: while PTT is held or another participant is talking, shared game sound defaults to half volume; the receiver/listener can configure that behavior in their own settings. Ducking applies locally to received presentation audio. It does not attenuate microphone voice, change the published stream, alter another listener's gain, or replace self/moderator mute. The request does not authorize changing an unrelated game's volume on the listener's operating system.

The selected trigger profile interprets held PTT as the listener's own accepted shortcut or Click to talk hold in the active call. Include local voice-activation transmission and an authorized remote microphone talkspurt that the listener can hear. Exclude muted/expired remote sources and presentation audio itself, so loud game sound cannot trigger its own ducking. Remote speech is identified through actual authenticated microphone playout; silent remote PTT does not trigger ducking. Never add a new speech-upload or recording service.

The implemented policy primitive represents half volume as a 0.5 gain multiplier (approximately -6.02 dB, a half-amplitude control value rather than a claim of half perceived loudness). The listener interface exposes an enabled switch and a Volume while talking percentage, default 50%. Use one ducking envelope for any number of simultaneous speakers: two speakers still produce 50%, not 25%. Retain the normal gain separately; changing it while ducked must restore the new value after speech. User/moderator mute remains zero throughout, and ducking never unmutes audio. Selected ramps reach the ducked gain within 20 ms and restore normal gain over 250 ms after the last trigger, without delaying samples or disturbing presentation synchronization. D-134 selects these ramp values.

Synchronization timing

Historical D-134 timing below is superseded by SPEC-024/D-167 for current presentation delivery. The independent presentation timeline and role-specific targets in SPEC-024 are authoritative.

Selected timing contract: capture microphone, video and presentation sound against one monotonic presenter timeline, or explicitly map their clocks into it. Authenticate timestamps, stream roles, presentation IDs and epochs. Receivers map that timeline to the local audio clock, compensate drift and schedule corresponding media by presentation time. Arrival order and starting two HTML elements together do not establish synchronization. PTT silence does not reset the timeline, and audio duplication through voice and presentation paths is prohibited.

Do not hold microphone audio beyond SPEC-004's 200 ms residence cap or expand its target just to wait for screen video. This is a receiver residence limit, not an end-to-end latency promise. Drop obsolete frames, lower video load, and show video paused when live synchronization cannot be maintained. A paused still image must be labeled as paused, not counted as synchronized moving video. Playback may resume only with valid authority, a decodable current frame and an acceptable clock estimate; authority/source loss still requires explicit restart.

Selected synchronization target: absolute audio/video presentation skew at most 80 ms for at least 95% of paired active-output observations over a specified 60-second clean fixture; never present a moving frame more than 150 ms from the corresponding audio timeline. D-134 selects these validation targets and runtime bounds; passing them still requires measurement. Fixtures must identify clean/impaired network, hardware, frame rate, frame sampling, startup exclusions, pause accounting, maximum continuous violation and drift. Report pause duration and dropped frames separately so a permanently paused stream cannot pass. No all-network synchronization guarantee is claimed.

Alternatives considered

The following feasibility judgments are design assessments. D-131 subsequently selects encoded video beside the existing voice transport, with a bounded prototype to complete its technical profile. Other approaches remain comparison context.

D-131 authorizes proving the second approach, while treating native multi-source capture as a separable platform adapter. If it cannot meet required interoperability, CPU or synchronization bounds, return to review with measurements instead of silently replacing the existing voice contract. The prototype record owns isolated fixture configuration and its evidence; fixture rates are not server defaults.

Platform evidence and protocol prerequisites

Official documentation checked on 2026-10-22:

• The W3C Screen Capture draft specifies one video track per getDisplayMedia result, user-selected sources and non-persistent capture permission; requesting audio does not guarantee an audio track. A combined logical display is possible, but arbitrary multi-monitor enumeration/capture is not guaranteed by one call. This is API evidence, not a supported-browser matrix.
• Electron desktopCapturer documents a single returned source on Linux/PipeWire. The native ScreenCast portal provides a multiple selection option and returns selected streams. Therefore a native portal adapter is a candidate for multi-source capture; compositor behavior still needs measurement. Repository Electron is pinned to 44.9.0; the retrieved latest documentation alone does not prove that exact build's behavior.
• The W3C content-hint draft distinguishes text/detail and motion intent. Hints inform media handling; they do not guarantee a particular codec, hardware encoder or result.
• WebCodecs encoder configuration provides codec, bitrate and latency controls. Capability probes and real encode/decode tests remain required; an API-defined option is not proof that a platform supports it.

The versioned profile below covers capability discovery; create/start/stop/subscribe transitions; authenticated call/account/device/presentation/track/epoch binding; common timestamps and clock mapping; codec descriptions and renegotiation; E2EE key separation, nonce uniqueness and rotation; replay across direct/relay copies; bounded fragmentation/reassembly, frame/track/decoder-memory limits and keyframe requests; grants, media-role revocation and rate enforcement; errors, migration and old-client refusal. Do not advertise the new capability on alpha.23.

The shared SCTP association permits 16,384-byte messages for the separate screen channel. The existing voice-fanout/1 handler retains its 4096-byte packet limit and only supports the bounded audio profile; its per-channel validation and quotas must not be bypassed to accommodate video. Existing 600-message/524288-byte per-second voice ingress limits are not a video capacity commitment. A separately bounded video profile must reserve voice capacity and retain independent relay enforcement for relayed media. Reuse reviewed identity/key-lifetime principles without reusing cryptographic nonces or treating a voice grant as permission for screen publication. Source titles/previews, captured content, keys, SDP and network addresses do not belong in diagnostic logs.

Screen-media wire primitives — D-134 engineering completion

The new unordered, zero-retransmission data-channel profile is screen-media/1; it is separate from the existing voice data channel and its quotas. Every binary chunk begins with magic SVS1, a big-endian uint16 canonical-JSON header length and uint16 payload length, then the UTF-8 header, a 64-byte Ed25519 signature, and raw payload bytes. The signature covers the exact canonical header bytes concatenated with payload. Reject noncanonical headers, unknown/missing fields and invalid UTF-8 before accepting a chunk. Limits are 16,384 bytes per message, 2,048 header bytes, 8,192 plaintext bytes per chunk and 1,048,576 plaintext bytes per encoded frame. Ciphertext adds the 16-byte authentication tag. Binary transport avoids base64 expansion of large media payloads.

The header contains exactly profile, serverId, room, domain, account, source, session, revision, sequence, presentation, role, rendition, codec, timestamp, keyframe, width, height, frame, part, parts, total, and encryption; encrypted chunks also have key and nonce. IDs bind the host, call, approved device, attendance and publication. sequence is monotonic per publication across media roles/renditions; frame identifies an encoded frame within its role/rendition. Both are nonnegative safe integers. timestamp is an authenticated capture time in microseconds on the presenter's continuous call timeline, unaffected by PTT release, in the range 0–9,007,199,254,740,991. revision is the current positive call revision. part is zero-based; parts equals ceil(total/8192); each payload has the exact implied length. Width/height are positive integers up to 8192 for video, with at most 8,294,400 output pixels, and zero for sound. Role is video or audio; rendition is direct or relay. Screen output is bounded to 60 fps by the sender/decoder profile; actual resolution/rate adapts to resources and budget.

Video codec identifiers are vp8, vp09.00.10.08, av01.0.08M.08 and avc1.42001f, subject to real encoder/decoder negotiation. H.264 uses Annex B with in-band parameter sets at random-access frames. Presentation sound uses opus, one independent 20 ms packet, at most 1275 bytes, 48 kHz stereo. Audio chunks use zero dimensions, keyframe: true, one part and one packet per frame. This defines interoperability candidates; a platform only advertises codecs actually available to it.

For E2EE, derive a 32-byte role/publication-specific key with libsodium's keyed BLAKE2b generic hash of UTF-8 sloppy-screen-media/1/{presentation}/{role}, keyed by the current ephemeral voice sender secret. The screen profile does not use the voice AEAD key directly. The key ID refers to the current SPEC-016 sender-key offer and shares its retirement/deadline; key derivation cannot extend that lifetime. Use fresh random 24-byte XChaCha20-Poly1305 nonces per chunk, carried as canonical base64url nonce. AEAD additional data is the entire canonical header including key ID and nonce. Sign header plus encrypted payload with the approved device signing key. Server-readable mode carries signed plaintext with no key/nonce fields. The reference browser client uses its initialized libsodium verifier for per-chunk Ed25519 verification to avoid slower JavaScript verification on the UI thread. The shared verifier retains a reference implementation for protocol/interoperability tests; verifier failure rejects the chunk. Every receiver checks signature, current source/own authority, publication role, identity/call context, key deadline and replay before assembly or decode. Sharing cannot fall back from E2EE to plaintext.

Relay uploads use SVU1, a uint8 recipient count (1–9), that many 16-byte UUIDs, then one SVS1 chunk. Reject duplicate/self/invalid targets and oversized uploads. The relay verifies the sender context/signature and independent screen-publication grant, then checks current recipient authority before forwarding the same inner packet. Only relay renditions may traverse the relay. Direct connections carry the inner packet unchanged, require existing private-E2EE/both-endpoint consent and verified non-relay candidates, and cannot bypass publication permission. Route-neutral replay state spans both delivery paths; at most 2048 accepted sequence numbers are retained per publication.

Reassembly admits at most four incomplete frames and 200 ms lifetime per sender publication, with no extension by duplicates. Reject mismatched metadata and conflicting fragments; evict expired state and release it on authority/key/publication changes. Validate each authenticated fragment before allocating assembly storage. Completed frames preserve their original timestamp; late or undecodable data never enters the render queue. Decoder scheduling, grants and sender congestion bounds are defined below.

The additive host capability screenMedia.frameOrder:"video-sequence/1" permits new publications to include the optional immutable frameOrder:"video-sequence/1" marker. With this marker, the authenticated header's frame is a contiguous zero-based encoded-video counter per publication/rendition, independent of presentation sound and the other rendition. Allocate a number for every encoded output, including output discarded before sending; do not restart it on codec reconfiguration. Packet sequence retains its existing publication-wide replay semantics. The server validates and projects the marker with the publication; relay grant and binary formats are unchanged. Old publications omit it and retain legacy frame-ID semantics. Updated presenters omit it against a host without the capability, and updated receivers use dependency ordering only for marked publications; older receivers can still decode marked frames using the existing payload/header contract.

For marked video, reorder completed authenticated frames by this counter before decoding. Retain at most twelve completed encoded frames and 2 MiB per viewer, with a fixed 40 ms missing-frame allowance that later arrivals cannot extend. Presentation sound never enters this queue. A missing predecessor, queue overflow or decoder-input drop invalidates the dependent chain: discard its queued encoded/decoded output, close that decoder, and require a complete fresh keyframe. A newer keyframe may recover immediately, retaining later queued frames that can follow it. Codec/geometry/rendition transitions require a keyframe and start a separate order context; obsolete earlier timestamps cannot restore a prior decoder or reanchor the playback clock. Output/error callbacks from replaced decoders cannot affect the replacement. Completed-video residence remains bounded to 200 ms across ordering, decode and render, and existing microphone-master lateness rules still apply. These fixed engineering bounds complete D-134's loss/recovery profile; they add no persisted preference or authority extension.

For budget accounting, charge each serialized message plus 160 bytes per started 1000 message bytes as a conservative transport allowance. This is an explicit accounting unit, not a measurement of physical IP/TURN/TCP traffic; actual connection statistics remain separately reported. Token buckets refill by monotonic elapsed time with a 250 ms burst capacity, never reset by a setting increase or publication restart within the same attendance. Per-presenter combined video/sound ingress, aggregate ingress and every forwarded egress copy are independently metered. An encoder's bitrate hint cannot replace these checks. Invalid input attempts consume input budget before parsing/signature work. Video queues and send backpressure are separately bounded so voice capacity is reserved; no generic voice quota is raised.

D-192 filtered output engineering bounds

The Linux helper observes direct PipeWire application-to-selected-sink links and creates passive monitor streams for those applications. Include newly started or moved eligible applications only while linked to that exact consented output; remove them on unlink/exit. The selected output's removal or instance/serial replacement stops capture. Preserve the original output-device selection limit (eight); each output has at most 32 concurrent eligible streams, 256 observed nodes and 1024 links. Exceeding a graph/capture bound fails explicitly rather than silently omitting audio. The helper mixes stereo float32/48 kHz into 10 ms packets, clamps peaks to [-1,1], retains at most 16 packets of mix state, targets 40 ms collection latency, advertises a total 80 ms renderer mix allowance and drops old backlog after scheduling gaps. No microphone, virtual sink, route/default/volume change or raw-monitor fallback. Indirect effects/virtual-routing paths are excluded and disclosed. These are fixed engineering bounds rather than settings. Desktop preload advertises outputAudioExclusionVersion: 1 only with this helper; renderer requires it in addition to outputAudioVersion: 1 for output mode.

Tests use isolated PipeWire generated tones to verify selected games retained, own-process and other-output exclusion, starts/stops/moves, stable routing, bounded backlog and explicit output loss. Physical desktop audio quality remains a separate listening check.

Configuration

D-165 adds client-local, per-share resolution ("auto", 720, 1080, 1440, 2160) and frameRate ("auto", 15, 30, 60) preferences, both initially "auto". They reset when opening a new share and apply at Start sharing; they are not persisted or transmitted as server policy. Automatic follows the intent profile below; explicit selections override its geometry/fps defaults, within the same protocol and bitrate bounds. Existing servers/receivers use unchanged publication and packet contracts. Invalid local choices reject starting capture publication.

D-144’s Linux adapter constants and runtime dependencies are defined in Linux application sound above. They add no persisted user setting or server override; sound remains initially enabled under D-134 and selection remains explicit per share.

Administrative protocol — D-134 engineering completion

Host screen settings use a separate version-1 meta/server-screen-policy record with version: 1, nonnegative revision, booleans allowed and audioAllowed, and positive safe-integer relayMaxBps. Defaults are the approved enabled/enabled/8 Mbps values and revision zero. GET /api/server/screen-settings is host-owner-only. POST accepts exactly {revision,changes}; changes are a nonempty subset of the three settings, omission preserves, and null is invalid. Require the current revision, this host's owner identity/domain/role and a requested rate no higher than infrastructure. Increment revision atomically and invalidate affected live room authority through the existing enforcement mechanism.

Channel records use kind screen-channel-policy, room ID as key, version 1 and revision zero initially. allowed, audioAllowed and relayMaxBps default to null/inherit. Stored exception is false initially and is derived by the host only when committing a rate: a value above the normal server rate requires the host owner and sets it true. Clients cannot submit this flag. Other setting edits preserve it; resetting/lowering the rate updates it. GET/POST /api/rooms/{room}/screen/settings require existing room visibility/admission; POST additionally requires existing host channel-settings authority and {revision,changes}. Direct/ad hoc calls and thread calls cannot write their own overrides. The normal channel's own record is the only override; thread calls read the parent record and direct/group calls read host defaults. Both host and channel changes create a bounded-retention audit record with actor, scope, values and whether an exception was granted, without captured source information.

An absent record applies the approved defaults, including to existing schema-9 channels; no admission/encryption data is rewritten and no capture starts. Unknown versions, fields or malformed stored values fail closed. This additive versioned record format leaves the existing database schema at 9. Read projection clamps infrastructure reductions immediately and clamps non-exception channel rates when the normal server rate falls; recorded owner exceptions survive within infrastructure. Configuration updates are authenticated/revision checked even when no publication is active. A settings API does not advertise working capture or forwarding.

Control and native media processes accept optional decimal integer deployment variables SCREEN_RELAY_INFRASTRUCTURE_MAX_BPS, SCREEN_RELAY_AGGREGATE_INGRESS_BPS, SCREEN_RELAY_AGGREGATE_EGRESS_BPS, defaulting to the approved 16/64/512 Mbps. Values must be positive safe integers no greater than 1,000,000,000 bit/s; ingress must cover the per-presenter infrastructure ceiling and egress must cover ingress. Omission uses defaults; null, empty, malformed or fractional values fail startup. These are non-secret startup settings, with no channel override. SCREEN_LIMITS also fixes the selected initial two-presenter/eight-source limits for this implementation profile. Native forwarding enforces equivalent or stricter local limits; Cloudflare media containers receive these values and include them in their generation configuration; deployment values alone establish no capacity claim.

Implemented policy primitives

shared/screen-policy.ts implements the approved, transport-independent subset under R-117–R-121/D-128–D-133. It does not itself advertise a capability, persist settings or authorize capture; SCREEN_LIMITS contains the D-134 deployment defaults. SCREEN_DEFAULTS contains serverAllowed: true, serverRelayMaxBps: 8000000, clientPreferredMaxBps: 4000000 and duckedVolumePercent: 50. These fixed initial values implement the confirmed defaults; the administrator/presenter/listener can change their applicable runtime setting through the integrated settings and share controls.

Rates accepted by these primitives are positive safe-integer decimal bit/s; zero, negative, fractional, nonfinite and unsafe values are rejected. A nullable channel rate/permission represents inheritance. All infrastructure limits supplied to the functions are mandatory validated inputs from the caller; these functions do not invent an operator default. Administrative authorization must come from authenticated host authority, never a submitted client flag. validateChannelScreenRate rejects any requested value beyond the supplied infrastructure ceiling and requires server administration above the normal server rate. Null restores inheritance. It only validates a proposed change; the host must separately authenticate the actor and commit it atomically.

screenRelayCeiling takes an already-authorized effective channel override and bounds it by the infrastructure maximum; it does not validate an exception's provenance or settle revision/migration behavior. screenAllowed combines a server boolean and an effective channel boolean/null, with a server disable remaining mandatory. The caller is responsible for any organizational inheritance; the host implements the selected independent host-to-channel hierarchy. initialScreenBitrate uses the lower of the confirmed client default and effective initial policy rate. screenBitrateForRoute respects an explicit personal limit, clamps relay/unknown routes to the relay ceiling, and allows a verified direct route to use the personal limit. Network adaptation can choose less. This is policy calculation, not byte-rate enforcement or independent proof of a direct route.

presentationDuckingMultiplier supplies only the approved local gain arithmetic. An active trigger applies the selected integer percentage from 0 through 100 (default 50); inactive/disabled ducking yields 1, and mute yields 0. All inputs are validated. Multiple speakers must first be combined into one active trigger, so attenuation is applied once. Trigger detection, gain ramps and persistence are implemented separately from this pure function.

Full integration inventory

This is the canonical screen-policy inventory. The selected logical properties map to the implementation names documented below. D-130 confirms the half-volume ducking outcome; D-132/D-133 confirm normal server/client rates and enabled/inherited sharing. D-134 selects the remaining defaults below. In the selected profile, server administrative policy is persisted at the host and changed through authenticated revision-checked commands. Creation omission uses the selected default; update omission preserves. Nullable channel overrides use null for inheritance, never zero/unlimited. Reject unknown names, invalid types, nonfinite/negative rates and unauthorized privilege changes. Numeric ranges, wire names and persistence are defined by the selected policy and protocol sections. No screen setting is secret; capture grants and media secrets remain ephemeral authority/state.

Capture source, active tracks, preview, negotiated codec, applied rate, route, current authority, clock estimate and synchronization state are operational state, not configuration defaults. Decoder safety bounds, interoperability codecs, timestamp format, sync thresholds and rate-window constants require a selected protocol profile. D-165 supersedes the initial 1080p Quality ceiling: Automatic resolution preserves native source/composite size up to 3840 × 2160 for Quality, while Speed retains the existing 720-pixel height / 3840-pixel width bounds. Automatic frame rate remains 60 fps for motion and 15 fps for productivity. Explicit resolution ceilings fit within 1280 × 720, 1920 × 1080, 2560 × 1440 or 3840 × 2160; explicit frame-rate ceilings are 15, 30 or 60 fps. Preserve aspect ratio, round down to even dimensions, do not upscale, and enforce existing pixel/bitrate/queue bounds. These are ceilings, not guaranteed throughput; HDR and physical platform quality remain unvalidated. Existing channels/accounts must retain access and encryption during migration. D-133 selects enabled/inherited sharing; migration implementation must apply those defaults without changing admission or starting capture.

Selected completion profile

D-134 selects the infrastructure/aggregate and presenter/source defaults in the inventory above. These are initial administrative/resource limits for validation, not claims about measured native-relay capacity. If load tests cannot sustain them while preserving voice, report the failed limit for review before release. Do not advertise them as supported merely because configuration accepts them.

For ordinary channels, inherit screen policy from the host independently at every nesting depth; keep server-admin exceptions exact-channel. Thread calls use their parent channel's screen policy. Direct/ad hoc calls inherit their hosting server's policy; initiating a call does not grant administrative settings authority. The creator/presenter can lower their own presentation limit and may use the confirmed direct-path bitrate exemption. This completes media-policy scope without changing SPEC-022 admission permissions.

Presentation sound is allowed unless administratively disabled, and D-134 selects its capture toggle on for each new share. Capture scope/audio consent never persists. Content/optimization intent resets for each new share; the selected initial intent is Productivity/Quality. Each new share starts with the confirmed initial bitrate constrained by current policy, so an earlier above-default P2P choice does not silently become the next session's rate. The listener's ducking preference is per local account/device. Its default is enabled at 50%, triggered by local held PTT/local microphone activation or audible remote microphone activity; silent remote PTT and presentation sound do not trigger it. Ramps are as described in the audio section.

The selected engineering completion keeps the current voice transport/security contracts and private-direct eligibility, completes the separately versioned screen protocol, selects codecs by actual capability/performance, and uses the stated 80/150 ms synchronization targets with pause/drop accounting. Platform capture support must be established per adapter, including native multi-source support where browser APIs cannot supply All screens. No unimplemented source/audio option may be reported as functioning. Exact packet, rate-window, clock, keyframe, decoder and geometry bounds must be documented and tested before dependent integration. D-134 delegates this technical completion under SPEC-000.

Publication and receiver authority — D-134 engineering completion

The scoped POST /screen/publish endpoint accepts Start as exactly {voiceId, action:"start", publication} with publication {id, preferredMaxBps, includeAudio, content, priority} and optional negotiated frameOrder:"video-sequence/1". The UUID is fresh for each explicit capture action. Preferences use integer bit/s (1–128,000,000), boolean audio, productivity|motion and quality|speed. The 128 Mbps direct safety bound is a client/protocol resource bound, not permission to relay above policy. Start requires admitted, current-device voice authority, sharing permission, permitted requested audio and a free presenter slot. Above-relay preferences require private encrypted direct eligibility and the presenter's explicit direct-routing consent. Identical repeats are idempotent; a different active publication must stop first. Stop is exactly {voiceId, action:"stop", id} and cannot stop another publication.

Voice lease renewal optionally carries screen:{codecs,watch,publication}. codecs contains at most the four selected video codec identifiers without duplicates and advertises verified decoding capability; a listener need not have an encoder for a codec it can receive. Presenters separately probe their actual encoder configuration against the common receiving capabilities; watch contains at most two current other-publication UUIDs in the same call; publication is the acknowledged own UUID or null. A listener explicitly chooses Watch for each new publication. Omission clears publication/subscription authority while preserving ordinary voice compatibility. The client serializes publication start/stop with complete voice-renewal handling, including relay acknowledgement and state application, so an in-flight pre-publication lease cannot revoke a newly acknowledged share. A publication UUID enters lease requests only after its explicit start is acknowledged. Screen authority inherits the existing three-second lease and four-second hard revocation boundary. State polling never renews it. Loss of authority stops capture and clears receiver queues; restarting requires another explicit capture action.

The signed native relay grant includes optional screen:{profile:"screen-media/1",publication,limitBps,audio,watch,ingressBps,egressBps}. Empty publication means receive-only. limitBps is the lesser of personal preference and effective relay policy. Audio permission independently respects participant-wide mute; video is not microphone publication. Every forwarded chunk rechecks current sender/receiver call, revision, expiry, subscription and role. Native deployment limits bound signed aggregate grants independently. Tokens cannot override local infrastructure limits.

Capture, scheduling and compatibility profile

The client advertises screen-media/1 and voice-clock/1; updated servers require voice-clock/1 at voice preparation/join/renewal so all admitted microphone sources supply the shared timeline. Older clients receive an explicit refresh-required response. Updated clients omit the new microphone timestamp and screen lease when talking to a server without the capability, retaining its earlier voice protocol. Alpha.23 deployment does not advertise screen sharing.

Microphone frames add authenticated mediaTime (integer microseconds at the first captured sample) to the existing envelope; the voice packet limit, jitter handling and 200 ms residence bound remain unchanged. Video capture is timestamped against that microphone AudioContext; presentation sound maps its separate 48 kHz context into the same timeline. Receiver microphone playout maps presenter time onto actual output time with getOutputTimestamp, including device output latency. During microphone gaps of at least 500 ms, presentation sound follows a stable arrival-based mapping; its own scheduling delays must not feed back into that mapping. Faster arrivals can shorten it; arrivals more than 40 ms past their target reanchor after a slower route change. Without an audio anchor, start with an 80 ms arrival-based target and reset stale estimates after five seconds; this fallback is not independent proof of audiovisual synchronization. Schedule presentation audio against the audible output clock, avoiding repeated addition of device latency.

Decode at most 60 video frames/s with a 15-frame burst and at most three pending decode operations. Retain at most twelve decoded frames and 192 MiB of RGBA-equivalent output per watched publication; reject output beyond the protocol dimensions. These checks bound application queues, not codec-internal allocations before a decoded output callback. Retain completed video for at most 200 ms, drop frames more than 150 ms late, allow at most 8 ms early scheduling, and, under D-166, retain the last good displayed picture after 250 ms without new video, labelled as a held frame while adapting. This static picture may outlive moving-video timing bounds only while its sharing authority remains valid; authority loss, source end and Stop watching clear it. The client watches at most two publications. A delayed render tick draws only the newest eligible due frame, closes superseded frames, and retains future frames within the same deadlines. Preserve same-size canvas backing stores and avoid canvas clears during ordinary timing/dependency recovery; never relax authority or moving-frame timing to hide a stall. Decoder changes require a keyframe; send recovery/periodic keyframes at least once per second while encoding. Probe all common codecs in intent order with prefer-hardware before trying the same order with no-preference, at the actual dimensions/rate. Preserve the chosen acceleration preference during bitrate backoff. These are WebCodecs hints, not proof of GPU use or real-time capacity; software fallback remains available.

Sender encoding queues contain at most two pending frames. The combined outgoing application queue is bounded to 2 MiB with 150 ms residence; direct paths never fall through to relay with their existing packet. Yield between outgoing chunks so a fragmented keyframe cannot flood the native relay's downstream buffer in one task. SCTP screen buffers are capped at 32 KiB and pending microphone traffic takes priority. D-166 adaptation reduces actual spatial resolution, cadence and encoder bitrate under send/budget failures, expired outgoing video, encoder backlog/latency, decoder overload, late video or sustained missing-frame recovery. Drop before encoding where possible so omitted capture frames do not break codec dependencies. Lost encoded dependencies still require a fresh keyframe. Never raise the chosen ceiling. Presentation audio is decoded in timestamp order, bounded to ten queued 20 ms packets and 200 ms residence, and stops at its independent authority deadline.

Source geometry must be finite: each source has one live video track, dimensions 1–32768 and coordinates within ±65536. Encoding preserves the composite aspect ratio with even dimensions, maximum width 3840 and the selected height/pixel ceilings. Native Windows source inventory supplies desktop coordinates; browser/manual capture requires the user to authorize each display and set its count/relative positions. The client refuses incomplete or oversized selections, and stops every track if any selected source ends. It does not claim automatic detection of every physical screen in browser/manual mode.

Electron source selection is explicit, main-frame/origin checked, single-use and short-lived. Windows can request optional whole-system loopback; the popup describes that scope and warns that it can include call audio. Windows application-specific exclusion/echo isolation remains unimplemented. Linux wrappers before D-144 are video-only and require disabling sound; the new native application-stream adapter is specified in Linux application sound above and requires an updated desktop package. It does not enable whole-system loopback. Real KDE/Windows capture and exact platform source/audio behavior remain acceptance gaps, distinct from synthetic browser tests.

D-166 adaptive completion and direct start

These are fixed engineering rules, not persisted preferences. Each relay/direct rendition has independent local pressure, combined with the highest current trusted target feedback level. Levels 0–6 apply spatial factors 0.8^level, cadence factors 0.75^level (floor 3 fps, never above the chosen cadence) and video bitrate factors 0.7^level below the existing 65% target after audio reservation. Preserve aspect ratio, even dimensions and all policy ceilings. Three pressure observations raise a level at most once per second; twenty seconds without pressure lowers one level. Recreating an encoder preserves its adaptation/budget and starts with a keyframe. Stale encoded output over 150 ms and dependent deltas after a sender-side loss are discarded until a fresh keyframe. Expired presentation-audio packets do not request a video keyframe. Pending encode input is bounded; skipped capture work does not consume video sequence numbers. Viewer feedback ages with existing voice authority; it conveys no permission.

Hosts advertise video-adaptation/1 as screenMedia.adaptation and a public capability. Only then may clients add optional feedback to the screen lease: at most two exact {presentation, level, keyframe} objects for distinct entries in their watch list; level is integer 0–6, keyframe boolean. The host filters feedback to currently permitted watched publications, projects it in scoped participant voice state and removes it on omission, unwatch or revoked policy. No media grant/packet change. Publishers consider only current authorized trusted targets for that rendition; feedback is advisory and cannot increase any rate ceiling. Recovery keyframe requests are limited to one per 500 ms. No extra polling: feedback uses existing authenticated renewal. Legacy hosts/leases remain compatible.

A brief dependency gap requests a replacement keyframe without treating that isolated event as overload. A receiver with no video progress for 750 ms adds pressure no more than once per second. Successful fresh display ends the held-picture status; recovery does not blank a valid previous picture. Diagnostic adaptation counters remain bounded numeric aggregates under SPEC-021.

Start sharing directly acquires a selected native source or opens the browser's system picker and publishes after successful explicit selection. The existing picker thumbnail/live selection is sufficient; no mandatory Preview selected source action or second confirmation. The popup retains optional live previews for multi-screen assembly, source reset and all intent/rate controls. All screens still requires every source to be explicitly authorized before Start; failures/cancelled pickers never publish and cleanup releases partial capture. Screen/application/output-audio scopes and grants remain unchanged.

Testing

D-192 filtered-output failure integration uses a disposable private PipeWire graph and generated application audio. tests/audit-output-monitor.mjs forces actual per-monitor ERROR and unexpected UNCONNECTED callbacks while the consented output and eligible applications remain live; capture must fail visibly, release all monitors and cease successful PCM framing. Intentional unlink, return to the selected output, application exit, empty-output silence and parent EOF retain their existing lifecycle. This integration evidence is separate from unit coverage, physical audio acceptance and dependency leak analysis. No runtime injection setting is introduced.

D-166 units cover independent adaptation, sustained pressure, bounded levels, slow recovery, even geometry and ceiling preservation, exact bounded feedback validation and legacy omission. Service tests verify feedback scope, filtering, omission and policy revocation. Browser fixtures exercise sender overload and receiver feedback, held pixel persistence through timing/dependency recovery, fresh-frame resumption, and clearing on authority loss. Dialog tests require direct Start without Preview, cancellation cleanup, retry and explicit all-source assembly.

Frame-order units cover reordering, complete/fragment loss, keyframe jumps, reordered periodic keyframes, stale input, fixed deadlines, frame/byte bounds and clearing on permission loss. Real VP8 browser fixtures at 1280 × 720 and 15 fps verify Chromium-encoded video through production Chromium/Firefox receivers with reversed fragments, reordered complete frames, a completely lost frame and a missing fragment. Assert decoder submission order, fresh decoder/keyframe recovery, correct rendered color samples, no stale-frame clock shift and no decoder errors. These software fixtures do not establish physical NVIDIA/Firefox driver performance. Server tests cover the additive capability, marked publication projection, legacy omission and rejection of unknown markers.

D-165 units cover every resolution/fps choice, automatic Quality/Speed and content defaults, aspect preservation, no upscaling and invalid choices. Browser tests verify a 4K synthetic source at actual encoded dimensions and rendered receiver pixels. Receiver authority regressions cover expiry, recovery status and membership-revision replacement without iterating a mutating map indefinitely. Codec cleanup tolerates already-closed WebCodecs instances, including capture-track release after encoder failure. Permission loss discards queued/decoded video and requires a fresh keyframe; renewed permission must not retain a stale permission-paused label.

D-144 adds Linux fixtures for exact application capture, exclusion of call/other-app tones, multiple explicit source selections, process-tree filtering, stale instance/serial rejection, no default microphone/output substitution, unchanged output routing, helper/renderer lease expiry, cancellation and native capture cleanup. Desktop units cover single-use consent, origin/frame checks and races; the real Electron fixture validates bounded PCM delivery and mixed game/music Opus output.

The local application validation record maps the automated evidence and remaining platform/capacity gates to R-117–R-121/A-49.

Document checks verify status labels, requirements, decision sources, component ownership, supersession, section structure and links. The isolated feasibility record reports five transport unit tests and ten synthetic browser cases. Experimental fixtures are not imported by the application; production integration tests exercise separately implemented capture, relay enforcement and rendered media; the prototype remains isolated evidence.

tests/screen-policy.test.ts covers the implemented policy primitives: selected initial defaults, explicit false versus inheritance, server disable precedence, administrative exception boundaries, required infrastructure input validation, lower initial policy rates, personal-limit preservation, actual-direct versus relay/unknown classification, malformed values, default half-volume and configurable ducking with mute precedence. It does not claim host authorization, rate enforcement or audible playback validation.

Focused browser regression verifies one paint for several due frames, preservation of future frames, closure of discarded frames, no same-size canvas resets, one clear per timing pause and fresh-frame recovery. Bounded aggregate screen diagnostics follow SPEC-021.

Required unit coverage covers policy precedence/exception authorization, stale revisions, lowered server/infrastructure limits, malformed and inherited settings, per-presenter combined-screen accounting, mixed-route classification, fallback before forwarding, bitrate burst enforcement, per-viewer backpressure, codec selection/failure, capture lifecycle/races and source loss. Timing units use deterministic clocks to test capture/clock mapping, drift, PTT gaps, late frames, pause/recovery, bounded memory and voice residence. Security units cover track-role substitution, replay, fragmentation attacks, expired authority, key rotation/removal and no screen-grant escalation from voice authority.

Ducking units test default 0.5 gain, user-selected percentages including 0/100, disabled state, shortcut/Click to talk holds, remote speech, overlapping speakers without compounded reduction, attack/release boundaries, no self-trigger from game sound, mute precedence and normal-gain changes during ducking. Integration uses two listeners with different preferences to verify independent rendered output, unchanged sender packets, uninterrupted optional sound between PTT holds and no extra audio delay.

Integration tests require two authorities; ordinary public/private and direct/group calls; all-direct, all-relayed and mixed recipients; actual encrypted rendered video/audio rather than packet arrival alone; source cancellation/closure, permission loss, channel denial, moderator all-audio mute and same-channel alpha.23 identity movement. Force high-rate direct-to-relay fallback and prove no over-limit traffic is forwarded. Test several screen tracks against the combined budget and aggregate relay egress.

Platform acceptance requires actual KDE Wayland/Windows capture and optional sound on the exact release builds, plus each claimed web/browser mode. All screens must show every explicitly authorized source with no unintended display/window/audio. Use paired audiovisual fixtures and report skew, dropped/paused video, voice latency, CPU/memory and route byte counts. Mocked capture and latest API docs do not establish physical-platform acceptance. GNOME/macOS retain their existing delivery status; any unavailable required platform feature remains a visible gap.

Acceptance criteria

• A filtered application monitor failing asynchronously while its eligible playback remains on the selected output stops the owning sound capture with actionable guidance and releases its monitors; it cannot continue as silent success or broaden capture. Intentional unlink/application exit remains a normal contribution removal.

• D-166: actual encoded dimensions, cadence and bitrate decrease under sustained local or viewer pressure and recover gradually within selected ceilings. Voice timing/authority bounds remain enforced.
• Ordinary timing drops and keyframe recovery retain the last good authorized picture with an explicit held-frame status; expired/revoked sources and Stop watching clear it.
• Start sharing needs no mandatory preview action; picker cancellation never publishes, and all-source/audio consent remains explicit.

• D-165: the presenter can choose Automatic or 720p/1080p/1440p/4K and Automatic or 15/30/60 fps; Quality Automatic can encode a 3840 × 2160 source without downscaling. Explicit lower ceilings preserve aspect ratio and never increase smaller sources. Applied dimensions/fps remain visible and bitrate limits remain enforced.
• A watched presentation survives a renewed call revision without hanging the renderer; expired grants clear video, and valid renewed grants show waiting-for-keyframe or Live rather than a stale permission warning.

• D-144: explicitly selected Linux game and music streams reach combined presentation audio while received call audio and other application streams are absent; source loss/cancellation releases the native capture group without changing normal output or capturing a substitute.

• R-117: permitted ordinary-channel and accepted direct/group participants can explicitly start, receive and stop screen sharing; denied/stale permissions fail on the server and every conforming route.
• R-118: a channel administrator cannot raise relayed bitrate above the normal server ceiling; a server administrator can grant an audited exact-channel exception within the infrastructure ceiling, without changing other channels.
• Direct paths can exceed advisory server/channel bitrate defaults only through the presenter's choice; relayed and mixed delivery obey their effective ceilings, including the first forwarded packet after fallback.
• R-119: the popup offers all screens as one combined desktop, one screen, one window, both intent selectors and bitrate control; the granted sources and effective constraints are visible, and cancellation/source loss never captures a substitute.
• R-120: microphone and optional presentation sound remain associated with the correct presenter and synchronized video; voice retains the existing 200 ms residence bound, and delayed video degrades/pauses visibly under the selected tested thresholds.
• Moderator mute silences every audio role while preserving video permission; PTT release silences the microphone while explicitly enabled presentation sound continues.
• R-121: a listener hears shared game sound at half its normal volume during the selected PTT/speech triggers by default, can change/disable that attenuation, and observes restoration to their current normal volume afterward. A second listener's settings/output and microphone voice remain independent; simultaneous speakers do not multiply attenuation.
• Multiple sources cannot bypass a per-presenter rate budget; relay fan-out and aggregate egress are measured separately from encoder bitrate and single-copy upload.
• Source/account/call changes, revocation, key expiry and old-client incompatibility cannot expose content, reuse stale authority or automatically restart capture.
• Configuration defaults, protocol safety limits, supported capture/codec matrix and relevant OPEN choices are resolved before runtime completion; future release evidence distinguishes automated, physical, cross-network and deployment results.

D-164 output-capture validation

Configuration: output mode is opt-in, no selected outputs by default, one to eight fixed devices, no saved choice. Existing application capture constants and server permissions apply.

Testing: cover separate source classes, mode-specific capture flags, stale selections, output removal and instance changes, multi-source cleanup and legacy capability handling. An isolated PipeWire graph must demonstrate whole-output capture of multiple application tones, exclusion of another output, unchanged routing and rejection of microphone/application nodes in output mode.

Acceptance criteria:

• Presenter can select a named output or all listed outputs within the eight-source limit.
• Output scope and call-echo warning are visible before capture; application mode retains own-call exclusion.
• Source loss stops capture without changing devices or capturing a microphone.
• Selection refresh/mode changes cannot reuse an earlier mode’s tokens or widen consent.