Components

At runtime Selkies is a single Python application, the selkies wheel. The HTML5 web client is bundled into it, and screen and audio capture and encoding come from the pixelflux and pcmflux extensions, installed as dependencies of the wheel. Everything else on this page is optional: container images that carry a whole desktop, libraries that give a container's applications gamepads and a webcam, and the TURN pieces the opt-in WebRTC transport may need.

Refer to Getting Started on how you can get on board.

Core Components

Optional Components

Sealskin is a separate project of the same organization, an example of orchestrating these images one desktop container per user on a single server, with its own web, mobile and browser-extension clients; its documentation is at https://sealskin.selkies.io.

Container Images

Retrieve the latest SELKIES_VERSION release, and pick the DISTRIB_FLAVOR of the container images (ubuntu26.04 or debiantrixie). The flavor names the distribution inside the image, so it is a free choice and not a property of the host:

export SELKIES_VERSION="$(curl -fsSL "https://api.github.com/repos/selkies-project/selkies/releases/latest" | jq -r '.tag_name')"
export DISTRIB_FLAVOR="ubuntu26.04"

Every image is multi-architecture (x86_64 and aarch64). When instructed to install binfmt for building the other architecture, use the following command with Docker®/Podman:

docker run --rm --privileged tonistiigi/binfmt:latest --install all

Each release attaches, per flavor and architecture, the digest of every image, the digest of the distribution image it was built from, and the list of packages it holds, which is what a downstream qualification build pins.

Encoders and Interfaces

This section lists the encoders and interfaces that are actually implemented in the current runtime. The set of available video encoders depends on the transport mode.

Encoders

Video is encoded by pixelflux. SELKIES_ENCODER or --encoder= names the allowed encoders as a comma-separated list whose first item is the default, and a single value locks the choice; the dashboard chooses among them.

The dashboards list every encoder the server allows. One this browser cannot play on the transport (no WebCodecs decoder for its codec over WebSockets, no RTP receiver for it over WebRTC) stays in the menu disabled and marked as unsupported by the browser, so a missing H.265 or AV1 reads as the browser's limit rather than a server option left out; Chrome and Firefox on Linux, for one, decode no HEVC. A stream the browser cannot play at all, from an encoder the server holds, is reported on the page on both transports.

When a codec cannot be served as asked, whether the host has no encoder for it or the browser declines it, the session steps down one ladder on both transports: the codecs the host encodes in hardware, most efficient first (AV1, H.265, VP9, H.264, VP8), then the ones it encodes in software in order of encode time (H.264, AV1, VP8, H.265, VP9), then striped H.264, and JPEG last of all. Only the encoders the deployment allows are stepped to, and a single allowed value is held: a stream the browser cannot play is reported on the page rather than replaced.

WebSocket mode (default) — every encoder above is available. The full-frame encoders are decoded by WebCodecs in the browser; the striped encoders are decoded per stripe, jpeg without WebCodecs at all.

WebRTC mode (--mode=webrtc) — the same allowed set and dashboard choice drive both transports. WebRTC carries the full-frame encoders (h264enc, h265enc, vp8enc, vp9enc, av1enc), packetized by the vendored RTP stack (RFC 6184, RFC 7798, RFC 7741, RFC 9628, and the AV1 RTP payload format); the striped framings of h264enc-striped and jpeg are WebSocket-only, so in this mode the published menu is filtered to the five and either of those two falls back to the default with a logged warning; switching back to WebSockets restores the configured menu and value. The offer puts the display's codec first and the rest of the menu behind it down the ladder: a browser that declines the codec answers with the next one it decodes and the display moves to that encoder for every viewer, logged as a warning, unless the operator's menu holds the encoder, in which case that peer gets no video rather than another codec's bitstream; a live encoder change switches each peer's payload type to the codec it already negotiated, with no renegotiation. Which codecs a browser takes over WebRTC is the browser's own RTP receiver's business (its RTCRtpReceiver.getCapabilities, which the dashboards filter the menu by), not WebCodecs': Chromium and Firefox take VP8, VP9 and AV1 everywhere and H.265 only where the platform decodes it, Safari takes H.265 as well.

Full color (4:4:4 chroma, --video-fullcolor) is carried by H.264 and H.265 on NVENC, VA-API, x264 and x265, and by VP9 profile 1 on VA-API and libvpx. The server learns from pixelflux which of its encoders carry it on the host, and the browser tells the server which 4:4:4 profiles its decoder takes, so a full-color stream is only ever sent where both ends carry it; elsewhere the session streams 4:2:0 and says so.

Display Capture

Audio Encoder

Opus is currently the only adequate full-band audio codec supported in web browsers by specification.

Audio Capture

Client Uplinks

Both are off by default and need a secure context in the browser; see Usage.

Transport Protocols

Use --enable-dual-mode=true to let the client switch between the WebSocket and WebRTC transports from the UI.