FCast: an open casting protocol for audio and video

A protocol first, a set of reference implementations second

FCast is an open source protocol for wireless streaming of audio and video between devices, and the README is explicit about the order of priorities. The protocol supports several stream types, naming DASH, HLS and mp4, and it works on Linux, Windows, macOS and Android.

The interesting claim is about who can use it. The README contrasts FCast with proprietary protocols like Chromecast and AirPlay, and says FCast offers an open approach that lets third party developers create their own receiver devices or integrate the protocol into their own apps. Device discovery uses mDNS rather than a vendor cloud service, so the sender and receiver find each other on the local network.

That framing sets the audience. The people who benefit are developers writing a set top box, a media centre application or a screen mirroring tool, and who need a casting protocol they can implement and ship without a vendor agreement. The people who will be disappointed are those expecting a consumer app that replaces a Chromecast on their television, because the value here is in the implementation freedom, not in a polished end user product.

Sender discovers, launches, then controls playback

The protocol defines two roles. A sender is a device or application that discovers and communicates with a receiver, and it can be a terminal client or an Android application. A receiver is a software implementation that runs on Linux, Windows, macOS, Android and similar platforms, and it continuously sends updates about the current playback state back to the sender.

The interaction sequence is what most implementers need to get right. The sender connects to the receiver, launches the media, and the receiver starts playing it. Once the media is running, the sender keeps control: pause, resume, seek and volume adjustment are all sender driven operations.

So the receiver holds the playback position and the media pipeline, and the sender is a remote control plus a source of commands. The state feedback loop is the part that has to be reliable, since the sender's user interface reflects what the receiver is actually doing. The repository structure supports that split, with separate crates for the protocol itself, for receiver logic and for receiver user interface, and a mirrored crate set for senders.

The GitHub repository is a mirror, the GitLab tree is the source

This is the first thing to know before you plan any contribution. The repository description reads FCast Issue Tracker and Source Mirror, and the homepage recorded for the project is on gitlab.futo.org, under a videostreaming group path rather than on GitHub. So issues and pull requests handled on GitHub are not where the authoritative history lives.

The Cargo workspace makes the same point from the developer side, in a comment that describes what a plain cargo build or test at the root actually builds. The comment says the sender side is excluded, listing the senders, the sender SDK and its flutter plugin, plus the crates only they use, and it says the work here is receiver work while the sender tree is one cargo xtask test-sender away. Shared crates, named as fcast-protocol, sabrump and google-cast-protocol, stay in the default set because the receiver uses them.

Reading that comment as a project direction rather than a build optimisation, the project is currently weighted towards receivers. That is a reasonable place to be for a protocol whose point is receiver diversity, and it also tells you that contributing to the sender side takes more setup than a plain checkout.

A default build that covers receivers only

Because the README does not document an install procedure for end users, the practical entry point is the source tree and the workspace layout. The Cargo file lists every crate in the workspace, and separately declares a default member set that a root level cargo build, test or check will cover:

default-members = [
    "xtask",
    "crates/fcast-protocol",
    "crates/receiver-core",
    "crates/receiver-ui",
    "receivers/desktop",
    "crates/app-updater",
    "crates/google-cast-protocol",
    "crates/inhibit-screensaver",
    "crates/fcast-gst-elements",
    "crates/fcast-runtime",
    "crates/fcast-video",
    "fuzz",
    "crates/apple-fairplay",
]

The list is a map of the receiver side: the protocol crate, the receiver core and its UI, the desktop receiver, the app updater, GStreamer elements, the runtime and video crates, a fuzz target, and the Apple FairPlay module. A separate google-cast-protocol crate sits in the default set, which tells you the project works alongside Google's casting protocol rather than in isolation from it.

The rest of the workspace is reachable with -p or --workspace, and the comment in the Cargo file says so. Outside the default set you will find the terminal sender, the desktop sender, the Android sender, the sender SDK and a flutter plugin, an image viewer example, and a file server crate.

Senders, receivers and third party implementations

The README lists what exists today. On the receiver side there is an Android receiver and a desktop receiver, plus an experimental Android receiver in the workspace list. On the sender side there is a desktop sender for mirroring your screen or casting multimedia content, and a terminal sender that lets you use the FCast protocol over the command line interface. Grayjay, with its own Android and desktop applications, is a multi platform media application that can watch content from multiple platforms in one place, and it is listed as a sender.

The project actively wants more implementations, and it asks outside developers to build their own FCast compatible receivers and senders. What it asks in return is a naming discipline: third party applications are asked to read the trademark policy for guidance on naming, logo usage and attribution, and that file sits at the repository root next to the contribution guide.

That is a sensible arrangement for a protocol that wants to grow beyond one vendor, and it is also a real constraint for anyone planning to ship a commercial receiver under their own brand. The contribution process itself is documented in CONTRIBUTING.md, and general questions go to the FCast channel on the FUTO Chat Zulip server, not to a discussion board.

What is shipped, and what the repository does not tell you

The release list is narrow and informative. The tagged releases are desktop receiver builds: 3.0.4 on 2026-08-28, 3.0.3 on 2026-07-24 and 3.0.2 on 2026-06-17. There is no release line for the terminal sender, the Android apps or the SDK in that list, so if you need a prebuilt sender you are looking at the desktop receiver artifacts only.

The repository is not archived and the last push was on 2026-10-09, so the work is current. The licence is MIT, stated in the README and in the workspace package section of the Cargo file, which is the permissive end of the scale and lets you embed the protocol in a commercial receiver, subject to keeping the notice, and this is not legal advice.

What the README does not tell you is equally worth knowing. It does not document an installation procedure for end users, it does not give a build command for a specific target, and the product documentation for receivers, senders and the SDK is hosted separately at docs.fcast.org. So the repository is a development surface, not a manual, and a first time implementer should expect to read the external documentation and the crates themselves to learn the wire format details.

Editorial conclusion

Adopt FCast if you are building a receiver device or a media application and need a casting protocol you can implement yourself, since the protocol, the SDK and the Rust crates are published under the MIT licence. Do not adopt it as a consumer casting service, because the reader expects a shipping product rather than a protocol with a mirror repository and a separate GitLab source tree. Verify first where the code of record lives, because the GitHub repository is described as an issue tracker and source mirror with the homepage pointing at gitlab.futo.org, and check the sender side separately since the workspace excludes the sender tree from a default build.

Frequently asked questions

Official sources

1. futo-org/fcast on GitHub
2. License: MIT
3. Project website
4. README
5. Releases