YoloBox Extreme Workflow for SRT, RTMP, NDI, and Cloud OBS

What changes with YoloBox Extreme

YoloBox Extreme is the bigger version of the portable switcher-encoder idea. YoloLiv's official page lists eight HDMI inputs, up to 4K60 stream or record, ISO recording options, a long built-in battery claim, six NDI inputs, Wi-Fi 7, built-in battery and 4G LTE, and support for connecting HDMI, USB cameras, NDI, SRT, and RTMP sources. YoloLiv's FAQ also says the device supports wireless connections such as NDI, SRT, RTMP, RTSP, and web page sources, plus Wi-Fi, Ethernet, SIM card, and USB dongle network options.

That is a lot of power for streamer events, but it also raises the stakes. If one field device owns local switching, audio, recording, network bonding, remote sources, graphics, and direct platform destinations, the operator has many ways to accidentally make the public stream fragile. The device can be strong and still need a cloud operating layer.

The clean StreamableRun workflow is YoloBox Extreme as the field production source, StreamableRun as the broadcast control room. Let YoloBox switch the local cameras and send a clean program feed by SRT or RTMP. Let Cloud Hosted OBS handle viewer-facing scenes, fallback, clips, destination routing, platform settings, monitoring, and remote producer handoff.

Use the device for the field job

YoloBox Extreme is most useful when the field side needs multiple cameras and one local operator. Think tournaments, church events, local sports, creator houses, pop-up interviews, conventions, workshops, music rooms, live selling, and outdoor productions where a laptop plus separate monitor plus capture cards would be annoying. The box can make the field side cleaner.

The field job is not the whole broadcast. The field job is inputs, switching, local monitoring, maybe local ISO or program recording, and one stable contribution feed into StreamableRun. The broadcast job is the public scene state, overlays, fallback, destination profiles, platform-specific output, and producer recovery. Keep those jobs separate and the setup becomes easier to reason about.

If you use YoloBox Extreme to send directly to every platform, the field operator becomes the destination operator too. That can be fine for a small single-person stream. It is not the setup I would choose for a sponsored event, group stream, or YouTube/Twitch/Kick multistream where a remote producer needs authority.

• Field box owns local HDMI, USB, NDI, SRT, and RTMP inputs.
• Field box owns local switching and program feed creation.
• StreamableRun owns Cloud OBS scenes, fallback, clips, overlays, and destinations.
• Producer owns public output and recovery decisions.
• Moderator owns viewer playback checks and timestamped issue reports.

SRT contribution path

SRT is the path to test when the YoloBox program feed needs better network behavior than plain RTMP. YoloLiv published a recent SRT explainer for YoloBox workflows, and the broader SRT model still depends on matching caller and listener roles, UDP paths, latency, and receiver behavior. Do not wing this during the event.

For StreamableRun, create a dedicated SRT ingest for the YoloBox Extreme program feed. Decide whether the YoloBox acts as caller to the cloud listener, then write down the exact URL, port, latency, and passphrase if used. Test from the same network route: venue Ethernet, bonded cellular, Wi-Fi, or router stack. Then cut the source while Cloud OBS is live on a private output and confirm fallback works.

Use SRT because it solves a contribution problem, not because it sounds advanced. If the venue blocks UDP, the setup fails. If latency is too low, the stream may artifact under jitter. If the producer cannot tell connected from reconnecting, the workflow is not ready.

• Create a named StreamableRun SRT ingest for the YoloBox program feed.
• Confirm caller/listener mode and UDP path before the event.
• Set latency based on route stability, not pride.
• Test reconnect while Cloud OBS cuts to fallback and returns to main.
• Keep an RTMP profile or backup source ready in case SRT is blocked at the venue.

RTMP path for simple output

RTMP is still useful because it is easy to understand and widely accepted. For many YoloBox Extreme events, the right first test is custom RTMP output from the YoloBox to StreamableRun, then StreamableRun to the final destinations. This keeps the field device on one contribution job while Cloud OBS handles the audience-facing output.

The mistake is sending direct RTMP from the YoloBox to every platform because the menu allows it. Direct multistreaming from the field box makes the weakest network point responsible for every destination. It also spreads platform keys and output profiles into the field kit. If Twitch needs one profile, YouTube needs another, and Kick has a stricter H.264 shape, the field operator should not be changing that while cameras are live.

Use RTMP into StreamableRun when the network is stable enough and the team wants fewer moving parts. Then let Cloud OBS output platform-specific profiles or a conservative shared output. If a platform rejects the final stream, the producer fixes destination output in StreamableRun instead of rebuilding the YoloBox event.

• Use RTMP for controlled venue networks and straightforward contribution paths.
• Keep the YoloBox output below the lowest stable upload the venue can hold.
• Store final platform keys in StreamableRun where the producer can own them.
• Test one private destination before adding the full multistream plan.
• Use direct platform output from YoloBox as a backup only when the runbook says so.

NDI inputs are local production, not a WAN shortcut

YoloBox Extreme's NDI input support is useful when cameras or computers are already on a production network. It can reduce cable mess and pull in sources that would otherwise need capture hardware. NDI's own overview describes it as a video-over-IP standard for systems to identify and communicate with each other over IP, with real-time video, audio, and metadata.

That does not mean NDI belongs across every network. Treat NDI as a local production tool unless you have a carefully designed remote path. Wi-Fi congestion, router isolation, discovery issues, and bandwidth spikes can make NDI sources unreliable. If the YoloBox is pulling several NDI sources, test with all of them active, not one at a time in an empty room.

Once the YoloBox has built the program feed, send that one program feed to StreamableRun. Avoid sending every raw NDI source to the cloud unless the show truly needs cloud-side switching of each camera. The more raw sources the cloud producer must manage, the more the runbook needs to justify it.

• Use NDI for local cameras, computers, and IP sources on a controlled production network.
• Test NDI discovery after router restarts and camera reconnects.
• Watch total network load when several NDI sources are active.
• Prefer one YoloBox program feed into StreamableRun for most field events.
• Use separate cloud ingests only when the remote producer must switch raw sources.

Recording and replay do not replace fallback

YoloBox Extreme's recording and replay-oriented features can help events, especially sports and multi-camera shows. Use them for what they are good at: local archive, edit recovery, instant replay, or ISO safety when the field operator needs it. Do not confuse recording with live recovery.

If the YoloBox program feed drops, a local recording may still be fine, but viewers cannot see that recording unless the live workflow has a fallback. Cloud OBS should have a clips scene, BRB scene, technical slate, backup source, and a producer who can switch quickly. A local ISO file helps after the event. A Cloud OBS fallback helps during the event.

Also decide where replay audio lives. If a replay comes from the YoloBox program, Cloud OBS should know whether it includes audio, whether browser-source alerts should be muted, and whether the producer can talk over it. Audio mistakes make replays feel broken even when video looks sharp.

• Use local recording for edit recovery and proof of what happened in the field.
• Use Cloud OBS fallback for live viewer recovery.
• Test replay audio against Cloud OBS alerts, music, and microphone sources.
• Keep a technical slate that does not depend on YoloBox output.
• After the event, compare local recording with platform archive to find routing problems.

StreamableRun scene plan

The Cloud OBS scene plan should be simple because YoloBox is already doing a lot. Main Program, Backup Source, Clips, Technical Slate, Sponsor Slate, Destination Test, and Producer View cover most serious events. If the field box is switching cameras, Cloud OBS does not need to mirror every camera angle unless the remote producer has a specific switching role.

Put cloud-only elements in Cloud OBS: chat, alert overlays, sponsor lower thirds, clips player, vertical framing, destination-specific bugs, and fallback scenes. Keep field-only elements on YoloBox: local camera switching, local audio mix, local replay, and field monitoring. If both layers try to own the same graphic or audio source, troubleshooting becomes slow.

Write a return rule. If YoloBox reconnects after failure, the producer should not instantly cut back to main. Wait until StreamableRun preview is stable, audio meters look right, and a public platform preview is clean. Returning too early creates a second outage after the first one.

• Main Program: YoloBox feed as the primary source.
• Backup Source: phone, local OBS, second encoder, or static venue feed.
• Clips: safe content for longer recovery windows.
• Technical Slate: clear status without showing private dashboards.
• Destination Test: private scene for checking output before going public.

Producer handoff checklist

The handoff needs to be practical. YoloBox event name, StreamableRun ingest name, protocol, bitrate, resolution, audio owner, local recording owner, fallback scene, backup route, destination list, and recovery authority. If the YoloBox operator and StreamableRun producer are different people, write that line in bold in the runbook.

Run the rehearsal with people in their real seats. Field operator switches cameras and watches the YoloBox. Producer watches StreamableRun and destinations. Moderator watches the public page. Then force the common failures: unplug a camera, mute audio, drop the YoloBox output, switch network, and restart the feed. Every recovery should end with a timestamped note.

StreamableRun is the best default for YoloBox Extreme workflows when the stream matters because it separates the powerful field box from the public broadcast contract. YoloBox can do local production. StreamableRun keeps the live output recoverable with Cloud Hosted OBS, fallback scenes, destinations, monitoring, and remote producer control.

• Confirm who can touch YoloBox settings during the live show.
• Confirm who can switch Cloud OBS scenes and destinations.
• Confirm who watches Twitch, Kick, YouTube, or custom RTMP playback.
• Confirm what happens if YoloBox output drops for 10 seconds, 60 seconds, and 5 minutes.
• Confirm platform keys are stored in the right place and removed from temporary devices after the event.

Other resources

Use these pages to verify current YoloBox Extreme capabilities, YoloBox SRT behavior, platform output requirements, SRT protocol behavior, NDI behavior, and StreamableRun production features before building an event workflow.