Skip to content
Callaba

How to receive an SRT stream in OBS Studio with Callaba

On this page

Inbound OBS receiver preflight

Receiving SRT in OBS is a two-endpoint job. Connection roles come first, followed by proof that the sender or server is ready, one configured Media Source and a decoded picture, audio and reconnect check.

This procedure covers inbound reception only. Publishing from OBS and general scene design belong to different workflows.

Assign Caller and Listener roles

The two endpoints fit on one line: which application waits, which initiates, and which address and UDP port each side uses. Caller initiates toward a Listener. If the sender already calls, OBS must listen; if a server waits, OBS can call it. Two Callers or two Listeners do not form the intended pair.

SRT is an open-source transport protocol for live video and audio; it uses UDP and ARQ-based retransmission, with optional AES encryption. Those protocol features do not replace correct role and firewall configuration. When the connection model is unfamiliar, Resolve SRT roles first and return with an explicit endpoint map.

Role line: sender/server mode, OBS mode, local bind or remote address, UDP port, Stream ID or passphrase policy when used, and configuration owner.

Prove the sender or server endpoint

The inbound SRT endpoint should exist before the OBS source opens. For Callaba, Configure the Callaba endpoint and retain the current server state, role, port and sanitized connection information. The expected publisher then needs to be connected or ready in the chosen direction.

Reachability is tested from the OBS network. A cloud security group, host firewall, NAT rule or occupied port can fail before media reaches the application. Transport proof remains separate from decode proof: a connected socket does not establish that OBS receives an MPEG-TS payload containing supported audio and video.

  • Confirm role pairing and destination address.
  • Verify UDP policy along the real route.
  • Record sender application and media format.
  • Keep credentials and passphrases out of screenshots.
  • Use a known test signal when production media is uncertain.

Add an OBS Media Source

Create a new Media Source with a name that identifies the feed and environment. For SRT input through OBS Media Source, disable Local File, enter the SRT URL, set mode according to the peer role and set Input Format to mpegts. Do not add multiple experimental sources to the same scene while diagnosing the first connection.

OBS Media Source is available on Windows, macOS and Linux; acceptance still requires decoded picture and audio, not only a connected socket. Record the exact OBS version and platform because fields and bundled media libraries can change. Follow the current OBS SRT fields for the implementation sequence used here.

Scope: Media Source receives the feed. Do not switch to Settings → Stream and accidentally test outbound publishing.

Enter the SRT URL and MPEG-TS input format

The URL comes directly from the endpoint map. A remote host and port are used when OBS calls a waiting peer; the documented listener form applies when OBS waits. Only options required by the known design belong in the string, because copied parameters from another deployment may use different units, roles or security policy.

For this workflow, the input format is mpegts. The ticket receives a sanitized URL while retaining the non-secret options needed to reproduce the connection. After the source is applied, its OBS log timestamp can be compared with remote endpoint state.

FieldRecorded valueAcceptance question
Local FileDisabledIs OBS reading a network source?
InputSanitized SRT URLDo host, port and mode match the peer?
Input FormatmpegtsDoes the arriving payload match?

Verify decoded picture and audio

The preview rectangle is only the beginning. The source should be visible in the intended scene, the picture should move, audio meters should respond, the correct channels should be audible and lip sync should remain acceptable. When tools expose them, resolution, cadence and audio layout belong in the received-output record.

If available, Inspect the feed in Multiview to compare the server-side decoded view with OBS. A clean server view and failed OBS decode narrows the problem, while a missing view at both surfaces keeps the investigation upstream. A recorded session is more useful than a transient glance.

Troubleshoot role, reachability and media separately

Roles come first: one Caller and one Listener. Address, port and UDP reachability follow, then whether the remote endpoint sees the session. MPEG-TS, codec and track compatibility matter only after transport exists. This order keeps random codec changes from hiding a firewall error.

Intermittent reception needs disconnect and reconnect timestamps on both sides, with one option changed per run. OBS logs, remote state and the same decoded-output observation make runs comparable. A temporary workaround should not become a permanent URL until its reason is documented and the security owner approves it.

No session
Roles, address, UDP policy, port ownership.
Session, no media
Payload, input format, codecs, tracks and timestamps.

Save the receiver preflight

A clean start and controlled reconnect close the test. The saved record includes exact OBS version, sanitized SRT URL and options, both endpoint roles, input format, connection result, decoded picture and audio, reconnect result, server or sender version and the person who approved the feed.

The preflight should be reusable without exposing a secret. A redacted connection template belongs in the runbook while protected values stay in the approved secret system. Changes to sender, route, OBS build or media format trigger the same check before the event.

Ready: one valid role pair, reachable UDP path, matching MPEG-TS input, decoded picture and audio, successful reconnect and a timestamped evidence package.