Stream Bridge Stream Bridge

Convert DeckLink / SDI to WebRTC

Stream Bridge converts a feed from any Blackmagic Desktop Video source, capture card, HDMI or SDI, into WebRTC, so it can reach a browser viewer or another paired device without a dedicated hardware codec.

Signal Flow

4 Simple Steps

  1. Connect your source

    Plug in any DeckLink input: cameras, mixers, routers or broadcast equipment.

  2. Pair the app

    Install Stream Bridge, add a device on the dashboard and enter its connection key.

  3. Convert to WebRTC

    Choose GPU or CPU encoding, set the bitrate and carry up to 16 audio channels.

  4. Receive it anywhere

    In a browser or on another paired device. Direct where possible, cloud when not.

How it works

Setup follows the same steps as any other source. Install the desktop app, create a device on the dashboard, and enter the connection key. Once connected, any DeckLink inputs on that machine are ready to convert into a stream.

You choose how it's encoded and used - NVENC or CPU, live bitrate control, viewer links and Bridge Sharing all let one feed serve people watching remotely as well as systems that need a local production input.

There's no need to exchange public IP addresses or configure inbound ports. We prefer a direct connection and fall back to our cloud relay automatically when firewall or NAT conditions require it.

Hardware checks and clear in-use messages make conflicts visible upfront, while the live pipeline keeps monitoring frame delivery, device performance and network recovery through the session.

Get Started Quickly

To get started straight away, join our beta, download the application, and get streaming. We also have a host of documentation available that goes through all of the features of Stream Bridge, troubleshooting issues, and our support team are ready to help if needed.

Devices

Studio A

Online
Sources 5 sources
Last Seen 18 January 2026 | 10:21 AM
CPU 21%
GPU 20%
Under the hood

Technical Breakdown

Technical detail on the source, audio path, encoding load, picture quality, internet route, and viewer controls.

Supported Sources

Any Blackmagic Desktop Video input the paired device can see.

Explore details

Stream Bridge captures video from anything running through compatible Blackmagic hardware and Blackmagic Desktop Video - capture cards, HDMI and SDI are all supported, covering cameras, vision mixers, routers and replay outputs.

Only sources visible to the desktop device can be selected. Allow discovery time after connecting, and use local-sources-only filtering on a busy production LAN.

Audio

Up to 16 embedded audio channels come through with the picture.

Explore details

Stream Bridge can capture up to 16 audio channels embedded in the source, the same as it does for NDI, delivered to the browser as individually controllable tracks.

Where the audience needs more than the source mix, add separate audio feeds to the link and let them control their own levels. Return communication is an independent per-link choice.

Performance

NVENC where available, CPU as the fallback.

Explore details

A supported NVIDIA GPU encodes through NVENC with barely any CPU impact - normally the best fit beside live production software. CPU encoding is the fallback when there's no compatible hardware, or it's already committed.

Each device starts with limits of four GPU and two CPU encodes. Treat these as safety limits rather than performance targets, and watch the live CPU/GPU meters before raising them.

Viewer Quality & Latency

Live bitrate control, typically under 500ms.

Explore details

Runtime checks and clear in-use errors help spot hardware conflicts before a production starts. Every viewer is a separate connection, and your configured bitrate applies to each one - two viewers at 5Mbps needs roughly 10Mbps upload.

You can change bitrate live without rebuilding the stream. Most 1080p30 pictures sit comfortably around 3-5Mbps; fast motion or 60fps usually wants 5-10Mbps and a stronger connection.

Networking

Direct connection first, cloud relay when that's blocked.

Explore details

ICE negotiation finds a usable route without asking either end to open an inbound port. Where the networks allow it, media travels directly between the production device and its viewer or receiver.

Restrictive NAT and firewall policy can force the connection through TURN instead. That reaches more networks, though the extra hop may add delay, so stick to stable wired bandwidth where you can.

Security & Customisation

Separate, controllable links per audience.

Explore details

Create a different link for each role rather than exposing one universal player - each can have its own URL, password, appearance, audio choices and communication controls while using the same stream.

Anyone with a viewer link can access its feed, so distribute it deliberately and add a password where appropriate. Device connection keys should stay private to whoever manages that machine.

Convert DeckLink / SDI to WebRTC

Frequently Asked Questions

What production teams need to know before configuring this source, route, and destination.

Setup & sources

Anything running through compatible Blackmagic hardware and Blackmagic Desktop Video - capture cards, HDMI and SDI all work, not just SDI. Make sure discovery is switched on, the runtime is installed, and the input isn't locked elsewhere, then create a stream and pick your destination.

Through a browser - Chrome, Firefox, Edge or Safari. Chrome's the most reliable for WebRTC, and nothing needs installing at their end.

We target under 500ms real-time delivery. What you actually get depends on encoder choice, distance, route quality, buffering, and whether it's going direct or through TURN.

Delivery & performance

Each destination is a separate send - multiply your bitrate by the expected simultaneous viewers and bridge routes, then leave headroom for overhead and normal fluctuation.

Yes, up to 16 channels, delivered as individually controllable tracks. Additional audio sources can be exposed separately, and return communication is set per viewer link.

No inbound port forwarding is needed. The session tries direct first and falls back to TURN if network policy blocks that; bridges reconnect once the source and receiver are both available.

Related workflows