ScreenBridge

A high-performance screen, window and game sharing application written in Rust.

Introduction

ScreenBridge shares a screen, a single application window, or a fullscreen game to any number of viewers in a browser, over a direct peer-to-peer WebRTC connection. Video is captured and colour-converted on the GPU, audio is scoped to whatever you picked, and neither ever touches an intermediate server in the happy path.

It is free and open-source, and by default it uses the public signalling server and browser viewer hosted by the Mira Screenshare project, so it works out of the box with no infrastructure of your own. No guarantee is made about the availability or performance of those public servers — you can point ScreenBridge at your own signaller and viewer at any time (see Configure).

At this stage we do not recommend it for sensitive or mission-critical use. Contributions are welcome.

Downloads

Download ScreenBridge 1.0.0 for Windows — grab ScreenBridge-1.0.0-windows-x86_64.zip from the releases page, unzip it anywhere, and run screenbridge.exe. The ffmpeg DLLs it needs are in the zip alongside it, so keep the folder together. No installer, nothing written outside the folder except config.toml, which is created next to the executable on first run.

macOS builds are not published yet — build from source for now.

Features

Pick any source, not just a monitor

• Share a whole screen, a single application window, or a borderless / fullscreen game
• Screens and windows appear in one flat dropdown, labelled Screen - … / App - exe - title
• Window titles are tidied for display: the repeated app-name prefix is dropped and glyphs the UI font cannot draw are stripped, so entries stay readable
• Shell noise (desktop, taskbar, wallpaper host, cloaked UWP shells, tool windows, minimised windows) is filtered out of the list
• Switch source mid-share — audio re-points to the new source's process while the WebRTC tracks and the encoder stay up

Audio that follows the source

• Sharing an application captures only that app and its child processes, via WASAPI process loopback on Windows
• Sharing a screen captures the whole system mix minus the apps you are in a call with — Discord, Teams, Zoom, Slack, Webex, Skype, Mumble, TeamSpeak, WhatsApp and more are excluded by default, and the list is configurable
• The UI states which of the two you are actually getting, including when per-app capture is unavailable and it has fallen back to system audio
• Opus at 48 kHz stereo, 10 ms frames, 96 kbps — set explicitly so game and music audio stay clean at low latency

Streaming

• Three stream modes: Video + Audio, Video only, Audio only
• Concurrent viewers, with separate pending and viewing lists — viewers are admitted, not auto-joined
• Room code, passcode, and a one-click invite link
• GPU NV12 colour conversion through D3D11 shaders, so the CPU only ever sees encoded frames
• x264 by default; NVENC, VP9 and anything else your ffmpeg build supports are one config file away

Platform

• Cross-platform: Windows (Windows.Graphics.Capture) and macOS (ScreenCaptureKit)
• Remote mouse and keyboard control is implemented but switched off — handing a viewer control of your input is too significant to be one CLI flag away, so it is gated behind a compile-time constant (REMOTE_CONTROL_ENABLED in src/capture/capturer.rs)

Performance

• 60 FPS encoding at 4K resolution
• ~110 ms end-to-end latency

Requirements

	Windows	macOS
Minimum OS	Windows 10 v1803	macOS 13.0
Capture API	Windows.Graphics.Capture	ScreenCaptureKit
Per-application audio	Build 20348 or newer; older builds fall back to whole-system audio	Scoped by the same content filter as the video

Technical Details

ScreenBridge is the sharer half of a three-part system built on the WebRTC stack:

• The sharer (this repository) captures the selected screen, window or game and streams it directly to the viewer(s) over a P2P connection.
  • If your network does not allow a direct P2P connection, a TURN server relays the data instead.
• The viewer is a browser client. It renders the stream and, when remote control is enabled, dispatches input events back to the sharer.
• The signalling server handles peer discovery and the initial connection negotiation. It never carries media.

By default ScreenBridge talks to the Mira Screenshare public signaller (wss://ws.mirashare.app) and viewer (https://mirashare.app/). Both are plain config values — swap in your own deployment and nothing else changes.

For encoding, x264 is used by default. Other codecs and encoder settings (quality, speed, compression) are configured in config.toml.

Build

You need ffmpeg installed.

• macOS: brew install ffmpeg@5 (later versions will not compile).
  • You also need cargo install apple-bindgen, then run apple-bindgen CoreFoundation --sdk macosx.
• Windows: download a shared library build of ffmpeg from BtbN/FFmpeg-Builds, such as ffmpeg-master-latest-win64-gpl-shared.zip. Put it under .\third_party\ffmpeg so you have e.g. .\third_party\ffmpeg\bin\ffmpeg.exe.

Then:

cargo run --release

On Windows the ffmpeg DLLs have to sit next to the binary at runtime, so copy them from the vendored build into the target directory you are running:

copy third_party\ffmpeg\bin\*.dll target\release\

Build scripts (Windows)

scripts/ wraps the above, including the DLL copy:

Script	Does
.\scripts\build-debug.ps1	Debug build, DLLs copied to target\debug\
.\scripts\build-release.ps1	Release build, DLLs copied to target\release\
.\scripts\build-dist.ps1	Release build, then packages dist\ScreenBridge-<version>-windows-x86_64.zip

All three check that the vendored ffmpeg is present and that the app is not already running — the linker cannot replace a binary that is open, and cargo's own error for it does not say so. build-dist takes the version from Cargo.toml, so bumping the manifest is enough to rename the artefact.

macOS bundle

make bundle-macos ARCH=aarch64-apple-darwin SIGNER=... KEYCHAIN_PROFILE=... FFMPEG_ENV_DIR=...

builds, bundles, signs and notarises ScreenBridge.app into a DMG.

Configure

Configuration lives in config.toml, created with defaults on first run.

• Windows: config.toml next to the executable
• macOS: ~/Library/Application Support/ScreenBridge/config.toml

Preset configurations for different encoders are in configs/ — libx264, libx264 (Windows), nvenc and vp9 — use one as a starting point. Pass a different file with --config <path>.

Notable keys:

Key	Purpose
signaller_url	Signalling server WebSocket URL
viewer_url	Base URL used to build invite links
max_fps	Capture / encode frame rate cap
ice_servers	STUN / TURN servers; credential_type = "Signaller" lets the signaller hand out TURN credentials
encoder	Encoder name, pixel format, WebRTC encoding and raw encoder options
audio_exclusions	Executables kept out of the mix when sharing a whole screen
discord_app_id	Discord application the Rich Presence is published as; empty switches the feature off

Discord Rich Presence

While a share is running, your Discord status shows what you are sharing and how many people are watching, with a Watch stream button that opens the invite link.

Whether it shows is a button in the app, not a config key — the eye icon next to Discord on the start screen, and on the live row while sharing. Flipping it mid-share takes the presence down or puts it back up immediately, without interrupting the stream. It starts on, and resets to on each launch.

Two things worth knowing:

• The button is only visible to other people — Discord never renders your own activity buttons, so checking your own profile will not show it.
• The link carries the room passcode, so anyone who can see your status can reach the room. They still land in the approval queue and cannot watch until you let them in. Switch the toggle off if you would rather not publish it at all.

Discord being closed is fine: presence retries quietly in the background and never affects the share. To disable it permanently, set discord_app_id = "", which also hides the toggle.

Q & A

Q. Can you see my screen?

No. In an ideal environment the media goes straight from the sharer to the viewer(s), and the signalling server is only involved in the initial negotiation. Even when a direct connection cannot be established and the data is relayed through a TURN server, it is encrypted by the WebRTC stack (SRTP).

If you would rather not rely on anyone else's infrastructure, host your own signalling and TURN servers and run the viewer from source.

Q. Is any data collected?

Not by ScreenBridge. The default public signalling server, operated by the Mira Screenshare project, collects some metrics such as session count/length and an estimate of unique users derived from a salted argon2 hash of the IP address. No personal data, and no access to the media between sharer and viewer.

License

GPLv3. See LICENSE.txt.

Files under src/capture/macos/ are additionally dual-licensed under MIT.

Rights & Attribution

ScreenBridge is based on Mira Screenshare, a high-performance screen-sharing project written in Rust and released under the GPLv3. All rights to that original work remain with the Mira Screen Share Team and its contributors: their copyright, their authorship and the terms they published under are unchanged, and continue to apply in full to everything ScreenBridge inherits from them.

All rights to ScreenBridge — this rebrand and the modifications, features and fixes that make it up — belong to Focsy.

Because the upstream project is GPLv3, ScreenBridge is GPLv3 as well: the source stays open, and any redistribution has to carry the same license along with these attributions.

Further attributions inherited from upstream:

• Some code is adapted from scrap, licensed under MIT.
• Some code is adapted from MirrorX, licensed under GPLv3.