AJA HELO Plus Workflow for RTMP, SRT, Recording, and Cloud OBS

Where HELO Plus fits

AJA HELO Plus fits streamers and small production teams that want a dedicated hardware encoder for an SDI or HDMI source, plus local or network recording, without running the whole broadcast from a laptop. AJA describes it as a compact H.264 streaming and recording appliance with SDI and HDMI I/O, up to 1080p60 streaming to a CDN, simultaneous recording, two separate streaming destinations, front-panel controls, a web UI, and recording to SD card, USB storage, or network storage. AJA's 2026 product news also lists HELO Plus v2.1.5 with RTMP audio, lip sync, and multicast improvements, so this is still an actively maintained workflow to test rather than an old box to trust blindly.

That is useful for a real event, but the best StreamableRun setup is not HELO Plus straight to every public platform. Use HELO Plus to make a clean contribution feed, send that feed into a named StreamableRun ingest, then let Cloud Hosted OBS run the public show. Cloud OBS can hold overlays, fallback scenes, backup ingests, clips, destination keys, monitoring, and producer handoff while HELO Plus focuses on encoding and recording.

This split matters during recovery. If the HDMI camera gets unplugged, if the venue network changes, or if the HELO Plus profile needs a restart, the public stream should not have to end. StreamableRun gives the producer somewhere to cut while the hardware source is fixed.

Best use cases

HELO Plus is not the obvious choice for a solo streamer walking around with a phone. It is stronger when there is a fixed camera, venue camera, switcher, SDI feed, HDMI camera, stage program feed, classroom, sports table, podcast set, esports desk, or paid event where local recording matters. It is a source appliance for a planned setup.

YouTube lists HELO Plus among hardware encoders and describes it as a standalone H.264 encoder for reliable live streaming while simultaneously recording to SD cards, USB storage, or network locations. That gives it a clean role in creator production: encode the venue feed and keep a local record. StreamableRun should still manage the show that viewers see.

• Good fit: fixed cameras, switcher program output, stage streams, sports tables, classrooms, podcasts, and small venue events.
• Weaker fit: fully mobile IRL streams, backpack streams, or streams where SRTLA bonding from a phone app is the main need.
• Strong reason to use it: local or network recording needs to happen near the source.
• Strong reason to route through StreamableRun: remote producer control, fallback, destinations, and overlays need to stay flexible.
• Best source label: name by job, such as HELO Stage Program, HELO Desk Cam, or HELO Venue Feed.

RTMP or SRT into StreamableRun

Choose the contribution protocol based on the route, not the device label. RTMP is simple, common, and useful when the HELO Plus is on a stable wired connection and the goal is a straightforward push into StreamableRun. SRT is worth using when the path crosses a less predictable network and the team can rehearse caller/listener mode, latency, firewall behavior, and reconnects.

OBS's SRT guide is a helpful sanity check because it explains the caller/listener relationship and says SRT inputs are commonly carried as MPEG-TS. The SRT protocol draft describes buffer latency, acknowledgements, retransmission, packet loss handling, and encryption. Those are the reasons SRT can be better for contribution. They do not remove the need for fallback.

If you use RTMP, keep the bitrate and keyframe settings platform-safe and easy to monitor. If you use SRT, write down the mode, port, latency, passphrase behavior if used, and expected reconnect action. A hardware encoder should make the production calmer, not create a secret settings puzzle only one person can solve.

• RTMP route: HELO Plus to StreamableRun RTMP ingest, Cloud OBS to public destinations.
• SRT route: HELO Plus to StreamableRun SRT ingest when firewall and latency settings are rehearsed.
• Wired venue: RTMP may be enough if the network is stable and private testing passes.
• Remote or unpredictable network: SRT is worth testing because recovery behavior is part of the protocol design.
• Any route: Cloud OBS fallback should be ready before the source is trusted publicly.

Input and audio planning

HELO Plus can sit in a lot of different chains: camera HDMI, camera SDI, switcher output, converter output, or a venue-provided program feed. Pick one primary path and one backup path. If the input is HDMI from a camera, test cable retention and output resolution. If the input is SDI from a switcher, test embedded audio and format changes. If the input comes from a venue, ask what happens when their operator cuts to graphics or playback.

AJA's specs list two-channel embedded audio over SDI or HDMI at 48 kHz, plus analog stereo input and output. That is good, but it still needs a live check. The most common hardware-encoder issue is not that video fails completely. It is that audio is missing, delayed, doubled, clipped, or coming from the wrong source. Build a Cloud OBS audio check scene and use a normal viewer device during rehearsal.

If the HELO Plus optional 4-channel audio workflow is part of the plan, keep that as a separate advanced test. Do not add multiple audio pairs to a public event unless the destination, Cloud OBS routing, recording, and producer monitoring all agree.

• Confirm the input format before the event starts, especially 1080p60 vs 1080p30.
• Use embedded audio when it is part of the switcher program, but test it in Cloud OBS and at the destination.
• Use analog audio only when the levels and ground noise have been checked under venue conditions.
• Keep a backup audio source ready in Cloud OBS if the hardware encoder audio disappears.
• Log the accepted input format so the venue does not change output mid-show without warning.

Recording is not a replacement for fallback

HELO Plus can record while streaming, and that is genuinely useful. Local or network recording gives the team a copy for highlights, sponsor proof, post-production, or recovery if a platform archive is bad. It does not keep the public stream alive when the live source fails.

Treat recording as a parallel safety feature. The live safety feature is still Cloud OBS fallback inside StreamableRun. If the HELO Plus source drops, the producer should cut away. If the recording keeps going but stream output fails, the producer still needs to know whether the issue is source, StreamableRun ingest, Cloud OBS, or destination. Recording gives you evidence after the moment. Fallback protects viewers during the moment.

Decide storage before the event. SD card, USB storage, network storage, file naming, free space, and who pulls the recording after the show should all be written down. Do not let a full card or network share error become the thing that distracts the operator while live.

• Use HELO Plus recording for archive and post-show recovery.
• Use StreamableRun fallback for public live recovery.
• Check recording media before the event and again after the event starts.
• Keep recording errors separate from live-output errors in the producer log.
• Do not promise a local recording until someone confirms the file after the test.

Cloud OBS scene setup

The HELO Plus source should land in a clean Cloud OBS scene. Start with Main HELO, Backup Source, Fallback, Technical Slate, Clips or BRB, and Destination Test. Keep the hardware feed itself clean. Do not bake every lower third, chat widget, and sponsor bug into the encoder if Cloud OBS can handle it more flexibly.

AJA notes that HELO Plus provides Picture-in-Picture and graphics functionality in hardware. That can be useful for a simple one-box presentation, but be deliberate. If graphics are baked into the source, the Cloud OBS producer cannot remove them quickly. If graphics live in Cloud OBS, the producer can change them per destination, cut them during recovery, or hide them if the source gets messy.

Use hardware PiP for cases where the local operator must produce without a cloud producer. Use Cloud OBS overlays when the event has a remote producer, multiple destinations, chat overlays, sponsor requirements, or a fallback plan.

• Main HELO scene: clean source, safe overlay padding, audio meters checked.
• Backup scene: phone, local OBS, second camera, or prebuilt slate available as another ingest.
• Fallback scene: no dependency on the HELO Plus input.
• Destination test scene: color bars, audio tone or voice check, and readable title.
• Producer notes: which graphics are baked into HELO Plus and which graphics are in Cloud OBS.

Producer runbook

The producer runbook should be short enough to use under pressure. Source name, protocol, expected bitrate, expected audio source, backup source, fallback scene, destination list, and recovery steps. If the HELO Plus stream stops, producer cuts to fallback. If audio drops, producer checks the source meter, Cloud OBS meter, and destination preview in that order. If the destination rejects output, producer does not start changing HELO Plus input settings unless the source itself is broken.

Use StreamableRun as the place where the producer can see and act. A hardware encoder web UI is useful, but it is not the public show. The producer should not need to remote into a venue laptop or call the camera operator for every scene decision.

After the event, keep the runbook notes. Which protocol worked, which bitrate passed, which storage target recorded, which cable was bad, which destination had delay, and which fallback scene viewers saw. That is how the next stream gets easier instead of repeating the same test.

• Level 1: watch HELO Plus source in StreamableRun and platform preview.
• Level 2: if unstable, cut to fallback and keep the public output alive.
• Level 3: check source video, source audio, network, and encoder state separately.
• Level 4: return only after StreamableRun preview and platform preview are clean.
• Level 5: if the hardware path cannot recover, stay on backup source or end deliberately.

Testing checklist

Run the test like the real event. Same camera, same switcher, same cables, same HELO Plus profile, same StreamableRun ingest, same Cloud OBS scenes, same destination, same recording media, same producer. A hardware encoder can pass a five-minute desk test and fail when the venue switches formats, audio changes, or the network drops for ten seconds.

Include forced failures. Pull the camera feed, restart HELO Plus streaming, fill a fake destination with the wrong key during a private test, remove network briefly if safe, and switch Cloud OBS to fallback. The goal is not to break gear. It is to confirm that no single failure turns into a public stream ending.

• Input test: HDMI or SDI format, audio source, embedded audio, analog audio if used.
• Network test: wired path, IP settings, firewall, RTMP or SRT connection, reconnect behavior.
• Recording test: media, free space, file creation, file playback, and naming.
• Cloud OBS test: main scene, fallback scene, backup source, overlays, and audio monitoring.
• Destination test: Twitch, Kick, YouTube, or custom RTMP preview from a normal viewer device.

Other resources

Use these pages to verify current HELO Plus capabilities, YouTube encoder context, SRT behavior, platform output constraints, and StreamableRun production features before building the event route.