Matrox SRT gateway hub: Maevex and Monarch EDGE workflows
More live video workflow notes and product updates.
Matrox family role-selection hub
Maevex and Monarch EDGE solve different parts of professional AV and broadcast transport. Maevex spans AV-over-IP encoding, streaming, recording and control use cases; Monarch EDGE targets remote-production contribution and return feeds. Treating both as a generic Matrox appliance hides the decision an operator actually needs to make.
Written by Iurii Pakholkov, founder of Callaba. Materially reviewed on July 17, 2026 against the official sources listed below.
Choose the correct Maevex and Monarch EDGE workflows
| Path | Operational role | When to choose it |
|---|---|---|
| Maevex 7100 family | AV-over-IP encoding with model-dependent H.264 or H.265 and SRT support. | Choose by exact 7112 model, codec requirement and integration or control-system needs. |
| Monarch EDGE | Remote production, contribution or return feed using SRT and other broadcast transports. | Choose by channel density, ancillary-data, return-feed and remote-production requirements. |
| Legacy Maevex paths | Older 5100/6100-family protocols and roles vary by model. | Never infer SRT from the family name; verify the exact legacy SKU and documentation. |
Keep the source, handoff and Callaba roles explicit
Source-side responsibility
The Matrox appliance owns physical I/O, encoding or decoding, local recording where supported and the source transport configuration.
Transport handoff
The contract is exact family and SKU, codec, channel count, raster, SRT or RTSP role, audio/ancillary data, security and network budget.
Callaba responsibility
Callaba owns the receiving gateway, browser operations view, transport statistics, cloud recording, playback, protocol conversion and routes.
Separate AV-over-IP from remote-production intent
- 1. Read the exact Matrox model number. Maevex 7112A and 7112H differ in codec capability, while older Maevex families have different transport matrices.
- 2. Choose Maevex for the documented AV-over-IP encoding and integration job, or Monarch EDGE for contribution and return-feed workflows. Do not mix their UI instructions.
- 3. Confirm SRT support and role in the current product manual. If an older Maevex path begins with RTSP, document where protocol conversion occurs before Callaba.
- 4. Align codec, channel count, audio, ancillary data, port, Stream ID and encryption with the Callaba endpoint and downstream consumers.
- 5. Test monitoring, a recording artifact and the final route under real network impairment. Keep appliance and Callaba telemetry together in the incident runbook.
After preflight, use the SRT Gateway hub for architecture choices, the SRT Server guide for receiver concepts, Multiview for browser operations, and the SRT API documentation for automation. These shared resources do not replace the model-specific guide linked in the decision table.
Official references reviewed
Capabilities and menu fields can change with hardware revisions, firmware and account entitlements. Recheck the exact model before a production event.
- Matrox Maevex 7100 Series — Official current Maevex family roles and exact-model split.
- Matrox SRT protocol and enabled products — Official list of Matrox product families with SRT support.
- Monarch EDGE S1 technical specifications — Official SRT modes, stream ID, formats and interfaces.
Frequently asked questions
Should I use the Maevex or Monarch EDGE guide?
Use Maevex for an AV-over-IP encoder, streaming, recording or control-system integration path. Use Monarch EDGE for remote-production contribution or return feeds. Confirm the exact SKU before choosing.
Which side originates the SRT connection?
It depends on the supported role selected on the exact Matrox device. Monarch EDGE documents caller, listener and rendezvous modes. Configure Callaba as the opposite peer and verify the UDP path.
When might a Matrox workflow use RTSP before SRT?
Some legacy or model-specific Maevex paths expose different transport sets. If the source produces RTSP, document the component that receives and converts it; do not label the original leg as SRT.
What remains on the appliance and what runs in Callaba?
Matrox handles physical media I/O and hardware encode/decode. Callaba starts at the network ingest boundary and adds common monitoring, recording, playback, conversion and route control.
Can Callaba monitor, record and play the feed in parallel?
Yes, a validated input can support those workflows in parallel when the deployed resources and configuration allow it. Verify each output independently during preflight.
Move from device choice to a tested receiving path
Open the exact-model guide, validate one contribution feed in Callaba, then add recording, monitoring and downstream routes only after the ingest contract is stable.
