Haivision Makito X1 Rugged SRT setup: compact field contribution with Callaba Gateway
Makito X1 Rugged direct-SRT field guide
Carry the picture and its mission context to a visible Callaba ingest
The Haivision Makito X1 Rugged is an unusually compact encoder, but its useful output is larger than the video frame. It can encode H.265/HEVC and H.264/AVC, capture KLV or Cursor on Target metadata, place metadata in an MPEG transport stream, and send that transport over SRT. A dependable Callaba workflow therefore proves three things separately: the sensor image, the SRT session, and the metadata that gives the image operational meaning.
The recommended first build
Use one Makito X1 Rugged output in SRT Caller mode and one Callaba SRT Server in Listener mode. Create and start the Callaba listener, open its chosen UDP port, then point the encoder at the reachable Callaba address and that port. Start with one video encoder, the required audio, and one known metadata source. Add a second codec, redundant path, or extra metadata inputs only after that baseline passes.
Direct SRT is appropriate here: the X1 itself exposes Caller, Listener, and Rendezvous modes, SRT encryption, Stream ID access control, live statistics, Network Adaptive Encoding, and SRT path-redundancy controls. Match each option to what the receiving endpoint actually supports instead of enabling every feature during the first connection.
The moving markers illustrate logical video and metadata carriage; they do not represent measured throughput or prove metadata interpretation. Animation stops when reduced motion is requested.
Use the X1 features deliberately
Haivision documents two flexible encoding cores in the Makito X1 Rugged. That makes simultaneous HEVC and H.264 output possible when one remote system values bandwidth efficiency and another requires AVC compatibility. It does not mean every mission needs two streams. Each additional encode and destination consumes network and receiver resources, so build only the branches with named consumers.
| Decision | X1-specific choice | Proof to collect |
|---|---|---|
| Video codec | HEVC for a compatible, bandwidth-conscious chain; H.264 where downstream compatibility requires it; both only for distinct consumers. | A decoded picture at every intended destination, using representative motion and the deployed profile. |
| Metadata source | KLV extracted from HD-SDI, KLV or CoT received over a configured UDP input, or KLV/CoT received on the Rugged serial port. | Advancing timestamps and changing known fields at the encoder, then the same expected values after transport. |
| Metadata filtering | Include only the tags needed by the exploitation workflow; use decimation only when its effect is understood. | An approved before-and-after tag inventory, including required security and mission fields. |
| SRT identity | A documented Stream ID when receiver access control or routing uses one. | The exact non-secret identifier visible on both ends; no keys embedded in a shared screenshot. |
| Recovery budget | Latency based on the measured round-trip path, then NAE or redundant transport only when the design calls for it. | Stable media through a controlled impairment, with recovery behavior recorded in the runbook. |
The encoder can combine multiple metadata sources in a transport stream. Treat that as an engineering choice, not a shortcut. When two sources can populate the same semantic field, establish precedence and filtering upstream. A downstream operator should never have to guess whether a position, timestamp, or classification value came from SDI, serial, or the network.
Configure the direct SRT path in a controlled order
Inventory the deployed appliance
Record that the unit is the Makito X1 Rugged, its installed firmware, enabled licenses, power and network interfaces, and the Haivision guide that matches that release. Do not copy settings from a Makito X4 or a non-rugged Makito simply because the screen looks familiar.
Prove the source before transport
Confirm input lock, correct raster and frame rate, representative motion, and the intended audio. Start the chosen video encoder and verify its local status. If two encoding cores are required, validate each profile independently.
Build the metadata source
In the Makito web interface, open Streaming and the Metadata area. Select or create the actual input type, set KLV or CoT as applicable, name it clearly, apply only the approved filtering or insertion policy, and start it. Watch statistics while deliberately changing a known field.
Prepare the Callaba listener
Follow the Callaba SRT Server user guide to create one receiving server. Assign a reachable address and unique UDP port, start it, and permit that port through the cloud security group, host firewall, and any intervening policy.
Create the X1 output
Under the encoder Outputs area, add an output, select TS over SRT, attach the intended video, audio, and metadata sources, and choose Caller. Enter the Callaba host and destination port. Configure latency, Stream ID, encryption, and passphrase to the same contract used at Callaba.
Observe transport before adding branches
Start the output. Confirm the X1 reports STREAMING rather than CONNECTING, then confirm Callaba sees a sustained incoming bitrate and plausible transport statistics. If the socket is established but the bitrate is zero, return to the selected content and encoder state.
Prove the usable result
Place the source in Callaba Multiview and make a short recording. Check moving video and audio there, then use an appropriate metadata-aware analyzer or downstream system to confirm the KLV elementary stream and required fields survived. A Multiview tile proves visible media, not KLV semantics.
Keep metadata evidence separate from video evidence
The X1 documentation says KLV or converted CoT is incorporated into the metadata elementary stream of the standard MPEG transport stream. That distinction matters. A picture can decode perfectly even when the metadata source is stopped, filtered too aggressively, associated with the wrong output, or unreadable to the next system.
For a rehearsal, generate a harmless, recognizable metadata change and record its time. Confirm the X1 metadata statistics react. Capture the same time window at the receiving boundary, and inspect it with the tool used by the actual mission workflow. Compare the video timestamp, KLV timing, required tags, and classification policy. Do not infer preservation from file size or from a green SRT status.
Prove recovery without confusing it with redundancy
SRT latency reserves time for retransmission and adds delay. Haivision’s current X1 settings describe a minimum related to measured RTT, but the correct production value must also cover real jitter and the end-to-end delay budget. Begin from actual path measurements, run long enough to encounter ordinary variation, then rehearse the failure you expect.
Network Adaptive Encoding can change video bitrate to respond to measured throughput without rebuilding the stream. SRT path redundancy can transmit equivalent content across separately defined paths. These are different mechanisms. NAE changes the encode to fit capacity; redundancy sends protected copies over more than one network path. Confirm receiver interoperability and genuine path independence before enabling the latter. Two logical paths on one switch, uplink, or power rail are not two independent failure domains.
Troubleshoot the layer that stopped proving itself
The output remains CONNECTING
Compare Caller and Listener roles, destination address, UDP port, and firewall state. Check name resolution from the encoder network. Then compare Stream ID, encryption mode, and passphrase exactly; reachability alone does not satisfy access control.
SRT streams but no image appears
Inspect the selected video encoder and its input lock. Confirm that the output references the intended encoder, and verify codec support in the receiving branch. Do not change metadata settings while isolating a video fault.
Video arrives without KLV
Verify the metadata source is started and its counters advance. Check that this source was included in the output and that the expected sync or async carriage was selected. Inspect the received transport with a metadata-aware tool.
Metadata exists but fields are wrong
Trace the value to SDI, UDP, or serial input. Review tag filters, decimation, any static insertion, and CoT conversion. Preserve a raw upstream sample so a transport problem is not blamed for incorrect source data.
Artifacts appear during congestion
Correlate X1 SRT graphs with Callaba bitrate, RTT, loss, and reconnect events over the same clock window. Increase the recovery budget or reduce load only after identifying whether capacity, loss bursts, or route changes are responsible.
The alternate path adds no resilience
Disconnect each physical route separately. Verify both were active, the receiver accepts the configured redundancy method, and no shared gateway or carrier fails both. Keep the single-path configuration available as a diagnostic baseline.
Continue the received feed inside Callaba
The Callaba SRT Server product page describes the receiving, transport-health, Multiview, recording, restream, and playback workflow. Use the Haivision and Callaba workflow hub for the broader model map. Once the manual build is stable, repeatable SRT server lifecycle tasks can be designed against the Callaba SRT Server API; keep the human-readable source-to-port and source-to-route map as the operational authority.
Official Haivision references
- Makito X1 Rugged product page — codec, dual-core, rugged, full-motion-video, and metadata positioning.
- Makito X1 Rugged stream settings — SRT modes, path controls, NAE, latency, and security fields.
- Makito X1 metadata capture — SDI, UDP, and Rugged serial metadata inputs and MPEG-TS association.
- Makito X1 SRT path redundancy — supported redundant-path configuration and receiver expectations.
Choose the receiving environment, then rehearse the whole evidence chain
Start with one X1 source and one listener. Preserve the configuration record, a decoded-media sample, transport statistics, and a metadata-aware verification before the system is released to operations.