Haivision Makito X4 SRT setup with Callaba Gateway, multiview, recording and playback

May 19, 2026

Written by Iurii Pakholkov

Founder of Callaba. Building cloud video tools for SRT, RTMP, WebRTC, NDI, live routing, monitoring, recording, and production workflows.

Release: Callaba 8.4

Haivision Makito X4 is a professional SRT encoder and decoder family used for low-latency contribution workflows. Unlike the NDI-only articles in this series, this one does not need an NDI bridge for ingest: Makito X4 supports SRT at the device/firmware workflow level, so you can send an SRT stream directly to Callaba Gateway without an extra protocol converter.

The cleanest setup is simple: create an SRT listener in Callaba Gateway, then configure the Makito X4 encoder as an SRT caller. After Callaba receives the stream, you can monitor it in the browser, place it on a multiview board, record it, create playback links, or route it to another destination.

This guide is written for the search intent behind Haivision Makito X4 SRT, Makito X4 multiview, Makito X4 recorder, Makito X4 playback, Haivision encoder SRT Gateway and Callaba SRT Gateway.

Quick answer: how do I connect Haivision Makito X4 to Callaba Gateway?

Create an SRT server in Callaba Gateway in Listener mode, open the selected UDP port, then create an SRT stream on Makito X4 in Caller mode. Enter the Callaba public IP or DNS name, destination port, latency, stream ID if used, and the same passphrase if encryption is enabled.

Makito X4 sends native SRT to Callaba Gateway. Callaba then handles browser monitoring, recording, playback and routing. This guide focuses on the practical SDI-to-SRT contribution path; ST 2110 is an optional source-side format in supported Makito X4 workflows.

What this setup does

This workflow sends a live video feed from a Haivision Makito X4 encoder to Callaba Gateway over SRT. Callaba receives the stream in the cloud and turns that contribution feed into something operators can monitor, record, play back and route.

Makito X4: encodes the source and sends SRT natively.
Callaba Gateway: listens on a public UDP port and accepts the incoming SRT stream.
Operators: use Callaba to check preview, bitrate, codec, audio, recording, multiview and downstream routing.

Which Haivision devices this guide fits

The main target is Haivision Makito X4 Encoder. The same SRT thinking can also help when planning with Makito X4 Rugged or Makito X4 Decoder, but the workflow direction changes.

Device	Callaba article angle	Workflow note
Makito X4 Encoder	Native SRT contribution to Callaba Gateway.	Best first article target.
Makito X4 Rugged	Field, ISR, vehicle or harsh-environment SRT contribution.	Same SRT principle, different deployment context.
Makito X4 Decoder	SRT return feed or hardware decode from Callaba output.	Direction is reversed: Callaba sends or the decoder pulls.

Recommended SRT mode: Callaba Listener, Makito X4 Caller

For normal cloud ingest, use this direction:

Callaba Gateway: Listener
Haivision Makito X4: Caller

This keeps the public UDP listener on the cloud side. The venue only needs to allow the Makito encoder to send outbound UDP traffic to the Callaba IP and port.

For ingest, Makito X4 calls the Callaba listener. For decoder/return workflows, the role may reverse depending on your network design.

A typical URL shape for the Makito X4 SRT caller side can look like this:

srt://YOUR_CALLABA_IP:10300?mode=caller&latency=200&streamid=makito-x4-main

Use this as a field-format example. In the Makito interface, these values may be entered as separate fields: mode, address, destination port, latency, stream ID and encryption settings.

Before you start

Prepare the network and media settings before touching the production profile.

Callaba address Use the public IP address or DNS name of the Callaba instance that will receive the SRT stream.

UDP port Choose one UDP port for this input and open it in the cloud firewall or security group.

Latency Start with 120–500 ms for internet contribution. Increase it if the path is unstable.

Stream ID Use a clear name such as makito-x4-main if your workflow uses stream ID routing or access control.

Encryption If you enable AES, use the same passphrase and encryption setting on both sides.

Codec profile Confirm HEVC/H.265 or H.264, resolution, frame rate, bitrate and audio mapping before the event.

Step 1: create the SRT listener in Callaba

Open your Callaba Gateway environment.
Go to SRT Servers and create a new incoming SRT server.
Set the role to Listener if the UI exposes this option.
Choose a UDP port, for example 10300.
Set latency, for example 200 ms as a starting point.
Add stream ID and passphrase if your workflow requires them.
Open the selected UDP port in the cloud firewall or security group.
Copy the SRT publisher URL or copy the host, port and SRT settings for the Makito profile.

Step 2: configure the Makito X4 SRT output

Open the Makito X4 web interface and configure the stream output that should send contribution to Callaba.

Firmware wording note: field names can change slightly between Makito X4 firmware versions. Look for the SRT protocol or transport settings, then match the meaning of these fields: SRT mode, destination address, port, latency, Stream ID or Stream Identifier, and AES or Encryption passphrase.

Select the video input or encoded stream you want to send.
Create or edit an output stream and select TS over SRT or the SRT transport option available in your firmware.
Set the SRT connection mode to Caller.
Enter the Callaba public IP address or DNS name as the destination address.
Enter the same destination UDP port that Callaba is listening on.
Set latency to your starting value.
Enter stream ID if Callaba expects one.
Enable encryption only if you have already prepared the same passphrase in Callaba.
Start the stream and check connection state, preview and statistics in Callaba.

Testing rule: for the first test, use one stream, one Callaba listener, one UDP port and no encryption. After the first clean connection, add stream ID, passphrase, recording, multiview and routing.

Settings table

This is the fastest way to avoid mismatches between Makito X4 and Callaba.

Codec test rule: Makito X4 can send HEVC/H.265, but for the first Callaba ingest test use H.264 if possible. If you plan to use HEVC, confirm that your Callaba installation and the downstream preview, player, recorder or transcoding path support that codec.

Makito X4 and Callaba must agree on SRT direction, port, stream ID, encryption, latency and media profile.

Setting	Makito X4	Callaba Gateway	Why it matters
SRT mode	Caller	Listener	One side waits, the other connects.
Address	Callaba public IP or DNS	Public endpoint	Makito must call a reachable address.
Port	Destination UDP port	Open listener UDP port	A wrong port looks like no connection.
Stream ID	`makito-x4-main`	Same value if expected	Identifies the feed and can drive access/routing logic.
Passphrase	Same passphrase if encrypted	Same passphrase if encrypted	Encryption fails if values do not match.
Codec	HEVC/H.265 or H.264	Receive, preview and route	Downstream compatibility depends on codec choice.

Makito X4 multiview workflow with Callaba

The Makito X4 can provide the contribution stream. Callaba provides the browser monitoring surface after ingest. This matters when operators need to watch multiple feeds, verify bitrate and audio, and keep route state visible.

After Callaba receives the Makito stream, the same source can be monitored, recorded, played back and routed.

Interactive check: open the Callaba multiview demo to see how received sources can look after cloud ingest.

Makito X4 recorder workflow: encoder side vs Callaba cloud recording

A Makito-side source check and a Callaba cloud recording do different jobs. Local or encoder-side monitoring confirms that the source exists. Callaba recording confirms that the stream actually reached the cloud workflow.

Layer	What it verifies	Use case
Source / encoder side	That Makito sees the input and encodes the selected profile.	Use during local setup and source validation.
Callaba cloud recording	That the SRT stream actually arrived in Callaba.	Use when you need cloud-side proof of the received workflow.

Makito X4 playback workflow with Callaba

Callaba playback means browser player, HLS output, embed link or a cloud route after Callaba receives the stream. These links are created in Callaba after you set up a web player or HLS path for the incoming stream.

HLS playlist after Callaba ingest:
https://YOUR_CALLABA_DOMAIN/hls/makito-x4-main/playlist.m3u8

Player or embed page:
https://YOUR_CALLABA_DOMAIN/embed/makito-x4-main

Where the links come from: these example URLs are not generated automatically for every stream. Callaba creates them after you create a Web Player or HLS packaging path. Depending on your settings, links may include temporary tokens or authorization parameters.

Decoder and return-feed workflows

If your workflow uses a Makito X4 Decoder, the direction changes. Callaba can provide a cloud-managed SRT output route, and the decoder can receive or pull that stream depending on your network design and the decoder configuration.

Decoder pulls from Callaba: the decoder acts as caller and connects to a Callaba listener.
Callaba pushes to decoder: Callaba acts as caller and sends to a decoder listener if the decoder network exposes a reachable port.
Return feed: this can be useful for venues that need a confidence monitor, program return, or hardware SDI output.

For most public internet paths, keeping the listener on the side with the stable public endpoint is the easiest operating rule.

Example when the decoder pulls the return feed from Callaba:

srt://YOUR_CALLABA_IP:10301?mode=caller&latency=200&streamid=makito-x4-return

Use this when Callaba has the stable public endpoint and the decoder can initiate the outbound connection.

Example when Callaba pushes the return feed to a decoder listener:

srt://DECODER_PUBLIC_IP:10302?mode=caller&latency=200&streamid=makito-x4-return

Use this only when the decoder side has a reachable public address or a correctly forwarded UDP port. Otherwise the decoder-pulls-from-Callaba model is usually easier.

Troubleshooting

Most Makito X4 to Callaba problems are caused by connection-mode, port, stream ID, encryption or media-profile mismatches.

Debug SRT connection first. Then check media profile, audio, preview and downstream output.

1. No connection in Callaba

Confirm Callaba is in Listener mode.
Confirm Makito X4 is in Caller mode for ingest.
Check destination IP or DNS name on Makito X4.
Check that the UDP port is open in the cloud firewall.
Check that the venue network allows outbound UDP to that port.

2. Connection starts, then drops

Increase SRT latency.
Lower bitrate and test again.
Check path stability, packet loss and reconnect behavior.
Avoid starting with the highest 4K profile for the first test.

3. Connected, but no picture or no audio

Confirm the source input is active on Makito X4.
Start with H.264 and a conservative HD profile before testing HEVC or 4K.
If the SRT connection is established but no picture appears, check whether Callaba and the downstream player path support the codec sent by Makito X4. Temporarily switch to H.264 with Baseline or Main profile for the first test.
Check audio mapping and embedded audio source.
Verify the received codec, resolution, bitrate and audio state in Callaba.

4. Stream ID or encryption fails

Make sure the stream ID entered on Makito X4 matches what Callaba expects.
Check whether access control is enabled on the Makito side.
Use the exact same passphrase and encryption settings on both sides.
Test once without encryption, then enable encryption after the basic SRT path is stable.

Official references used for this guide

Use these if you need exact Haivision firmware wording, SRT setup fields, Stream ID behavior or Makito X4 device capabilities.

FAQ

Can Haivision Makito X4 send SRT to Callaba Gateway?

Yes. Makito X4 has native SRT support. In a simple cloud ingest setup, create a Callaba SRT listener and configure Makito X4 as an SRT caller.

Should Makito X4 be Caller or Listener?

For most public cloud ingest workflows, set Callaba Gateway as Listener and Makito X4 as Caller. This keeps the open UDP port on the cloud side.

Which SRT values must match?

The destination port, stream ID if used, encryption/passphrase if used, and latency policy must be aligned between Makito X4 and Callaba.

Can I monitor Makito X4 in Callaba multiview?

Yes. After Callaba receives the SRT stream, you can monitor the feed in browser preview or multiview depending on your deployment and version.

Can I record a Haivision Makito X4 stream in Callaba?

Yes. Callaba records the received cloud-side stream, which is useful as proof that the feed reached the gateway correctly.

Should I start with H.264 or HEVC?

Start with H.264 for the first ingest test. Makito X4 can send HEVC/H.265, but you should confirm that your Callaba installation and downstream preview, player, recorder or transcoding path support HEVC before using it in production.

Final practical rule

Make the first Makito X4 → Callaba SRT connection boring. One output, one UDP port, one listener, one caller, no unnecessary routing. When that is stable, add stream ID, encryption, recording, multiview, playback and downstream destinations.

Last updated: May 19, 2026

Try Callaba Gateway with your Haivision Makito X4

Create an SRT listener in Callaba, send a Makito X4 stream to the gateway, and monitor the feed before routing it to recording, restreaming, multiview, playback or player delivery.

See SRT server setup Open multiview demo Makito X4 SRT docs