Raid Centre Opens the Door to a CRESA-Owned Web Source

Raid Centre Outgoing Presentation

Development on Raid Centre has continued beyond discovery, recommendations, history and raid execution, with work now focused heavily on the outgoing raid experience.

The goal has always been for an outgoing raid to feel like part of the stream rather than simply pressing a button and waiting for Twitch to take over.

CRESA's Full and Compact outgoing presentation modes are being designed around that idea. Full provides a dedicated MNV presentation before transitioning towards the destination, while Compact keeps the current stream visible and introduces the raid target alongside it.

Getting the destination channel itself into that presentation reliably, however, has turned out to be a much more interesting engineering problem than expected.

The Browser Source Problem

Our first approach used Twitch's official embedded player inside the existing browser-based presentation.

Technically, it works.

In practice, testing exposed several things outside CRESA's control, including advertising, mature-content prompts, authentication state and other Twitch-controlled player behaviour.

We then investigated whether an authenticated Twitch session could improve that experience.

That exposed another limitation.

OBS Browser Source has its own browser environment. A Twitch session in the user's normal browser cannot simply be carried across and treated as the same authenticated session. We also investigated using the browser environment available through OBS itself, but that did not give CRESA the level of lifecycle and session control we need.

For Raid Centre, we need to be able to control when the browser exists, when media is active, when it shuts down and, eventually, maintain an isolated authenticated Twitch session without leaving an unnecessary browser running in the background.

Trying to force the existing OBS Browser Source to behave differently was increasingly becoming the wrong solution.

So we started investigating whether CRESA could own the source instead.

CRESA Web Source

That investigation has now produced the first working prototype of a new CRESA-owned web source for OBS.

Rather than using OBS Browser Source, CRESA now has an experimental standalone Chromium/CEF runtime.

The browser itself runs outside OBS in a separate CRESA-owned helper process and renders its content off-screen. Those rendered frames are then transported back to the CRESA plugin and displayed through a custom source registered directly with OBS.

In simple terms, the current prototype looks like this:

CRESA Web Runtime → Chromium/CEF → Off-screen rendering → CRESA frame transport → CRESA Web Source → OBS

This is not a modified OBS Browser Source.

It is our own source using the public OBS source and graphics interfaces.

The first animated test surface is now successfully rendering inside OBS. The source can be added to a scene and manipulated on the OBS canvas like a normal source.

That is a significant first proof for the architecture.

Why Run the Browser Separately?

One of the important design decisions is that the Chromium runtime does not live directly inside the OBS process.

CRESA launches and owns a separate Web Runtime helper.

That separation is intentional.

As development continues, the browser runtime will be responsible for browser rendering, sessions and web media, while the native CRESA source is responsible for presenting the resulting video and audio to OBS.

It also gives us a much cleaner failure boundary. A problem inside the browser runtime should not mean taking OBS down with it.

There is still considerable testing and hardening required around that behaviour, but the architecture now exists rather than only being a design on paper.

What We're Working on Next

The current prototype proves the video path.

The next stage is browser audio.

CRESA needs browser-specific audio to travel alongside the rendered video and appear in OBS as audio belonging to the CRESA source itself. The intention is for it to behave like a normal OBS audio source, including the mixer, mute controls, volume, monitoring and filters, without relying on Desktop Audio or virtual audio devices.

Once the video and audio foundation has been proven, development can move onto the part that originally started this work: an isolated persistent Twitch viewer session.

That will allow us to investigate Twitch authentication inside CRESA's own browser environment rather than borrowing a session from Brave, Edge, Chrome or OBS Browser Source.

From there, we can test authenticated Twitch playback and determine how the new source behaves with real destination channels before connecting it back into Raid Centre's Full and Compact presentation modes.

Raid Centre itself is not using CRESA Web Source yet.

We are deliberately proving each layer before putting it anywhere near the production raid lifecycle.

Bigger Than Raid Centre?

Potentially.

This work exists because Raid Centre needed it, and delivering the outgoing raid presentation remains its immediate purpose.

But creating our own OBS source also opens an interesting longer-term direction for CRESA.

Today, many CRESA presentation features rely on individual OBS Browser Sources. If CRESA Web Source matures into a stable production component, future CRESA-managed web surfaces could potentially use the same technology.

That could give CRESA much greater control over source lifecycle, rendering, recovery and integration with OBS while reducing its dependency on manually configured Browser Sources.

We are not replacing existing Browser Sources today, and we are not committing to moving every web surface onto this system.

The prototype is far too early for that.

For now, CRESA Web Source has one job: prove that we can build the media foundation Raid Centre needs without compromising the presentation around limitations we cannot control.

The first major piece of that foundation is now working.

There is plenty still to build, but it is looking very promising.