Choose Output 1–4, match the SRT fields, then decode the intended downstream result.
For teams already running vMix
Design the handoff between vMix and Callaba.
Choose whether vMix sends the program to Callaba, receives a remote source from it, or works behind a primary and backup path. Then match the transport fields and prove the destination before the event starts.
Build the manual path first. Add Callaba API actions or vMix Script only after the same route passes an operator rehearsal.
Choose the signal direction
Operator decisionStart with the handoff you need to operate.
Each path uses different vMix screens, endpoint roles, and ready checks. Pick one before creating listeners or routes.
Prove the source in Callaba, add Stream / SRT in vMix, and verify picture, tracks, and reconnect.
Separate the failure domains, define the trigger, and rehearse recovery and failback.
Source verifiedTransport state checkedDestination decoded
Reviewed by Iurii Pakholkov
Founder of Callaba · Live production operator · Updated
Your show is already built in vMix. This guide focuses on the network boundary: where Callaba belongs in the signal path, how to configure the handoff, and how to prove the source, transport, and destination before the event starts.
Choose one clear handoff between vMix and Callaba
vMix builds the program; Callaba handles the network-facing handoff. It can receive or return a transport stream, route or record it, publish it to a browser player, and feed downstream destinations. Define that boundary before you create servers or routes.
ProductionvMix Output 1–4Program, clean feed, or another assigned source
SRT or RTMP
Transport and controlCallabaListener, route, live inspection, recording, or restream
Verified output
DestinationvMix input, player, recorder, or platformThe endpoint that must decode the intended video and audio
vMix sends a program or clean feed
Assign the vMix output first, then configure the matching SRT or RTMP endpoint in Callaba. This is the usual path for restreaming, recording, browser playback, and remote monitoring.
Callaba returns a remote source to vMix
When the remote feed lands in Callaba first, add its receiver or route to vMix through Add Input → Stream / SRT. Avoid exposing a public listener on the production PC unless the network design calls for it.
Primary and backup feeds converge in Callaba
Put the primary and backup in independent source and network failure domains, agree on the switch trigger, and rehearse recovery and failback. A second output from the same PC does not protect that PC.
Send a selected vMix output to Callaba over SRT
Open Settings → Outputs / NDI / SRT in vMix, select the output channel, and enable SRT. Available outputs depend on the vMix edition, and the channel may already be shared with recording, streaming, replay, or an external device. Check the assignment before you change it.
- Assign the source.Choose Program, a clean feed without overlays, or another named output for Callaba. Preview that exact source locally.
- Create the Callaba SRT listener.Put the hostname or public IP, UDP port, Stream ID policy, latency, and encryption settings for this handoff in the runbook.
- Set vMix as Caller for the usual outbound path.Enter the Callaba hostname and port. Listener and Rendezvous are valid in other network designs, provided both endpoints have complementary roles.
- Align transport and media settings.Use the same latency and passphrase on both sides. vMix exposes an encryption Key Length; select the value that corresponds to the Callaba passphrase-length policy. Send H.264 or HEVC video with AAC-LC audio in MPEG-TS. vMix SRT supports progressive video only.
- Validate the receiver, not just the socket.Confirm that Callaba sees the expected bitrate, then open the routed or recorded output and listen to the selected audio bus.
For the screen-by-screen procedure, open the vMix SRT send and receive runbook. This hub stays focused on architecture and acceptance criteria.
Bring a Callaba-routed source into vMix
This is the return path for a phone, encoder, partner feed, or remote venue that reaches Callaba before it enters the vMix production. In vMix, select Add Input → Stream / SRT.
- Verify the remote source in Callaba.Before building the final vMix input, confirm that the intended source is connected and its media decodes.
- Decide which side opens the connection.Caller connects to a reachable Listener. Rendezvous needs matching ports and compatible network conditions at both ends. Draw the connection direction instead of inferring it from endpoint labels.
- Treat the settings as one connection contract.Match the host, UDP port, Stream ID, latency, and passphrase exactly. vMix exposes Key Length. Callaba exposes the passphrase and recommends 16, 24, or 32 characters; it does not present a separate key-length field. A connected socket with the wrong stream identity is still the wrong feed.
- Set decoder behavior for a known reason.Use vMix Decoder Delay when source timing or audio/video arrival requires it, not to mask transport loss or an undersized SRT latency window.
- Test in the production preset.Check picture, audio channels, sync, frame rate, replay requirements, and behavior after a deliberate disconnect and reconnect.
The Larix Broadcaster to vMix over SRT guide covers a phone contribution end to end. Plan talkback and return video as separate signal paths unless the selected tools explicitly combine them.
Match the fields before debugging the network
Start troubleshooting with a side-by-side readback. Keep the expected values in the event runbook and compare both endpoints directly; do not retype them from memory.
| Field | vMix | Callaba | Acceptance check |
|---|---|---|---|
| Output or input | Named Output 1–4 or Stream / SRT input | Named SRT server, stream, and route | The labels identify the same event and direction. |
| Mode and host | Caller, Listener, or Rendezvous; hostname used by Caller | Complementary endpoint role | Caller can reach the Listener address through NAT and firewall rules. |
| UDP port | Selected port | Listener or route port | The port is allowed end to end and is not assigned to another listener. |
| Stream ID | Exact string when required | Expected stream identity or routing policy | Case, punctuation, and mode parameters match the intended feed. |
| Latency | Milliseconds | Matching SRT latency | The value is documented for both ends and tested under the expected network condition. |
| Encryption | Passphrase and Key Length | Passphrase; Callaba guidance uses 16, 24, or 32 characters | The passphrase matches, and the vMix Key Length corresponds to the Callaba passphrase-length policy. Secrets are not stored in the show notes. |
| Video | H.264 or HEVC, bitrate, keyframe frequency, CBR choice, progressive resolution | Receiver and downstream compatibility | The final destination decodes the selected profile, resolution, and GOP. |
| Audio | AAC-LC, bitrate, selected audio bus, channel or track layout | Preserved or deliberately mapped tracks | Every required channel is audible and in sync at the destination. |
The official vMix SRT output guide documents the encoder, latency, passphrase, Stream ID, audio, and codec fields. The vMix SRT input guide documents receiver mode, Decoder Delay, hardware decoding, and multi-track audio.
Verify source, transport, and destination separately
RTT and bitrate describe the transport; neither confirms the delivered program. Watch source, transport, and destination separately during rehearsal and the live event.
Is vMix producing the intended media?
- Correct output assignment and overlays
- Encoder state and CPU/GPU headroom under full load
- Source Dropped, Renderer Dropped, and Resync counters
- Selected audio bus, channels, and sync
Is SRT moving the media within its recovery window?
- Connection state and uptime
- Bitrate trend against the configured media rate
- Packet loss, retransmission, dropped or too-late packets where exposed
- RTT considered together with configured latency and network variation
Can the real endpoint decode the result?
- Correct picture and frame cadence
- Required audio tracks and lip sync
- Recording grows and opens, when recording is part of the job
- Browser player, platform, or receiving vMix input works on the actual route
The vMix Statistics window exposes source and renderer drops, resync, audio timing, SRT bandwidth, packet loss, transferred data, and RTT. For the matching server and route, read live state from Callaba's authenticated operator view. The Engine 8.7 statistic-history API is not a health source.
Design recovery around states and operator decisions
A useful backup removes the failure you are planning for. A second vMix output may protect an output configuration, but it does not protect the production PC, its power, or its network. For higher-risk events, separate the encoder or production system, internet path, and source where practical.
PrimaryvMix programKnown codec, GOP, tracks, and baseline
BackupIndependent feedCompatible media, separate failure domain
DecisionTrigger → switch → verify → fail backNamed owner, timeout, manual override, and recovery evidence
OutputSame destination contractPicture, audio, timestamps, and player behavior rechecked
| State | Operator decision | Evidence required |
|---|---|---|
| Primary active | Keep the backup connected or ready according to the runbook. | Primary and backup identities are visible; destination is decoding primary. |
| Primary degraded or absent | Use the agreed trigger and timeout. Avoid switching on one noisy metric. | Source, transport, and destination checks identify the failed layer. |
| Backup active | Confirm the output before declaring recovery. | Video, audio tracks, sync, and downstream delivery match the event contract. |
| Primary restored | Choose when to fail back; restoration alone is not a reason to interrupt a good backup. | Primary remains healthy for the agreed observation window and the owner approves the change. |
Callaba SRT PULL can reconnect through configured routing hosts. Saving a preferred-route change does not reload a running relay; apply the change with a controlled stop and start, then verify the live output. Recovery time depends on the actual source, reconnect interval, buffers, SRT latency, and network. Do not promise a hitless switch without testing the production path. See the Callaba Live Video Failover product and SRT server lifecycle and API.
Choose SRT, RTMP, or NDI at the boundary
Each protocol fits a different boundary. Choose against the network and destination instead of ranking one protocol as universally better.
| Use | Prefer | Why | Watch for |
|---|---|---|---|
| Contribution across the public internet | SRT | Caller, Listener, and Rendezvous modes; retransmission within a configured latency window; optional passphrase. | UDP reachability, latency sizing, Stream ID, packet recovery, and compatible MPEG-TS media. |
| Publish one program into a familiar streaming ingest | RTMP or RTMPS when the endpoint supports it | Simple server URL and stream-key workflow with broad platform support. | TCP behavior on impaired links, credential handling, and lack of SRT-style recovery controls. |
| High-quality sources and outputs inside a managed production network | NDI | vMix can send and receive NDI and expose independent outputs or inputs on the LAN. | Network capacity, multicast or discovery design, segmentation, and whether the route leaves the controlled network. |
Output count and routing options vary by vMix edition, so check the selected edition against the current vMix Outputs / NDI / SRT documentation. For NDI deployments, verify addressing, discovery, segmentation, and security against the current Callaba and vMix configuration; do not treat a generic NDI walkthrough as an event-ready runbook.
Add automation only after the manual path passes
Automation earns its place when routes must follow the show, presets create event-specific resources, or a control surface needs a bounded start/stop action. Build it from a manual procedure that has already passed.
- Provision once or from an approved preset.Create the listener through the Callaba SRT Servers API and named handoffs through the SRT Routes API. Request examples include vMix Script variants where supported.
- Expose routine actions, not destructive setup.Once the route exists, map start and stop to a vMix shortcut, trigger, or script. Keep deletion, credential rotation, and topology changes away from the live operator button.
- Read the state back.An HTTP success only confirms the request. Check the Callaba resource state and decoded destination after the action.
- Make failure operable.Give the operator a timeout, a visible error, and a manual fallback. Repeated button presses must not create duplicate resources.
vMix scripting is limited to specific editions. Check the current requirements in the official vMix scripting documentation.
Start troubleshooting at the first failed layer
| Symptom | Check first | Next action |
|---|---|---|
| No SRT connection | Caller/Listener direction, hostname, UDP port, firewall, Stream ID, and passphrase. | Read both endpoint values side by side; prove UDP reachability from the Caller network. |
| Connected, no picture | Selected vMix output, encoder state, supported H.264/HEVC and AAC-LC transport stream. | Preview the output locally and decode the same Callaba source before adding routes. |
| Picture, no expected audio | vMix audio bus, channel selection, split stereo pairs, and destination track mapping. | Use a spoken channel-identification test and follow the same track end to end. |
| Intermittent freeze or breakup | Source/renderer drops, encoder load, packet loss, retransmission, RTT, and configured latency. | Identify whether frames fail before encoding, in transport, or at decode; change one layer at a time. |
| Delay is higher than expected | vMix encoding, SRT latency, decoder delay, Callaba processing or routing, and player buffer. | Measure each stage with the same test event instead of subtracting unrelated dashboards. |
| Backup activates but output breaks | Codec, resolution, GOP, audio tracks, timestamps, and destination tolerance. | Align the primary and backup media contract, then repeat loss and failback rehearsals. |
| API action succeeds, route does not change | Whether the action only saved configuration or also restarted the running relay. | Follow the documented lifecycle, then read back state and verify the destination. |
Run a short acceptance check before every event
- The vMix edition, output number, source assignment, overlays, and audio bus are recorded.
- Caller, Listener, or Rendezvous roles are drawn with the initiating side identified.
- Host, UDP port, Stream ID, latency, encryption, codec, bitrate, GOP, resolution, and tracks match the event sheet.
- A clean baseline is captured for vMix drops/resync, encoder load, SRT state, bitrate, loss, retransmission, and RTT where available.
- The actual destination shows the expected picture, audio channels, and sync.
- A deliberate disconnect and reconnect have been observed before the live window.
- The backup has an independent failure domain, a named trigger, an owner, and a rehearsed failback decision.
- The operator knows where to look first and who can change the route during the event.
Open the runbook for the path you are building
Exact SRT fieldsSend and receive SRT with vMixCaller/Listener roles, latency, passphrase, Stream ID, and validation in both directions.
Remote cameraLarix Broadcaster to vMixA phone contribution that reaches Callaba before the production input.
Camera ingestOpen a GoPro feed in vMixThe camera-specific source path, with output and latency checked against the show.
Recovery designPlan a primary and backup SRT pathReconnect, preferred-route changes, and operator recovery for the event.
Product and protocol references
vMix and Callaba questions
Which vMix output should I send to Callaba?
Send the output that represents the downstream program: Program for the main show, or a named output for a clean feed, alternate language, or isolated source. Availability and sharing depend on the vMix edition. Check the assignment under Outputs / NDI / SRT, including any recording or streaming function that uses the same output.
Are RTT and bitrate enough to monitor an SRT feed?
No. Read them alongside connection state, packet behavior, vMix dropped/resync counters, encoder load, audio timing, and a decode check at the destination. The configured SRT latency sets the packet-recovery window; compare it with observed RTT and jitter to judge whether retransmissions can arrive before playout.
Is vMix failover through Callaba hitless?
Do not assume a hitless switch. Detection, reconnect, switching, decoder behavior, GOP, track compatibility, and the destination all shape the visible result. Test the exact primary and backup feeds, then rehearse failback before making an event promise.
Where can I see a live Callaba output before deploying?
Open the live Callaba Multiview demo. The product overview is available separately on the Callaba Multiview page.
Build the smallest path you can prove
Begin with one vMix output, one Callaba listener, and one receiving endpoint. Prove the media contract and recovery behavior before you add restreams, recordings, browser players, or automation.
Choose the signal direction
Choose the vMix workflow you need next.
Start with the setup or operating job in front of you. Each guide continues with the fields and checks for that path.
Core runbookSend and receive SRT with vMix
Match Caller or Listener mode, port, Stream ID, passphrase and latency, then verify both directions.
↗Remote cameraBring Larix into vMix over SRTBuild a controlled phone-to-production path and keep talkback as a separate operator loop.
↗Camera workflowOpen a GoPro feed in vMixReceive the camera once in Callaba, then open the controlled feed in vMix, OBS or VLC.
↗Recovery designPlan a primary and backup SRT pathSeparate the failure domains, define the trigger, and rehearse both recovery and failback.
↗Choose the signal directionBuild the manual path first. Add Callaba API actions or vMix Script only after the same route passes an operator rehearsal.