A camera receiver in the browser.

Why this is worth doing

A browser receiver removes the install step from everything downstream. A stage manager opens a link and sees the camera. A producer in another room watches on a tablet. A dashboard shows four angles next to the run sheet. None of it requires shipping software to anyone, and it works on hardware you don't control.

For a long time this meant WebRTC and a media server, which is a lot of moving parts for what is essentially "show me these frames." WebCodecs makes the direct route viable.

What the browser gives you

WebCodecs exposes the decoders the browser already ships. You hand VideoDecoder a configuration and then encoded chunks, and it hands back VideoFrame objects you can draw to a canvas. H.264 is the most broadly supported codec in that set, which lines up with what the protocol sends.

Support as of 2026: Chrome and Edge from 94, Firefox from 130, Safari from 26 on macOS, iOS and iPadOS. That is broad enough to build on, though it is worth checking VideoDecoder.isConfigSupported() before assuming.

The constraint that shapes the design

That process is genuinely small. It speaks the protocol on one side — discovery, TCP, framing — and a WebSocket on the other, forwarding the payloads it has already separated. It is the same code you would write for any receiver, with a different output. Everything visual still happens in the page.

If that feels like defeat, consider what it buys: the relay is one binary you run once on the production machine, and after that any device on the network gets a monitor by opening a URL.

The build, in order

1. Relay first. Get discovery, TCP and packet framing working in your relay, logging packet types. This is ordinary receiver work — the build order for any receiver applies.
2. Forward, don't reassemble in the page. Send each complete packet over the WebSocket as its own message. Doing the framing in the relay means the browser never has to think about partial reads.
3. Configure the decoder from the format description. The protocol sends a format description before any frames; that is what your VideoDecoder configuration is built from. Configure once, then feed access units.
4. Mind AVCC. The video is AVCC — length-prefixed NAL units — and the description carries the parameter sets. Getting this wrong is the classic reason a decoder accepts everything and outputs nothing.
5. Draw and release. Paint each VideoFrame to a canvas and call close() on it. Frames hold real memory; leaking them will stall the page within a minute.
6. Send control back. The WebSocket runs both ways, so the page can emit control messages — cue a camera, ride exposure, flip tally — through the relay.

Latency, honestly

You can get to a monitor that feels immediate, but WebCodecs was not designed as a low-latency contract. There is no standard way to demand strict one-in-one-out decoding, and behaviour varies between browsers. Practical guidance:

• Draw the newest frame and drop the backlog. A monitor that is current beats one that is complete.
• Watch decodeQueueSize. If it grows, you are behind; shed frames rather than buffering into a delay you can't recover from.
• Never use a browser monitor as your program path. It is for looking at, not for broadcasting. The program should come from Bridge or a native receiver.

What it will not do

The protocol carries no audio, so a browser monitor is picture only. Discovery stays on the local network — remote viewing means exposing your relay deliberately, with the security thinking that implies. And the camera's optional password is access control, not encryption: a WebSocket carrying that video across an untrusted network should be wrapped in TLS by you.

Within those lines, this is one of the more satisfying things to build on the protocol — a few hundred lines of relay, a canvas, and every screen in the building becomes a monitor.