YoloBox Ultra SRT and RTMP Setup for StreamableRun Cloud OBS

The direct answer

YoloBox Ultra is useful when a creator wants a portable production box with HDMI inputs, local switching, monitoring, recording, IP sources, network options, and RTMP or SRT output. YoloLiv's product page lists four HDMI inputs, USB inputs, SRT, RTMP, and NDI HX sources, output over Wi-Fi, 4G LTE, or Ethernet, and streaming to multiple destinations using RTMP or SRT.

For a StreamableRun workflow, the best split is YoloBox Ultra as the field production encoder and StreamableRun as the cloud broadcast layer. Let YoloBox handle local sources and the first contribution feed. Let Cloud Hosted OBS handle the public scene collection, fallback, clips, destination routing, monitoring, and producer handoff.

That matters because YoloBox can do a lot. The fact that it can switch, record, bond, pull IP sources, and stream to multiple destinations does not mean it should own every part of a serious show. The field box should have a clear job: send a stable program feed into StreamableRun.

What matters in 2026

Portable switcher-encoders are getting closer to full mini production systems. That is great for streamers, but it also creates messy workflows. If the same device owns camera switching, audio, local recording, overlays, cellular bonding, destination keys, and remote control, one field mistake can affect the whole public stream.

The safer operator model is layered. YoloBox Ultra handles the local stack: HDMI cameras, local assets, ISO or program recording where needed, and network contribution. StreamableRun handles the cloud stack: Cloud OBS, fallback scenes, destination settings, vertical or horizontal output decisions, and the remote producer's view of the show.

This layered setup is especially useful for tournaments, pop-up interviews, conventions, outdoor activations, creator meetups, cooking streams, workshops, and live selling shows where one person may carry the hardware while another person manages the public broadcast.

• Use YoloBox Ultra when you need several local inputs in a portable kit.
• Use StreamableRun when the public show needs remote control and fallback.
• Use SRT when contribution reliability matters and the path is tested.
• Use RTMP or RTMPS when simple custom destination setup matters more.
• Keep direct platform multistreaming on the field box as a backup, not the default for important shows.

YoloBox to StreamableRun over RTMP

RTMP is the first setup most teams should test because it is easy to reason about. Create a StreamableRun ingest for the YoloBox program feed. In YoloBox, create a custom RTMP or RTMP(S) destination using the StreamableRun server URL and stream key. YoloLiv's own RTMP setup material describes adding a custom RTMP(S) destination and manually entering the stream URL and stream key.

Then watch the path in this order: YoloBox preview, StreamableRun ingest, Cloud OBS scene, platform dashboard, public viewer page. Each layer catches different problems. The YoloBox preview catches camera and switching issues. StreamableRun catches ingest state. Cloud OBS catches scene and audio mix problems. The public page catches what viewers actually receive.

Do not use platform bitrates as the only target. Kick's current help page lists CBR and bitrate guidance up to 8,000 kbps, while YouTube's live encoder docs list wider ranges for H.264, H.265, and AV1. The YoloBox-to-StreamableRun contribution should be chosen by field network stability first, then the StreamableRun output should be matched to each destination.

• Create one StreamableRun ingest for the YoloBox program feed.
• Save custom RTMP details inside YoloBox before arriving at the venue.
• Test one destination from StreamableRun before testing all destinations.
• Keep the YoloBox output bitrate below the lowest stable field upload margin.
• Use Cloud OBS fallback scenes instead of stopping the public stream when the field box reconnects.

YoloBox to StreamableRun over SRT

SRT is worth testing when the field network is variable and the team wants a more resilient contribution path than plain RTMP. YoloLiv has a YoloBox Ultra SRT setup guide that covers adding SRT as a source and destination. It notes caller/listener behavior when adding SRT sources, which is exactly the kind of detail producers must understand before show day.

With SRT, write down the mode, port, latency, passphrase if used, and firewall expectations. The producer should know what the YoloBox shows when SRT is connected, reconnecting, or failing. The field operator should know whether to restart the event, restart the destination, switch network, or leave the box alone while Cloud OBS holds fallback.

Do not set SRT latency as low as possible just because the number feels better. OBS's SRT guide explains that latency should be large enough for the network round trip and that it is one of the most important URL options. A slightly slower but stable field contribution is usually better than a fast feed that collapses every time the network gets busy.

• Confirm caller and listener mode before leaving for the event.
• Test the venue firewall and mobile network path.
• Choose latency for packet recovery, not only for speed.
• Confirm StreamableRun ingest behavior when YoloBox reconnects.
• Keep a tested RTMP fallback profile in the YoloBox.

Bonding does not remove the need for fallback

YoloLiv describes YoloBox Ultra bonding across multiple connection types, including cellular, Wi-Fi, Ethernet, and USB modems. Bonding is valuable because it can reduce dependence on one weak path. It is not a promise that the show will never hit trouble.

Real locations are messy. A convention center can have congested cellular. A venue Ethernet port can be behind a captive portal. A USB modem can be on the same carrier as the internal SIM. Wi-Fi can look strong while upstream quality is bad. Bonding gives the field box more options, but the public broadcast still needs a recovery layer.

That is where StreamableRun matters. If the YoloBox program stalls, Cloud OBS can cut to clips, a BRB scene, a sponsor slate, or a safe camera. The field operator can fix connections without the streamer yelling settings into chat. The producer can keep the public output alive while the field contribution recovers.

• Use different carriers when possible instead of duplicating one congested carrier.
• Test Ethernet, Wi-Fi, SIM, and USB modem paths separately before bonding them.
• Watch upload stability over time, not only a one-time speed test.
• Keep StreamableRun fallback scenes ready even when bonding looks healthy.
• Have a non-YoloBox backup ingest for paid events or sponsored streams.

Scene design in Cloud OBS

Do not rebuild the same switching job twice. If YoloBox is already switching local cameras, Cloud OBS should not also contain every raw camera angle unless you have a specific reason. Bring in the YoloBox program as the main source. Then add the cloud-only parts: alerts, chat, clips, remote guest overlays, vertical output framing, and fallback scenes.

Keep cloud scenes stable. A main scene, a fallback scene, a technical slate, a clips scene, a sponsor or event slate, and a backup source scene are enough for most YoloBox shows. If you add ten extra browser sources and animated overlays, you may make the recovery path harder for the producer.

The producer needs buttons that match real problems. Main for normal program. Fallback for contribution failure. Slate for planned breaks. Backup source for a phone or local OBS feed. Destination controls for Twitch, Kick, YouTube, or custom RTMP. Anything else should earn its place.

• Keep the YoloBox program feed as the primary Cloud OBS source.
• Use Cloud OBS for overlays that remote producers must control.
• Keep fallback independent of the YoloBox feed.
• Make the backup source visible in a separate scene before the event.
• Label scenes by action, not by inside jokes or version numbers.

Audio and recording decisions

YoloBox Ultra can be part of the audio and recording plan, but decide what each recording is for. Local recording on the field box can be useful for edit recovery. A platform VOD or a separate recording of the finished program can be useful for the public archive. They are not the same thing.

Audio should have one clear master. If YoloBox receives camera audio, a mixer feed, and a wireless mic, decide whether the field operator mixes final audio before StreamableRun or whether Cloud OBS adds final browser-source audio on top. Doubling the same microphone through both paths can create echo or comb filtering. Missing browser-source audio can make alerts or clips feel broken.

Test the audio path with movement and scene changes. Switch a YoloBox camera, trigger a Cloud OBS clip, cut to fallback, and return. If the producer hears a delay or double source, fix it in rehearsal. Audio problems are harder to explain to viewers than video softness.

• Choose one master audio path for the live program.
• Use local recording for field recovery, not as proof the public stream was clean.
• Test clip and browser-source audio inside Cloud OBS.
• Check the public destination from headphones on a normal device.
• Document whether the producer is allowed to mute field audio from Cloud OBS.

Producer handoff

The producer handoff needs names, not guesses. The runbook should list the YoloBox event name, StreamableRun ingest name, primary protocol, backup protocol, expected resolution and bitrate, main scene, fallback scene, backup source, destination order, and who owns audio.

During a failure, the local YoloBox operator fixes the box and the network. The StreamableRun producer protects the public output. The streamer keeps hosting if they can. This division matters because everyone under pressure wants to touch the wrong control.

Do a final private test with the exact people. Have the YoloBox operator start and stop the feed. Have the producer switch scenes. Have a moderator watch the public page. Then write down what happened. A technical plan that only one person understands is not a plan yet.

• Field operator owns YoloBox sources, network, and local audio.
• Cloud producer owns StreamableRun scenes, fallback, and destinations.
• Moderator owns public viewer checks and timestamped notes.
• Streamer owns the show and should not be the first recovery contact.
• Everyone knows the backup path before the stream starts.

Other resources

Use these resources to verify current YoloBox Ultra capabilities, SRT setup behavior, RTMP setup behavior, and StreamableRun production features before changing a live workflow.