Magewell Ultra Encode AIO to StreamableRun: SRT, RTMP, and NDI HX Workflow

The direct answer

Magewell Ultra Encode AIO is a good fit when a production needs a dedicated HDMI or SDI encoder that can send a clean contribution feed into StreamableRun. Magewell lists HDMI and SDI input in one unit, 4K encoding and streaming from HDMI, multi-protocol streaming, file recording, H.264, H.265, NDI HX2, NDI HX3, RTMP, RTMPS, SRT, RTSP, RTP, HLS, and other protocol support.

For StreamableRun, use Ultra Encode AIO as the contribution encoder, not as the entire broadcast plan. Send the camera, switcher, or program feed to StreamableRun over SRT or RTMP. Let Cloud Hosted OBS handle scenes, overlays, fallback, clips, destinations, monitoring, and remote producer handoff.

This is the right shape for small venues, tournaments, camera crews, education streams, houses of worship, sports, and paid productions where a phone app feels too fragile but a full broadcast truck is not the job. The encoder creates a stable field or venue feed. StreamableRun turns that feed into an operable public show.

Why a dedicated encoder changes the workflow

A dedicated encoder changes the failure shape. A phone app carries camera, battery, screen, mobile data, heat, and encoder work in one device. A laptop OBS source carries operating system updates, plugins, browser sources, and local user behavior. A hardware encoder can narrow the job: receive video, encode it, and send it to the server.

That narrower job is useful, but it does not remove production needs. The public stream still needs fallback scenes, destination control, audio checks, overlays, clips, and a producer who can recover the show without touching the encoder. That is why Ultra Encode AIO to StreamableRun is stronger than Ultra Encode AIO directly to every public destination for important events.

Think of the encoder as the clean pipe from the venue to the cloud. Think of StreamableRun as the control room. If the pipe has trouble, the control room should still have a slate, clips, backup ingest, and destination controls.

• Use the encoder for contribution, not every public production decision.
• Use StreamableRun for Cloud OBS, scenes, fallback, destinations, and remote control.
• Use a backup source when the event has sponsor, ticket, or audience value.
• Use recording on the encoder for local recovery when that fits the job.
• Use the public platform preview to verify the final stream, not only the encoder status page.

SRT, RTMP, RTMPS, or NDI HX

Magewell's product page lists several protocol families, but not every protocol should be used for the same leg. SRT and RTMP/RTMPS are the most practical contribution choices into a cloud production workflow. NDI HX is useful for IP production and low-bandwidth NDI environments, especially on a managed local network. RTSP and HLS can be useful in other workflows, but they are usually not the first choice for a live contribution feed into Cloud OBS.

Use SRT when the path needs resilience and the team can test listener or caller mode, port behavior, latency, passphrase, firewall, and reconnect behavior. Use RTMP or RTMPS when simple custom destination compatibility matters more. Use NDI HX locally when the encoder is part of an NDI production network, then decide whether to bridge or convert that local production into StreamableRun through a tested ingest.

Do not choose a protocol because it looks advanced. Choose it because the producer knows how it fails and how to recover it. A tested RTMP profile beats an untested SRT profile on show day.

• SRT: best when network recovery matters and settings are rehearsed.
• RTMP: simplest contribution path for many custom ingest workflows.
• RTMPS: useful when the endpoint supports secure RTMP-style ingest.
• NDI HX: good inside IP production networks, not a default public ingest route.
• RTSP or HLS: useful in specific monitoring or distribution cases, but not usually the first contribution choice.

Check resolution, bitrate, and dual stream behavior

Magewell's Ultra Encode AIO tech specs list main-stream resolution and frame-rate combinations up to 4096x2160 at 30 fps and 1920x1080 at 60 fps, plus bitrate ranges for NDI HX3 and other outputs. Those specs are useful, but the live setting should be based on the whole route, not the highest supported number.

If the event output is 1080p60, do not send 4K into the cloud just because the encoder can. If the venue network is unstable, do not run at the top of the bitrate range because a speed test looked good once. If the output is going to Kick, Twitch, YouTube, and a sponsor custom RTMP endpoint, the safest shared profile may still be H.264 at a platform-friendly resolution and bitrate.

Dual stream behavior can be useful for monitoring or secondary paths, but it must be documented. The producer should know which profile goes to StreamableRun, which one is local, and which one is a backup. Unnamed profiles are how teams change the wrong output during a live problem.

• Choose output resolution based on the public show, not device maximums.
• Leave bitrate headroom for network variation.
• Use H.264 for the broadest mixed-platform compatibility.
• Use HEVC only when the full path supports it.
• Label main and sub streams so the producer knows which feed matters.

Recommended StreamableRun setup

Create a dedicated StreamableRun ingest for the Ultra Encode AIO. Name it by device and protocol, such as Magewell SRT Main or Magewell RTMP Venue. Then build a Cloud OBS scene collection around that source: main program, fallback, technical slate, clips or BRB, backup source, and destination test scene.

Keep the local encoder configuration boring. One input, one output profile to StreamableRun, one recording plan if needed, and a tested network path. If you also need local NDI HX, local monitoring, or secondary output, document it separately. Do not let a flexible encoder become a mystery box.

In StreamableRun, keep platform destinations separate from the encoder. Twitch, Kick, YouTube, and custom RTMP keys should be managed in the cloud production workflow. That lets the producer restart or edit a destination without asking the venue tech to touch the Magewell web UI.

• One StreamableRun ingest per primary Magewell output.
• One main Cloud OBS scene for the encoder program feed.
• One fallback scene that does not depend on the encoder.
• One backup ingest for a phone, local OBS, or second encoder.
• One producer runbook with protocol, bitrate, source, audio, and destination ownership.

Audio and embedded source checks

Hardware encoder problems often show up as audio confusion. HDMI or SDI embedded audio may be present, missing, too quiet, doubled, or mapped differently than the operator expects. Ultra Encode AIO can encode up to eight channels of AAC audio according to Magewell's overview, but the public stream still needs a clear stereo or supported audio plan.

Before the event, test the camera or switcher audio into the encoder, the encoder audio into StreamableRun, and the Cloud OBS audio into each destination. If Cloud OBS adds clips or browser-source audio, decide whether those are mixed in the cloud or whether the encoder feed is the only program audio.

Use a spoken slate and a clap test. Say the source name, clap once, switch scenes, play a clip, cut to fallback, return to main, and listen on a public viewer device. If the audience hears echo, delay, missing channel, or clipping, fix it before you touch bitrate.

• Confirm embedded audio from HDMI or SDI before starting the stream.
• Check whether Cloud OBS adds any extra audio sources.
• Test browser-source and clip audio separately from the encoder program.
• Keep fallback audio intentional: music, silence, or slate, not random venue audio.
• Document who is allowed to mute the encoder feed during a live recovery.

Monitoring during the stream

The encoder status page is only one layer. Monitor the Ultra Encode AIO, StreamableRun ingest, Cloud OBS output, destination dashboards, and public viewer page. If the encoder says it is sending but StreamableRun is not receiving cleanly, the problem is not solved. If StreamableRun looks healthy but YouTube or Kick is unhappy, the producer needs destination-specific action.

Magewell's support material says Ultra Encode can stream multiple sessions over protocols such as SRT Caller and Listener or RTMP and RTMPS, subject to limits. Multiple sessions can be useful, but they also create monitoring responsibility. If StreamableRun is the production layer, avoid sending unnecessary direct platform sessions from the encoder during important shows.

Have one person watch technical state and one person watch viewer experience when possible. The technical screen tells you where the feed is going. The viewer page tells you what the audience got.

• Monitor encoder input, output, bitrate, and network state.
• Monitor StreamableRun ingest and Cloud OBS scene health.
• Monitor destination dashboards for platform-specific warnings.
• Monitor a normal viewer device for audio, delay, buffering, and framing.
• Log the first point where a problem appears so recovery is targeted.

Failure drills

Run the drills before the show. Disconnect the HDMI or SDI input. Stop the encoder output. Change network path. Restart the StreamableRun destination. Switch Cloud OBS to fallback. Return to main only after the public viewer page is clean. These drills teach the team what each failure looks like.

If the encoder loses input but keeps streaming a frozen or black frame, the producer needs to cut to fallback. If the encoder output stops entirely, StreamableRun should keep the public show on fallback or a backup source. If one destination rejects the output, the producer should fix that destination in StreamableRun without changing the encoder.

The goal is not to prove the Magewell never fails. The goal is to prove the production can recover when any single part has a bad minute.

• Input failure: camera or switcher stops feeding the encoder.
• Network failure: encoder output cannot reach StreamableRun.
• Cloud failure drill: Cloud OBS switches to fallback while source returns.
• Destination failure: one platform needs a restart or settings check.
• Backup drill: second source goes live while the Magewell path is fixed.

Other resources

Use these resources to verify Magewell Ultra Encode AIO protocol support, specifications, multi-session behavior, SRT details, and StreamableRun production features before building an event workflow.