PlayBridge: local-network casting where the phone browses and the TV plays

A six digit PIN, then a secure socket

Everything starts with both devices on the same local Wi-Fi network, which is stated as a requirement rather than a nicety: the sender, whether phone, desktop app, extension or CLI, and the receiver must share a network. Discovery then has two paths. Automatic discovery uses mDNS and UPnP, and the device chip in the app lists what it found. If a receiver is missing from that list, you type its IP address, which the receiver displays on its own home screen.

Pairing is the third path and the one with a security shape. On your first connection to a PlayBridge receiver, whether Android TV, Apple TV or the desktop app, a six digit PIN appears on the receiver screen. You enter it on the sender, and the connection is established over an encrypted WebSocket, described as wss in the documentation. Paired devices reconnect on later sessions without asking again.

That PIN flow is deliberately scoped. DLNA and UPnP televisions are discovered automatically on the local network and need no PIN at all, which is what keeps the no install promise intact for the largest number of screens.

DLNA televisions need nothing installed

The receiver list is deliberately heterogeneous, and the no install case is the one worth understanding first. Any DLNA-capable television works with nothing on it at all: the phone finds renderers on the network automatically and casts to them. That path bypasses PlayBridge's own player entirely, so it is also the path with the fewest features, but it is the one that works on a hotel television.

The richer receivers are the ones you install. Android TV and Fire TV get a dedicated TV Player, available in the Google Play store for Android TV in open testing, installable from the TV's own Downloader app with the code 9557748, or sideloaded from the tv-player APK on the releases page. Apple TV has no prebuilt binary: the instructions are to build and deploy from Xcode using the readme in the tv directory. The desktop receiver covers macOS, Windows and Linux with archives named by platform and extension.

An optional TV Browser APK extends the Android TV player with web browsing using GeckoView and uBlock Origin, which is a separate download rather than part of the player itself.

The TV app asks for overlay permission first

There is one permission prompt that surprises people, and the documentation explains it rather than leaving you to guess. On first launch the Android TV application asks for Display over other apps, and the stated reason is that the receiver needs it to come to the foreground when a cast arrives. Without it, a cast can arrive while something else is on screen and the player never appears.

On a television, that is a system level setting rather than a runtime dialog, so it is the kind of thing that gets declined once and then blamed on the sender later. Grant it before you test casting again.

Updates are handled in the same spirit of not leaving a sideloaded build to rot: the phone and TV applications can check for new releases and install updates from inside the app, so a build you sideloaded once does not have to be replaced by hand every time.

Apple TV is the one you have to build

Of the four receiver families, Apple TV is the outlier and the documentation does not hide it: there is no prebuilt binary yet, so you build and deploy from Xcode using the documentation in the tv directory. That is a different commitment level from tapping a store listing, and it is the reason to check which platform you own before reading further.

The desktop receiver is the opposite case, the most frictionless install of the non store options. You download the archive for your operating system from the releases page, with Windows as a zip, Linux as a tar.gz and macOS as a zip. Two platform notes come with it: Linux needs libmpv2 present, because the receiver path goes through mpv, and the macOS build is unsigned, so the first launch needs a right-click and Open rather than a double-click.

There is also a command line installer for the Rust tooling, one shell path and one PowerShell path:

curl -fsSL https://playbridge.app/install.sh | sh

Piping a remote script into a shell is the usual trade for a single command install, so the manual archives on the releases page remain available if you would rather inspect what you run.

Five senders, and they are not interchangeable

The sender side is where the differences are largest, and picking the wrong one is the most common way to conclude the suite is broken. The phone application for Android and iOS browses video sites in its built in ad blocked browser, casts from a Stremio library and its add-ons, loads IPTV playlists and streams local files. The desktop application is both a receiver and a sender: it plays incoming casts and can send local video by drag and drop or stream a URL to a television. The browser extension for Firefox and Chrome detects streams in active tabs and hands them to the desktop app, which means the desktop app has to be running. The Rust command line tool offers a full screen terminal dashboard, and it can also host a browser receiver or receive through mpv:

playbridge                         # Open the dashboard
playbridge discover                # Open dashboard discovery
playbridge send video.mp4          # Open Cast with media preselected
playbridge browser video.mp4       # Host and pair a browser receiver
playbridge receiver                # Start the mpv receiver in the dashboard

A fifth path is the DLNA television itself, which needs no sender application at all once the phone finds it.

Two stream proxies, one in the Rust workspace

The repository is multi language in a way that is easy to miss from the Kotlin primary language on the repository card. Android and television code sits under mobile and tv with gradle configuration at the root, desktop has its own directory, the browser extension and a web front end have theirs, and the Rust code occupies cli, cast, stream-proxy-rust and browser-receiver-rust. There is also a stream-proxy-dart directory, which is the interesting entry: the same proxy idea appears in two languages.

The Cargo workspace selects only the Rust side. Its members are cli, cast/core, cast/receiver, cast/ffi, stream-proxy-rust and browser-receiver-rust, with the resolver set to version 3 and a single excluded path, inspirations/mediaflow-proxy-light. So a Rust build of the workspace never touches the Dart proxy, and the Dart tree is built by its own toolchain.

The rest of the root is where the governance and the automation live: DESIGN.md, CONTRIBUTING.md, AGENTS.md, SECURITY.md, PRIVACY.md, THIRD_PARTY_LICENSES.md, plus scripts/, protocol/, shared/, packages/, prebuilt/ and third_party/. There are also two agent configuration directories, .agents/ and .jules/, which suggests the project drives its own development partly through agents.

Release tags are prefixed per platform

The tag names tell you the suite has more than one delivery cadence. The recent releases are desktop-v0.13.0, phone-v0.13.4 and phone-v0.13.3, so the desktop and the phone carry independent version lines with the same minor number, and the desktop line has fewer patches behind it than the phone line. A user on desktop and a user on a phone are therefore not necessarily running the same generation of the suite.

The install instructions lean on that structure too, linking to filtered views of the releases page for the phone APK, the TV player APK, the TV Browser APK and the desktop archives, each with its own release query. Filtering by tag prefix is doing the job that subdirectories would do in a single repository.

The alpha warning at the top of the README is the frame for all of this. It states that the project is under active early development and that bugs, incomplete features and breaking changes between releases should be expected, with feedback and issue reports welcomed. Given a cadence where the phone shipped two patches three days apart, treat the version you install as a snapshot rather than a stable base.

Editorial conclusion

PlayBridge suits a household where casting has to work without an account, without a vendor server and without installing anything on the television, and the DLNA path is the cheapest of the four. It does not suit anyone who needs reliability today, because the project labels itself alpha and expects breaking changes between releases. Before you commit, check which receiver you actually own: Android TV and Fire TV are in stores, desktop is downloadable, DLNA TVs need nothing, and Apple TV needs an Xcode build. Pair on the same network, keep the PIN flow in mind, and read PRIVACY.md before pointing the extension at private browsing sessions.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. playbridgeapp/playbridge on GitHub
3. Project website
4. README
5. Releases