CRESA Web Source coming along slowly!

CRESA Web Source: From Prototype to Live Twitch Playback

Development of CRESA Web Source has reached one of its biggest milestones so far. What originally began as an experiment to give CRESA its own browser-powered source inside OBS has now successfully reached the point where a real live Twitch stream can play directly through CRESA Web Source. Getting there, however, turned into a much bigger engineering journey than simply putting a web page inside OBS.

The long-term goal for CRESA Web Source is to provide a foundation for browser-powered parts of CRESA, including presentation surfaces, alerts and eventually experiences such as the outgoing Raid Centre presentation. Rather than asking streamers to manually create and manage a collection of Browser Sources, the idea is for CRESA to own and manage the surfaces it needs while still presenting them to the streamer as normal CRESA sources inside OBS.

Building Our Own Browser Runtime

The first version took the most direct approach: CRESA had its own standalone CEF browser runtime.

This worked surprisingly well as an initial prototype. CRESA Web Source appeared as a genuine source inside OBS, could render web content and had its own browser audio pipeline. The browser itself ran outside OBS while CRESA transferred the rendered frames and audio back into the source.

For normal web content, the concept worked.

Then we tried Twitch.

Our CEF runtime was capable of modern browser rendering, but diagnostics revealed an important limitation: H.264 and AAC were unavailable. Those formats are important for Twitch playback, and when we attempted to load a real Twitch stream the result was Twitch error #4000. Further diagnostics from the Twitch player reported that there was no playable format available.

That changed the problem completely. CRESA Web Source itself worked, but the browser underneath it was not capable of playing the content we ultimately wanted it to handle.

Looking for Another Route

Rather than immediately committing to maintaining our own custom Chromium build, several alternatives were investigated.

We explored building CEF ourselves with additional codec support, using WebView2, and whether OBS's existing media capabilities could provide the missing playback path. Each route taught us something useful, but each also introduced its own technical, distribution or supportability problems.

Building and distributing our own codec-enabled CEF would significantly increase the responsibility of maintaining the browser runtime. WebView2 offered a much more convenient installed browser environment, but did not provide a straightforward replacement for the rendering and audio bridge CRESA had already built. OBS's normal media backend could decode the formats we needed, but there was no clean supported route for handing a Twitch playback stream directly into it.

For a while, it looked as though Twitch playback might have to remain unavailable inside CRESA Web Source.

Then we tested something much closer to home.

The OBS Browser Breakthrough

OBS Browser Source could already play Twitch.

On the exact same machine where CRESA's standalone CEF runtime could not play the stream, a normal OBS Browser Source could. That immediately changed the direction of the prototype.

Instead of replacing CRESA Web Source with a normal Browser Source, we began investigating whether CRESA Web Source could privately manage OBS Browser as one of its rendering backends.

The intended architecture became:

CRESA Web Source → Managed OBS Browser → Web Content

CRESA Web Source would remain the source visible to the streamer. CRESA would continue owning the presentation, configuration and lifecycle, while OBS Browser could provide the actual browser rendering and media capabilities underneath it.

It was the right direction.

It also broke things spectacularly at first.

Breaking It, Fixing It, Breaking Something Else

The first managed OBS Browser prototype immediately exposed a rendering conflict. CRESA and the internal Browser Source were both attempting to participate in OBS's rendering effect lifecycle, producing repeated effect errors and a black output.

That required changing how CRESA Web Source renders. Instead of wrapping the managed browser in another OBS effect pass, the source was changed so the browser backend could render correctly through CRESA's custom draw path.

With that fixed, we hit another problem.

An attempt to expose the managed Browser Source as a child of CRESA required registering CRESA Web Source as a composite source. Unfortunately, CRESA Web Source was already audio-capable, and OBS does not permit that combination of source flags.

The result was considerably less subtle than a black screen: CRESA Web Source disappeared from OBS entirely.

At that point the prototype needed another architectural redesign. Composite ownership was removed and replaced with explicit lifecycle management, allowing CRESA to privately create, own and destroy its managed Browser Source without turning CRESA Web Source itself into an invalid source type.

After rebuilding, CRESA Web Source returned.

Then came the test that mattered.

H.264 and AAC Finally Arrive

Before going anywhere near Twitch again, we built a deterministic certification page specifically for the new backend. It tested ordinary browser rendering, animation, transparency and the media capabilities being exposed through OBS Browser.

The page rendered successfully inside CRESA Web Source.

More importantly, the media tests that had previously failed were now green:

• H.264 MP4: probably playable
• AAC MP4: probably playable
• Opus WebM: probably playable
• VP9 WebM: probably playable
• MediaSource H.264/AAC: supported
• MediaSource VP9/Opus: supported
• MediaSource AV1/Opus: supported

For the first time, CRESA Web Source had access to the media capabilities that its original standalone CEF runtime was missing.

So we went back to Twitch.

The Moment Twitch Actually Played

A dedicated Twitch playback certification surface was created using the official Twitch embedded player. No custom stream extraction, authentication tricks or alternative playback system was involved. The objective was simply to determine whether the new CRESA-managed OBS Browser architecture could genuinely render Twitch.

After resolving how the embedded player needed to be served to the browser, the test finally reached PLAYING.

A real live Twitch broadcast appeared inside CRESA Web Source.

Playback progression was confirmed, the video continued rendering correctly and the previous Twitch #4000 error was gone.

The experimental path was now genuinely working:

CRESA Web Source → Managed OBS Browser → Official Twitch Player → Live Twitch Video

That was the major proof we had been working towards. We were no longer asking whether the architecture should be capable of playing Twitch. We had Twitch physically playing through it inside OBS.

Making the Browser Interactive

Getting video onto the screen introduced another problem: some browser content needs actual user interaction.

Twitch can display player controls, mature-content prompts and other legitimate interactive surfaces. Because the Browser Source underneath CRESA is intentionally private, exposing that source separately just so the streamer could interact with it would defeat part of the reason for building the managed architecture.

CRESA Web Source therefore gained support for OBS's standard Interact system.

When the streamer chooses Interact on CRESA Web Source, mouse, keyboard, focus and scrolling input can now be passed through to the managed browser underneath it. This has already been manually tested with the Twitch player and is working.

The internal Browser Source remains hidden. The streamer interacts with CRESA Web Source.

The Current Fight: Autoplay and Audio

There are still two major pieces being worked on before this experiment can be considered ready for wider integration.

Autoplay is currently inconsistent. Twitch playback itself works reliably once started, and the player can currently be started using OBS Interact, but the intended automatic playback behaviour is not yet operating reliably. We previously reached automatic PLAYING behaviour during development, so the current work involves identifying what changed during the later lifecycle and audio work rather than attempting to bypass Twitch's normal playback restrictions.

Audio has presented an even more interesting problem.

Twitch audio is actually working. Once playback begins, the stream can be heard through the managed OBS Browser. That proves the browser is successfully receiving and decoding Twitch's audio.

The problem is ownership.

The audio currently does not appear through CRESA Web Source's own OBS Audio Mixer channel. The CRESA mixer meter remains inactive even while Twitch audio can be heard. This means the browser playback path is working, but CRESA is not yet correctly receiving and publishing that audio as its own OBS source.

That distinction is important. The finished architecture should behave like:

Twitch Browser Audio → CRESA Web Source → OBS Audio Mixer

That would allow CRESA Web Source itself to own mute, volume and future presentation control while keeping its managed Browser Source completely private. The current audio forwarding implementation has not yet achieved that, so this is now one of the main areas under investigation.

Where We Are Now

CRESA Web Source is still experimental. It has not replaced the production Raid Centre presentation system, and there are still lifecycle scenarios to certify including source recreation, scene changes, OBS restarts, shutdown behaviour, offline Twitch channels and persistent viewer-session behaviour.

But several of the biggest architectural questions have now been answered.

CRESA Web Source exists as a real OBS source. It can privately manage OBS Browser. It can render modern web content through that browser. It has access to H.264 and AAC playback capabilities. OBS Interact works through the CRESA source. And, most importantly, we have successfully played a real live Twitch stream through it.

The remaining work is no longer about proving whether the idea is possible. It is about turning the working prototype into something reliable enough to become part of CRESA's wider presentation architecture.

What started as a relatively simple browser-source experiment has become an entirely new foundation for how CRESA may handle browser-powered content in the future.

And yes, we had to make CRESA Web Source disappear from OBS at least once to get here.