Skip to content

Stream modes and Cloud Studio

Pyre asks you two questions about how you broadcast, and never asks them twice. Where is your stream copied to each platform, and how is your picture put together. Both live in one card, and everything else in the product follows whatever that card resolves to.

Open Stream Manager and find the Live settings card. Its own first line calls itself “the single source of truth for your stream mode”, and names what follows it: Studio, the topbar Go Live button, and the Quick actions.

Fan-out, described in the card as where your stream is copied to each destination:

OptionWhat it means
Cloud relay (fan out to all platforms)You send one upload to Pyre, and Pyre’s relay copies it to every enabled destination
Local fan-out (this PC fans out)Your own machine sends a separate copy to every enabled destination

Mobile / compositing, described as how your program is composed before it goes out:

OptionWhat it means
Plain (no compositing)Nobody composites. What you send is what goes out
Desktop Studio (this PC composites)The managed OBS on your own computer builds the picture
Cloud Studio (GPU pod composites)A GPU machine Pyre provisions builds the picture

Under the two selects is a Resolved mode line, repeated as a badge in the card header. It is the answer, not a third choice: pick a pair and it names what you actually get.

The card locks while you are live. It says so, in as many words: Mode is locked while you’re live. End the stream to change it. Changing how a broadcast is produced halfway through a broadcast is not a thing Pyre pretends to offer.

In the desktop app there is only one select. The desktop always composites in its own managed OBS, so the compositing question has no honest answer there. The field is hidden, Plain is not offered, and the card asks only about fan-out. If your saved mode was Plain, the app tells you it is changing rather than quietly switching you.

Four pairs are worth picking on purpose. A fifth resolution exists and it means off.

Your computer does everything. It composites the picture, then sends a separate copy to Twitch, to YouTube, to Kick, to each destination you enabled. No video passes through Pyre at all in this mode: your machine is talking to the platforms directly.

The cost is your upstream. Three destinations means three uploads leaving your house, and your connection has to carry all of them at once.

Resolved mode reads Desktop Studio (this PC composites).

Your computer still composites, but it sends one upload, to Pyre’s relay, and the relay makes the copies. One stream leaves your house no matter how many platforms you are on. No GPU machine is involved: the relay is copying bytes, not re-encoding them.

Resolved mode reads Desktop Studio · Cloud relay.

A GPU machine Pyre provisions for your session builds the picture and publishes it, and the relay fans it out. Your machine sends its camera and its inputs up and otherwise does very little, which is the point: a laptop can produce a stream that laptop could not encode.

There is no Cloud Studio page and nothing to provision by hand. Picking it here is the whole setup.

Resolved mode reads Cloud Studio (GPU pod composites).

Nobody composites. Something that is not Pyre sends a finished picture to the relay, and the relay copies it to every enabled destination. That is the entire arrangement. It is the mode for a working OBS setup you have no intention of replacing, and it is also how a phone publishing straight up from the Pyre mobile app reaches your platforms, which is why the select is labelled Mobile / compositing.

Plain is never a dead end: with it resolved, the card grows a line pointing at where your ingest address and stream key live, which is Sources, under advanced ingest.

Resolved mode reads Plain (cloud relay, no compositing).

What you give up is everything that needs a Pyre studio in the path, and the clearest of those is Delay.

No relay and no compositing leaves nothing to send anywhere. It is a real resolution rather than an error, and the card names it plainly: IRL / Off (no relay, no compositing).

Local fan-out plus Cloud Studio is impossible, and Pyre says why rather than quietly doing something else. A GPU machine in Pyre’s cloud cannot hand its finished picture back to your PC for your PC to fan out; it publishes through the relay it is sitting next to. So the moment you select that pair, the card collapses to the nearest mode that works and prints the reason:

Cloud Studio requires the cloud relay, so it can’t run with local fan-out. Resolved to Cloud Studio.

You end up in Cloud Studio with the cloud relay, which is what you asked for minus the impossible half, and you are told that is what happened. A wrong mode chosen silently would be the worse outcome by a distance.

Cloud Studio can be engaged without you picking it

Section titled “Cloud Studio can be engaged without you picking it”

There is one route to a GPU pod that does not start in Live settings, and it is worth knowing about before it surprises you on a go-live.

Every destination starts locked to your canvas, showing Output: follows canvas. Unlock one and pin it to a different resolution, codec or frame rate, and your destinations now span more than one rendition. Over the cloud relay, something has to transcode the extra rendition, and the relay does not transcode. A GPU pod does.

The Destinations pane says this in the editor itself, the moment you unlock an output while the cloud relay is on:

Custom output over cloud relay is transcoded by Cloud Studio — going live with extra resolutions engages it. Choose "Follow canvas" to remove it.

If the combination is one the server will not accept, saving is refused in the same language:

Per-destination resolutions over cloud relay need Cloud Studio — enable it or remove the extra resolution.

And switching a destination on can be refused for the same reason: Enabling this destination needs Cloud Studio: its custom resolution adds a second rendition over the cloud relay.

So a stream you set to Desktop Studio with cloud relay can resolve to Cloud Studio anyway, because your destinations made it necessary. The Resolved mode line reflects that: it is derived from your destinations as well as your two selects. The way out is the way in, on Destinations: put every enabled destination back on Follow canvas and the pod is no longer needed.

A pod has to exist before it can composite, and provisioning takes a moment. The Go Live tile handles this by saying Waiting… instead of pretending, and a dialog titled Connecting to your cloud studio explains the wait:

Your destinations use multiple resolutions, so a cloud GPU is being prepared to transcode them. This usually takes one to three minutes — you will go live automatically the moment it is ready.

You are not stuck watching it. The buttons are Keep waiting and Cancel go-live, and pressing the tile again while it reads Waiting reopens that dialog rather than firing a second go-live. If no GPU has come free yet, the same dialog says so instead:

No cloud GPU is available right now — we keep retrying automatically. You can keep waiting or cancel the go-live.

When a pod genuinely cannot be had, the go-live stops with a modal titled Cloud studio unavailable:

Your destinations span more than one resolution or codec, which needs a cloud GPU pod to transcode the renditions — but none is available right now. Make your destinations use a single resolution/codec to stream locally, or try again later.

Its primary button is Adjust destinations, which takes you to the page where the problem is fixable, because a refusal that does not point anywhere is just a closed door.

Nothing, for the two things people expect to have to set up.

Your scenes. All of them are sent to the pod over its own control channel, and each is preloaded as a scene there, so switching between them mid stream is instant. There is no upload step, no export, no second copy to keep in sync. Two honest details: a scene with no camera in it gets a full frame camera rather than a black picture, and a source a machine in a data centre cannot possibly run, a camera plugged into your own PC, an OBS window or game capture, is dropped from the cloud copy of that scene instead of failing the whole go-live. You get the rest of the scene, with a camera in it, rather than an error.

Your music. On a cloud session the player runs on the pod and its sound is routed into the mix there. Nothing of yours has to stay open, and there are no manual steps. The one honest catch is that the sound is being made on our machine and not yours, so you will not hear it in your own headphones until audio monitoring is on, and Pyre can set that for you: it manages that studio, so it can change the setting without you opening anything.

A delay on a cloud session is held on the pod’s own disk, and the countdown card is rendered on the pod’s GPU rather than yours.