Matrox Monarch EDGE SRT setup: Gateway, multiview, recording and playback

May 14, 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

Matrox Monarch EDGE is a professional hardware encoder family used for remote production, contribution, and return-feed workflows. If you want to send a Monarch EDGE feed into a cloud workflow, the cleanest setup is usually simple: create an SRT listener in Callaba Gateway, then configure the Matrox encoder as an SRT caller.

This guide is built around four practical search intents: Matrox Monarch EDGE SRT, Matrox Monarch EDGE multiview, Matrox Monarch EDGE recorder, and Matrox Monarch EDGE playback. The main job is SRT contribution. The larger workflow starts after Callaba receives the stream: browser multiview, cloud recording, playback, routing, failover, and delivery.

Quick answer: how do I connect Matrox Monarch EDGE to Callaba Gateway?

Create an SRT server in Callaba Gateway in Listener mode, open the selected UDP port, then set the Matrox Monarch EDGE output to SRT Caller. Enter the Callaba public IP or DNS name, destination port, latency, stream ID if used, and the same passphrase if encryption is enabled. After ingest, the same feed can be monitored in multiview, recorded, previewed in the browser, or routed to playback and delivery workflows.

Monarch EDGE provides the hardware contribution feed. Callaba receives it and turns it into a cloud workflow for monitoring, recording, playback, and delivery.

What this setup does

This workflow sends a live video feed from a Matrox hardware encoder to Callaba Gateway over SRT. Callaba receives the stream in the cloud, then the feed can be monitored, routed, recorded, restreamed, used in a web player, or placed into a browser-based multiview board.

The important part is the split of responsibility:

Matrox Monarch EDGE encodes the SDI input and sends the SRT contribution stream.
Callaba Gateway listens on a public UDP port and accepts the incoming SRT stream.
Callaba workflow tools make the feed useful after ingest: browser preview, multiview, recording, restreaming, failover, and player delivery.

That is the SEO and product story: Matrox creates the contribution feed. Callaba gives that feed an operational workflow.

Which Matrox Monarch EDGE models this guide fits

The main targets are Matrox Monarch EDGE E4 and Matrox Monarch EDGE S1. Both are relevant for SRT workflows, but they are used differently.

The Monarch EDGE E4 is the stronger first target for multi-camera remote production and contribution. The Monarch EDGE S1 is useful for single-channel contribution and return-feed style workflows where encode and decode can both matter.

Model	Best Callaba angle	Use in this guide
Monarch EDGE E4	Multi-camera SRT contribution to a cloud gateway.	Primary model for this page.
Monarch EDGE S1	Single-channel contribution, decode, return feed, and playback-related workflows.	Mentioned where playback and return feed are relevant.

Practical note: do not assume every older Matrox encoder has the same SRT workflow. Before following any setup guide, confirm that the exact model and firmware support SRT output.

Recommended SRT mode: Callaba Listener, Matrox Caller

SRT can use different connection modes. In most public cloud ingest workflows, the easiest model is:

Callaba Gateway: Listener
Matrox Monarch EDGE: Caller

This keeps the public listening port on the Callaba side. The venue only needs to allow the Matrox unit to send outbound UDP traffic to the Callaba IP and port. This is usually easier than asking the venue to expose an inbound port to the encoder.

This role mapping keeps the public port in the cloud and avoids exposing the encoder on the venue network.

A typical SRT URL shape looks like this:

srt://YOUR_CALLABA_IP:10080?mode=caller&latency=200&streamid=matrox-edge-main

Here is a filled example with demo-style values. Treat it as a copy pattern, not as a live ingest endpoint:

srt://demo.callaba.io:10080?mode=caller&latency=200&streamid=matrox-edge-main

In production, replace demo.callaba.io with your Callaba instance public IP address or DNS name, replace 10080 with your open UDP listener port, and use your own stream ID.

Some device interfaces ask for these values as separate fields instead of one URL. That is fine. The logic is the same: destination address, destination UDP port, caller mode, latency, optional stream ID, and optional encryption settings.

Before you start

Prepare the connection before touching the live production profile. This avoids the most common mistake: changing many values at once and then not knowing which one broke the stream.

Callaba public 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 make sure it is open in the cloud firewall or security group.

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

Stream ID Use a clear name such as matrox-edge-main if your workflow uses stream ID routing.

Passphrase If you enable encryption, use the same passphrase on both sides. Keep it within the valid SRT length range.

Codec profile Confirm what Callaba will receive: H.264/H.265, resolution, frame rate, bitrate, and audio format.

Step 1: create the SRT listener in Callaba

In Callaba, create a new incoming SRT server for the Matrox feed. The exact module name can differ by your UI version, but the operational idea is the same: Callaba opens a UDP port and waits for the Matrox encoder to connect.

Open your Callaba environment.
Create a new SRT input or SRT server.
Set the role to Listener if the UI exposes this option.
Choose a UDP port, for example 10080.
Set latency, for example 200 ms as a starting point.
Add a stream ID if your routing model uses it.
Add the same passphrase that you plan to use on Matrox, if encryption is needed.
Open the UDP port in your cloud firewall or security group.

Testing rule: for the first test, keep the setup simple. One Matrox output, one Callaba listener, one UDP port, no encryption. After the first clean connection, add stream ID, passphrase, recording, restreaming, multiview, playback, or failover.

Step 2: configure the Matrox SRT output

Open the Matrox Monarch EDGE web interface and choose the output profile that should send the contribution feed. Firmware versions can change the labels, so look for the SRT output, streaming protocol, or transport settings.

Select the SDI input or encoded channel you want to send.
Set the streaming protocol to SRT.
Set the 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 the same starting value, or close to it.
Enter stream ID if Callaba expects one.
Enable encryption only if you have already prepared the same passphrase in Callaba.
Start the output and watch for connection state in Callaba.

If the Matrox UI supports multiple outputs per input, start with one clean output first. After the first feed is stable, duplicate the settings for backup, lower-resolution monitoring, or a second Callaba destination.

Matrox Monarch EDGE SRT settings table

This table is the fastest way to avoid mismatches. The words in the Matrox interface can differ, but the values must describe the same SRT connection.

Use this as a checklist before blaming the encoder, the cloud instance, or the network.

Setting	Callaba Gateway	Matrox Monarch EDGE	Why it matters
Mode	Listener	Caller	One side must wait, the other side must connect.
Address	Public IP or DNS	Callaba destination address	Matrox must call the reachable Callaba address.
Port	Open UDP port	Same destination port	A wrong port looks like no connection at all.
Latency	120–500 ms starting point	Same or close value	Too low can break stability on noisy networks.
Stream ID	`matrox-edge-main`	Same value if used	Useful when several streams share routing logic.
Passphrase	Same encrypted stream passphrase	Same encrypted stream passphrase	If encryption is enabled, both sides must match exactly.

After ingest: multiview, recorder, playback, routing

The Matrox SRT connection is only the entry point. After Callaba receives the feed, the same source can become part of several production workflows.

This is the core Callaba message: SRT ingest is the start, not the end of the workflow.

This is why the page should not stop at SRT settings. People searching for Matrox Monarch EDGE multiview, Matrox Monarch EDGE recorder, or Matrox Monarch EDGE playback may be trying to solve the same larger problem: what to do with the feed after the encoder sends it.

Interactive check

Open the Callaba multiview demo to see the monitoring side of this workflow. In a real Monarch EDGE setup, the tiles would be your Matrox SRT sources after Callaba receives them.

If you have a public recording page or HLS playlist from a Matrox test, add it here as a second proof point. That turns the article from a setup guide into a working example: encoder → SRT gateway → multiview → recording/playback.

Matrox Monarch EDGE multiview workflow with Callaba

Matrox does not have to be your multiview system. It can simply send the reliable SRT contribution feed. Callaba receives the stream and makes it available for browser-based multiview, where operators can watch several incoming sources from one board.

This is useful when you have several Matrox feeds, backup lines, or venue sources and you do not want to bring every stream back into a local hardware multiviewer. The browser board becomes the operational view after ingest.

Try the multiview demo

Open the Callaba multiview demo to see how a received SRT feed can be monitored from a browser board. In a real Matrox workflow, the tiles would show your Monarch EDGE contribution feeds after Callaba receives them.

Use Matrox Monarch EDGE as the hardware contribution encoder.
Receive the SRT feed in Callaba Gateway.
Place the received stream on a multiview board.
Monitor video, audio, bitrate, codec, connection state, and route behavior.

Matrox Monarch EDGE recorder workflow: local recording vs cloud recording

There are two different recording questions in a Matrox workflow. The first is whether the Matrox unit can record locally or to attached storage in your exact configuration. The second is whether you want to record the received stream after it reaches the cloud gateway.

For Callaba, the important angle is gateway-side recording after SRT ingest. That means the Matrox encoder sends the contribution feed, Callaba receives it, and the cloud workflow records the stream after it has passed through the same path you monitor and route.

Recording type	Where it happens	Why it matters
Encoder-side recording	On or near the Matrox device, depending on model and configuration.	Useful as a local copy close to the source.
Callaba cloud recording	After the SRT stream reaches Callaba Gateway.	Useful when you want to record the same received feed that is monitored, routed, or delivered downstream.

For production, this is a clean mental model: local recording protects the source side; cloud recording protects the received workflow side. The strongest setup is often parallel recording: keep a local copy near the encoder when the device and storage workflow allow it, and record the received SRT feed in Callaba so the cloud copy matches what operators actually monitored and routed.

Matrox Monarch EDGE playback workflow with Callaba

Playback can mean different things in this context. For some teams, it means browser preview after SRT ingest. For others, it means a web player, downstream delivery, or a return-feed workflow.

With Callaba, the simple path is: receive the Matrox SRT feed, confirm it in the browser, and then route it to the playback path you need. That may be an internal preview, a web player, a CDN workflow, or another production destination.

Browser preview: confirm that the Matrox feed is live after Callaba receives it.
Web playback: route the received stream toward a player or delivery workflow.
Return feed: for Monarch EDGE S1-style encode/decode workflows, Callaba can sit in the cloud routing path for the return-feed side. S1 can handle contribution and return-feed use cases, while Callaba helps receive, monitor, and route the live paths.

This is not a replacement for the Matrox device role. It is the next layer after contribution: making the received feed visible, usable, and routable.

What to monitor in Callaba after Matrox starts streaming

Once the Matrox output is active, Callaba should become the operational source of truth for the incoming feed. Do not only check whether the stream is connected. Check whether it is useful for production.

Connection state: the Matrox caller should appear as connected to the Callaba listener.
Bitrate: confirm that the live bitrate matches the expected encoder profile.
Codec: confirm H.264/H.265 and profile compatibility with the next part of the workflow.
Resolution and frame rate: confirm the received values match the production format.
Audio: check that audio exists and is routed as expected.
Packet loss / stability: watch for packet loss, reconnects, or jitter symptoms.
Preview: use browser preview or multiview to confirm the picture is actually live.

Operational rule: the stream is not ready when the socket connects. It is ready when connection state, preview, bitrate, audio, recording path, playback path, and downstream routing all look correct.

Troubleshooting

Most SRT problems fall into a small number of buckets. Check them in this order.

Start with transport settings. Only move to codec, audio, preview, recording, and playback after the SRT connection is stable.

1. No connection in Callaba

Confirm Callaba is in Listener mode.
Confirm Matrox is in Caller mode.
Check the destination IP or DNS name in the Matrox profile.
Check that the UDP port is open in the cloud firewall.
Check that the venue network allows outbound UDP to that port.

2. Connected, but no picture

Confirm the Matrox input has a valid SDI signal.
Confirm the output profile is active.
Start with H.264 before testing more specific profiles.
Check resolution, frame rate, and audio mapping.
Restart only the stream output first, not the whole device, so you can isolate the issue.

3. Stream drops or stutters

Increase SRT latency.
Lower bitrate and test again.
Check uplink speed from the venue.
Watch packet loss and reconnect behavior in Callaba.
Avoid Wi-Fi for the encoder path when possible.

4. Encryption fails

Check that encryption is enabled on both sides or disabled on both sides.
Use the exact same passphrase on Matrox and Callaba.
Make sure the passphrase is not too short.
Confirm any AES/key-length option if the interface exposes it.

5. Multiview works, but recorder or playback does not

Confirm the received stream has a stable codec and audio format.
Check whether the recording route is using the same input you see in preview.
Check whether the playback route expects a different protocol, bitrate, or resolution.
Use a simple H.264 test profile before testing a full production profile.

Official references used for this guide

Use these references if you need exact Matrox firmware specs, supported SRT modes, S1 return-feed details, or SRT encryption behavior. They are also useful when you want to confirm the article against official vendor documentation before a live event.

FAQ

Can Matrox Monarch EDGE send SRT to Callaba Gateway?

Yes. Monarch EDGE supports SRT and can be used as a hardware SRT contribution encoder. In a simple cloud ingest setup, Callaba Gateway listens for the incoming SRT stream and the Matrox encoder connects as the caller.

Should Matrox be Caller or Listener?

For most public cloud workflows, set Callaba as the SRT Listener and set Matrox as the SRT Caller. This keeps the open UDP port on the cloud side and usually makes firewall rules easier at the venue.

Can I use Matrox Monarch EDGE with browser multiview?

Yes. Matrox sends the SRT feed; Callaba receives it and can place the received stream on a browser-based multiview board. This is useful when operators need to monitor several Matrox feeds, backup lines, or venue sources from one browser view.

Can I record a Matrox Monarch EDGE SRT feed in Callaba?

Yes. After Callaba receives the SRT stream from the Matrox encoder, you can record the received feed in the cloud workflow. This is different from encoder-side recording and is useful when you want to record the same stream that is monitored and routed downstream.

Can I preview or play back the Matrox stream in a browser?

Yes. After ingest, Callaba can expose the received stream through browser preview, multiview, player, or delivery workflows, depending on how your Callaba instance is configured.

Which SRT values must match?

The UDP port, stream ID if used, encryption/passphrase if used, and latency policy must be aligned between Matrox and Callaba. A mismatch in one of these values can stop the stream from connecting or showing the expected source.

What latency should I use?

Start with 120 to 500 ms for normal internet contribution and increase it if the network is unstable. Very low latency can work on clean networks, but it gives less room for jitter and packet recovery.

Can I use SRT encryption?

Yes. Use the same passphrase and encryption setting on both sides. SRT passphrases are commonly required to be 10 to 79 UTF-8 printable characters.

Why does the stream connect but show no picture?

The transport may be connected while the media settings are still wrong. Check the video input, codec profile, resolution, audio settings, and whether the Matrox output profile is actually active.

Final practical rule

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

Try Callaba Gateway with your Matrox encoder

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

Learn more about SRT ingest Open multiview demo