Matrox SRT gateway hub: Maevex and Monarch EDGE workflows
More live video workflow notes and product updates.
Matrox family decision
Separate AV-over-IP endpoints from remote-production contribution
Maevex and Monarch EDGE can both appear in an IP-video design, but they do not define the same job. Maevex spans AV-over-IP encoding, streaming, recording and control. Monarch EDGE is oriented toward contribution, return feeds and remote-production paths. Selecting the family by the word “SRT” hides the constraints that actually determine whether the workflow will work.
Callaba begins at the agreed handoff. It receives the exact stream the Matrox system produces, makes transport and decoded media visible, and attaches recording, Multiview or downstream routing only after acceptance.
Use this fork before opening a model guide
Maevex: managed AV-over-IP endpoints
Choose this branch when encoder and decoder endpoints, AV distribution or an existing Maevex estate define the project.
- The current 7100 family needs an exact SKU check.
- 7112A and 7112H differ in codec capability.
- Older 5100 and 6100 transport matrices vary.
Monarch EDGE: remote production
Choose this branch for a contribution or return-feed design where channel density, ancillary data and encoder/decoder direction are part of the plan.
- Confirm the precise encoder or decoder model.
- Plan Caller, Listener or Rendezvous from the network.
- Validate every required channel and return path.
Do not inherit SRT support from a family name
For Maevex, support is model-dependent. The 7112A/7112H distinction and older 5100/6100 differences mean that a generic “Maevex SRT configuration” is unsafe. Inventory the installed endpoint, current software and licensed capabilities first. If an older or model-specific path begins as RTSP, document the protocol-conversion boundary rather than describing the source as native SRT.
Make the handoff visible to both teams
The source-side operator owns input timing, format, audio and the Matrox processing role. The network contract owns addressability, Caller/Listener/Rendezvous selection, latency, Stream ID and encryption where applicable. The Callaba operator owns only the session and downstream jobs created in Callaba.
Run an acceptance test that matches the selected family
Exact model, role, firmware and licensed options are recorded.
Real raster, frame rate, codec profile, audio map and ancillary requirements are tested.
The expected peer remains connected at a plausible bitrate through representative motion.
Multiview, a sample recording and the final route prove decoded media.
For a Maevex AV estate, verify the intended endpoint mapping and any conversion boundary. For Monarch EDGE, run the planned channel count, contribution and return-feed combination. Under controlled impairment, observe which layer reconnects and which requires an operator; do not label an untested alternate route “failover.”
Choose placement from media ownership
Callaba may run in cloud infrastructure or on Linux close to the facility. The correct choice follows reachability, latency, egress, security and operational ownership. If the Matrox endpoint stays on a private AV network, a controlled self-hosted placement may simplify the first handoff. If remote contributors call a public endpoint, cloud placement may be the clearer boundary.
In either design, start with one source and one destination. Fan-out is an operational feature only after the accepted source is stable.
Verify the installed system against Matrox sources
Use Matrox Video’s Maevex 7100 Series overview, Monarch EDGE technical specifications, and SRT protocol guidance. Recheck manuals and release notes for the exact model before production.
