WHIP and WHEP for Broadcast: OBS, Opus and WebRTC-to-SRT Workflows

WebRTC is no longer limited to video calls. With WHIP for contribution and WHEP for playback, it can become a practical part of a broadcast workflow: OBS sends a live program with interactive latency, a browser opens a low-latency return feed, and a gateway converts the same route to SRT for a decoder or master control room.

The important point is that WHIP, WHEP, WebRTC, SRT, and HLS solve different parts of the chain. This guide explains where each protocol belongs, how Opus audio affects interoperability, and how to configure an OBS-to-WHIP workflow without treating WebRTC as a universal replacement for SRT.

WHIP, WHEP, and WebRTC in One Minute

WHIP is an IETF Proposed Standard published as RFC 9725. It uses a simple HTTP exchange to establish the WebRTC session: the encoder sends an SDP offer, the server returns an SDP answer, then media flows through the negotiated ICE/DTLS/SRTP path.

WHEP applies a similar HTTP model to playback. As of September 2026, it remains an active IETF Internet-Draft, not yet a published RFC. Implementations are already useful, but version and player compatibility still deserve testing.

The Broadcast Workflow

A useful WebRTC broadcast architecture is not necessarily WebRTC from end to end:

OBS / camera / browser
        │ WHIP (WebRTC contribution)
        ▼
   Vajracast route
     ├── WHEP → browser return, preview, low-latency viewer
     ├── SRT  → MCR, remote production server, broadcast decoder
     ├── HLS  → larger audience and CDN delivery
     └── File → recording

The inverse workflow is equally valuable:

Field encoder / satellite receiver / partner feed
        │ SRT
        ▼
   Vajracast route
        │ WHEP
        ▼
Browser multiview, producer, journalist, client or confidence monitor

This is live protocol conversion with an operational purpose. WHIP makes contribution simple for software encoders. WHEP makes low-latency viewing accessible to browsers. SRT remains useful for resilient facility-to-facility transport and hardware decoders.

Configure OBS to Send WHIP

OBS publishes an official WHIP streaming guide. The basic setup is deliberately shorter than a typical SRT URL.

1. Create the WHIP ingest

In Vajracast:

1. Create or open a route.
2. Add an input and choose WHIP.
3. Save the input.
4. Copy the WHIP endpoint URL and the access credential shown for that endpoint, when authentication is enabled.

Keep the endpoint private. A WHIP bearer token has the same operational role as a stream key: anyone who has it may be able to publish to the ingest.

2. Enter the endpoint in OBS

In OBS, open Settings → Stream and configure:

Do not paste an SRT URL into the WHIP server field. WHIP uses an HTTPS endpoint for signaling; the WebRTC media path is negotiated after that HTTP exchange.

OBS notes that WHIP is not available in every packaging of the application. In particular, its official guide advises Ubuntu 24.04 PPA users who need WHIP to use the Flatpak build. Check the current OBS documentation for your platform before troubleshooting the server.

3. Start with conservative media settings

Provider capabilities and network conditions matter more than a single universal preset. A practical starting point is:

H.264 and VP8 are mandatory-to-implement video codecs for WebRTC endpoints under RFC 7742. Other codecs may be available, but “supported by OBS” does not automatically mean “accepted by every WHIP service” or “decoded by every browser.” H.264 is often the practical bridge when the route must also feed conventional broadcast systems.

4. Verify the route before going live

Confirm four separate layers:

1. OBS reports a successful connection and stable outgoing bitrate.
2. The WHIP input is healthy in Vajracast.
3. Audio and video codec details match the expected route.
4. A WHEP preview or downstream output plays with correct lip-sync and channel mapping.

If signaling succeeds but no media arrives, investigate UDP reachability, ICE connectivity, firewall rules, and codec negotiation. An HTTP 201 response alone does not prove that the media path is healthy.

Why Opus Matters

Opus is not an optional curiosity in WebRTC. RFC 7874 requires WebRTC endpoints to implement Opus, alongside G.711 PCMA and PCMU. Opus is normally preferred when the endpoint can process wideband audio.

It is well suited to interactive contribution because it can handle speech and music, adapt its bitrate, and operate at low algorithmic delay. But broadcast interoperability depends on the next device in the chain.

SRT does not mandate an audio codec. It transports the media format selected by the sender and receiver, commonly inside MPEG-TS. Converting WHIP to SRT therefore has two possible meanings:

• Repackage where compatible: keep H.264 and Opus when the SRT receiver accepts both.
• Transcode for interoperability: keep or convert the video, and convert Opus to AAC/MP2/AC-3 when required by the decoder, MCR, CDN ingest, or satellite chain.

Always test channel count as well as codec. A browser-oriented stereo Opus source is not equivalent to a multi-channel broadcast program, even if both are described as “audio present.” Use an audio matrix when channels must be split, remapped, or converted for the destination.

WHIP-to-SRT: When the Conversion Is Useful

Remote contributor to an MCR

A journalist or producer sends a composed OBS scene over WHIP. Vajracast converts the route to SRT Caller or Listener for the MCR. The contributor gets a simple OBS workflow; the facility receives the protocol its infrastructure already knows.

Browser or software contribution to a hardware decoder

The source enters through WHIP, then leaves as an SRT/MPEG-TS feed compatible with an SDI or HDMI decoder. This may require H.264 normalization and Opus-to-AAC conversion.

One contribution, several delivery paths

One WHIP input can feed a low-latency WHEP preview, an SRT production destination, an HLS audience output, and a recording. Each output has different latency and compatibility goals; forcing them all through one protocol would be less efficient operationally.

SRT-to-WHEP: Bring Broadcast Feeds to the Browser

SRT-to-WHEP is valuable when the source is already a broadcast contribution feed but the viewers are operators, clients, journalists, or producers using browsers.

Typical uses include:

• a browser video wall for multiple incoming feeds;
• confidence monitoring for a remote producer;
• a client preview without installing VLC or an SRT player;
• a near-live return feed for a remote production team;
• a low-latency internal player alongside a higher-latency public HLS output.

This does not turn a browser into a calibrated broadcast monitor. Color management, deinterlacing, codec support, audio-channel exposure, and device decoding still matter. Use WHEP for access and immediacy; use proper broadcast monitoring where signal compliance must be certified.

WebRTC vs SRT vs HLS

WebRTC commonly achieves sub-second latency under controlled conditions, but it is not magic. A congested or highly lossy path can still freeze, reduce quality, or disconnect. SRT deliberately adds a latency budget so packets can be retransmitted. The correct choice depends on whether interaction or recovery is more important; see the SRT latency tuning guide for the transport side of that trade-off.

Common Problems

OBS shows an authentication error

Verify the WHIP endpoint URL and bearer token independently. Do not reuse an RTMP stream key unless the provider explicitly maps it to the WHIP credential.

Signaling works but the route has no media

Check outbound UDP, NAT, ICE/STUN/TURN configuration, and firewall state. HTTPS signaling and SRTP media are separate network paths.

Video works but audio is missing after conversion to SRT

The SRT receiver may not support Opus in MPEG-TS. Inspect its audio codec requirements and transcode to AAC-LC, MP2, AC-3, or another supported format.

WHEP playback works in one player but not another

WHEP is still an evolving draft, and the negotiated codec profile may differ between clients. Test the exact browser and player versions used in production.

Latency increases over time

Separate capture/encode delay, network delay, gateway processing, player jitter buffer, and display delay. “WebRTC latency” is the sum of the entire chain, not one server metric.

Practical Deployment Checklist

• Use a current OBS build that includes WHIP.
• Protect the WHIP URL and bearer token like a stream key.
• Start with H.264 and Opus unless every endpoint has been tested with another codec.
• Confirm whether the SRT receiver accepts Opus before choosing passthrough.
• Validate video profile, pixel format, frame rate, audio codec, sample rate, and channel count.
• Test UDP/ICE connectivity from the actual contributor network.
• Create WHEP, SRT, HLS, and recording outputs according to their distinct purposes.
• Monitor the WHIP input and every downstream endpoint independently.
• Configure failover when the feed is production-critical.
• Test the full workflow before the live event, including reconnection after a network interruption.

The Practical Takeaway

WHIP and WHEP make WebRTC easier to integrate into broadcast systems because they standardize the edges: publishing into a service and playing out from it. They do not eliminate the need for routing, monitoring, codec conversion, recording, or resilient transport.

The most useful architecture is often hybrid. Use WHIP where a software encoder or browser needs simple low-latency contribution, WHEP where a browser needs immediate playback, SRT where the network or professional receiver demands resilient transport, and HLS where audience scale matters.

The Vajracast SRT gateway connects those workflows in one route: WHIP input, WHEP preview, SRT handoff, HLS distribution, recording, health monitoring, and failover without requiring every participant to use the same protocol.