ScreenStream: Android Screen and Audio Streaming Without a Cloud Account

What ScreenStream Solves, and for Whom

The problem is mundane and recurring: you have an Android screen you want to look at from somewhere else, and you do not want to route it through a vendor account. ScreenStream renders the device screen as a stream and exposes it through three different delivery mechanisms, so the same app can serve a browser on the same Wi-Fi network, a remote viewer over WebRTC, or an RTSP client such as a media player or recorder.

The audience is narrow but real. Developers who need to watch a phone's screen while debugging on a second machine. People who want a phone camera or screen visible in OBS without a USB capture card. Anyone who wants a screen feed inside a network they control rather than a hosted service. The README frames the modes as independent, with different capabilities and restrictions, and that framing matters: this is not one product with three transports bolted on, it is three products sharing an app shell.

How the Three Modes Actually Differ

ScreenStream uses Android's MediaProjection API and requires Android 7.0 or higher. Above that shared capture layer, the modes diverge sharply.

Local mode (MJPEG) runs a built-in HTTP server and sends each frame as a separate JPEG image. Because frames are processed one at a time, the app can apply per-frame transformations such as cropping, resizing and rotating before the image reaches the browser. There is no audio, and protection is a 4 to 6 digit PIN rather than encryption. It works with no internet at all, over Wi-Fi, a device hotspot or USB tethering.

Global mode (WebRTC) connects the app to a public signaling service at screenstream.io and pairs it with the hosted ScreenStream Web Client. Audio is supported here, including microphone and internal device audio, and the connection is end-to-end encrypted with a password. It requires an internet connection. Both the signaling server and the web client are open source in the separate ScreenStreamWeb repository.

RTSP mode speaks RTSP/RTP over TCP or UDP with H.264 or H.265 video and OPUS, AAC or G.711 audio. It can run as a built-in server or as a client against an external server, and client mode supports RTSP authentication and RTSPS over TLS. The README notes that the Google Play build supports all three modes with ads, while the F-Droid builds are ad-free and support only Local mode (MJPEG) and RTSP mode.

Installing ScreenStream and Getting a First Frame

There is no build-from-source requirement for a first look. The README points to two distribution channels: Google Play for the full feature set, and F-Droid for an ad-free build limited to Local mode (MJPEG) and RTSP mode. The package identifier is info.dvkr.screenstream on both.

After installing, the first real use is Local mode, because it needs nothing beyond the phone and a browser. Start the stream in the app, then open the address the app displays from a device on the same network. The README describes clients connecting in a browser using the app address, with an optional 4 to 6 digit PIN. The README does not document the default port, so read the address off the app screen rather than guessing. If nothing loads, the README names two likely causes: some Wi-Fi networks isolate connected devices from each other, and some mobile carriers block incoming connections to your device.

Where ScreenStream Falls Short

The mode split is the main limitation, not a footnote. Local mode has no audio, and its PIN is protection rather than encryption, so anyone who can reach the HTTP port and knows or guesses the PIN can watch. If you need audio and you are on an isolated network with no internet, none of the three modes gives you both: Global mode carries audio but requires internet, and RTSP carries audio but needs a client or server to talk to.

Latency is explicitly conditional. The README states that latency depends on the selected mode, device performance and network conditions, and that RTSP and WebRTC are generally better suited to lower-latency streaming while Local mode prioritizes broad browser compatibility. Treat MJPEG as a compatibility choice, not a performance one.

Resource use scales with viewers in the browser modes. The README says the number of clients is not directly limited in Global mode (WebRTC) and Local mode (MJPEG), but each client consumes CPU and separate bandwidth. On mobile data, the warning about high traffic applies: streaming over 3G, 4G, 5G or LTE can consume a large amount of data. And a phone that is encoding and serving is a phone that is not doing much else.

RTSP Mode Against a Media Server Instead

The obvious alternative for many teams is not another Android app but a desktop capture stack: OBS with a capture card or a virtual display, feeding an RTSP or RTMP server. The difference in approach is where the work happens. ScreenStream encodes on the phone and, in RTSP client mode, pushes to an external server you already run, with RTSP authentication and RTSPS available. A desktop capture setup encodes on a machine that has more headroom, but it needs a physical or virtual path from the phone's screen to that machine.

If the phone is the thing being filmed, ScreenStream removes that path. If the content originates on a desktop anyway, ScreenStream adds a device and a network hop for no benefit. The README's own RTSP description is the honest boundary: server mode needs no internet, client mode depends on the network path to your server.

Maintenance, Licensing and Upgrade Cost

The repository is MIT licensed, which is permissive and places few obligations on reuse; the LICENSE file is at the root. The README also links PrivacyPolicy.md, SECURITY.md and TermsConditions.md, which are worth reading before deploying this in an organization, since the Global mode depends on a hosted signaling service at screenstream.io. Nothing here is legal advice; read the actual files.

The last push to the default branch was on 2026-09-28, and the most recent release listed is 4.4.2 from 2026-07-15, preceded by 4.4.1 and 4.4.0 in the same quarter. The project is not archived. Upgrading is an app install rather than a server migration, but note the distribution split: if you depend on Global mode (WebRTC), the F-Droid build will not give it to you, so an upgrade path that switches stores silently drops a mode.

Choosing a Mode Before You Install

Decide the transport first, because it determines the store. Need a browser view on a LAN with no internet and no audio: Local mode (MJPEG), available on both stores. Need audio and remote viewers and you accept a hosted signaling service: Global mode (WebRTC), Google Play only. Need to feed a player, recorder or media server with H.264 or H.265 and audio: RTSP mode, available on both stores, with client mode adding RTSP authentication and RTSPS.

Two checks are worth doing before you rely on it. Confirm the target device runs Android 7.0 or higher, since MediaProjection is the capture path. And confirm the network will let the client reach the phone at all, because the README calls out both client isolation on public or guest Wi-Fi and carrier blocking of incoming connections as reasons a connection can fail even when the address looks correct.

Editorial conclusion

Adopt ScreenStream if you need a browser-visible view of an Android screen on a LAN, or an RTSP feed from a phone into a player or media server, and you are willing to accept that Local mode is video-only and unencrypted. Do not adopt it if you need audio on a network with no internet access, because audio exists only in Global mode (WebRTC) and RTSP mode. Before committing, verify the Android version of your target device (7.0 or higher), whether your Wi-Fi network isolates clients, and whether your carrier allows incoming connections if you plan to view over mobile data.

Frequently asked questions

Official sources

1. dkrivoruchko/ScreenStream on GitHub
2. License: MIT
3. Project website
4. README
5. Releases