How to Connect a BELABOX Stream Backpack to StreamableRun

What this setup actually connects

A BELABOX backpack solves the field part of an IRL show: camera input, hardware encoding, modem connections, and the rough stretch between a moving streamer and the cloud. StreamableRun solves the production part: Cloud Hosted OBS, scenes, overlays, a safe place to land during a drop, destination routing, and a producer who is not standing next to the backpack.

The useful split is camera and audio into the BELABOX encoder, BELABOX SRTLA over the available field links to a BELABOX Cloud relay, then the relay's SRT output into a StreamableRun ingest. Cloud Hosted OBS turns that contribution feed into the program stream for Twitch, Kick, YouTube, or a custom RTMP destination. BELABOX's own BEE specification describes this exact protocol boundary: SRTLA between encoder and cloud relays, then SRT from the relay to OBS or other streaming software.

That does not make either layer a guarantee. Bonding can reduce the pain of one weak modem; it cannot create coverage, cool an overheating encoder, or repair a camera cable. Cloud production can keep viewers on a deliberate fallback while the field feed recovers; it cannot make missing video appear. Give each part one job and test the whole path together.

Signal path: keep the field transport separate from the show

Write this chain in the runbook before touching settings: camera and microphone → BELABOX backpack → two or more field links where available → BELABOX Cloud SRTLA relay → SRT contribution → StreamableRun ingest → Cloud Hosted OBS → destinations. A producer can then say which link is broken without guessing whether "the stream" means the camera, a modem, the relay, OBS, or the public platform.

Do not point the BELABOX encoder's SRTLA receiver fields at StreamableRun. Those fields belong to the BELABOX SRTLA relay leg. The current BELABOX remote labels them SRTLA receiver address, SRTLA receiver port, and SRT streamid, and advises a 1,500 to 2,500 ms starting latency range. Use the relay values that BELABOX Cloud gives your account for that leg. StreamableRun joins after the relay, on the relay's normal SRT output path.

The distinction matters when troubleshooting. If the BELABOX remote is not reaching its relay, do not rotate the StreamableRun Stream ID. If the relay has a healthy source but StreamableRun sees no bitrate, inspect the downstream SRT output. If StreamableRun sees picture and audio but the public page is wrong, the issue is Cloud OBS or the destination, not bonding.

Prerequisites and gear

Bring the exact kit you will carry live. A desk test with one Ethernet cable is not a backpack test. The current BELABOX BEE listing specifies HDMI input, H265 video encoding from 500 to 12,000 Kbps up to 1080p60, AAC or Opus audio, built-in Wi-Fi, and four high-power USB ports for modems. A DIY BELABOX build may have different input, power, capture, modem, and cooling limits, so use its own documentation rather than copying BEE numbers.

You need a BELABOX Cloud relay entitlement and a relay near the field route, plus access to the relay's SRT watch or output settings. BELABOX says its cloud relays are for carrying bonded SRTLA streams to OBS and lists relay locations across several global regions. Pick the practical relay for the field location, then test it; nearest on a map is not a substitute for a real moving-route rehearsal.

• Camera with a tested clean HDMI output, a short strain-relieved cable, and any HDMI adapter tested while moving the rig.
• The real microphone path, a wind solution, headphones, and a way to tell camera scratch audio from the program microphone.
• BELABOX encoder, approved power lead, charged power bank or battery system, and enough capacity for the show plus a recovery margin.
• The actual modem/SIM layout, plus Wi-Fi or Ethernet only when those links will really exist on location. Different carriers fail differently; several copies of one weak network are not a bonding plan.
• A running StreamableRun server, permission to manage its ingests and destinations, and a private communication channel between field operator and producer.
• A private, unlisted, or otherwise safe destination for testing. Keep public destinations off until source, audio, fallback, and return-to-program checks pass.

4Build and prove the camera-to-backpack side

With output stopped, connect the camera's clean HDMI feed to the encoder and secure both cable ends. Turn on the intended microphone, speak at normal street volume, and listen on headphones. Then deliberately mute or disconnect the external microphone for a few seconds. If you cannot immediately identify the audio that would reach viewers, fix that now. Audio mistakes survive a clean video preview far too easily.

Power the backpack with the same lead and battery layout planned for the show. The BEE page specifies a 9–15 V barrel input and a higher current requirement when USB devices are powered; its listed USB current is shared, not unlimited per port. That is a reason to inspect the actual modem and power load, not a reason to treat a generic battery label as proof. Check that the encoder, camera, modems, and cable bends all remain comfortable and secure after ten to fifteen minutes in the bag.

Set the camera to a supported input format for the particular encoder. BEE's published HDMI input list includes common 1080p and 720p formats, but it is not a promise that every camera menu mode, HDMI overlay setting, or custom BELABOX board will work. Start at a known supported mode, verify a moving picture locally, and only then add field networking.

5Configure the BELABOX relay leg

In BELABOX Cloud, create or select the relay that belongs to this show. Copy its current SRTLA address, port, and stream ID into the BELABOX encoder or Cloud remote relay settings. Treat the stream ID like a password: the BELABOX Cloud page explicitly warns not to share keys or stream IDs or show them on stream. Keep it in the secure dashboard or password manager, not in a producer chat or a screenshot.

Use the encoder's current relay configuration rather than typing a hand-built SRTLA URL from an old tutorial. The BELABOX remote exposes the SRTLA receiver address, port, stream ID, and latency, and it can show a dynamic-bitrate overlay. Enable the overlay during rehearsal if it helps the field operator see what the rig is doing, but do not leave a diagnostic overlay on the viewer-facing program unless that is intentional.

BELABOX describes SRTLA as a transport proxy that dynamically balances traffic across multiple links for capacity aggregation and redundancy. It also warns that the open-source receiver is unsupported for production deployment. For this workflow, use the current BELABOX Cloud relay rather than building a production receiver from the old public receiver instructions. The operator's job is to verify the relay is receiving a stable contribution, not to tune internal SRTLA behavior during a public show.

6Create the StreamableRun SRT ingest before routing the relay

Start the StreamableRun server and open Ingests. Use the current SRT connection labeled Other Cloud Servers (SRT), then give the ingest a name that carries its job: BELABOX Main — Street Camera is much better than Input 2. The current StreamableRun implementation supplies a URL with port, a private Stream ID, an empty passphrase instruction, and a displayed latency value for this BELABOX-compatible SRT endpoint. Copy those exact account values; do not recycle a key from a different ingest or add a passphrase StreamableRun did not provide.

The current default shown for this endpoint is 800 ms, but the value displayed in the account is the operational source of truth. It is separate from the BELABOX encoder-to-relay latency. Do not try to make the whole show low-latency by setting every buffer to its smallest number. Each leg needs enough room for retransmission and reordering, especially after a modem changes state.

In the BELABOX Cloud relay's SRT watch or output area, use the StreamableRun URL with port and Stream ID as the downstream SRT target, in the direction and fields that the relay currently presents for an OBS or other streaming-software receiver. BELABOX documents its relay output as SRT for OBS or other streaming software; StreamableRun is taking that production-software position. If the Cloud UI offers a generated watch URL rather than separate fields, follow its current copy/import flow and do not edit protocol parameters by guesswork.

• Keep the BELABOX Cloud relay stream ID and StreamableRun ingest Stream ID separate. They authorize different legs.
• Use a separate StreamableRun ingest for a backup phone or a second backpack. A producer cannot recover quickly from two sources with the same name.
• Confirm StreamableRun sees bitrate, changing video, and audio before building an elaborate scene collection or enabling a public platform.

7Set codec, bitrate, and latency with a real test

BELABOX BEE's published output is H265/HEVC. That can be useful for a constrained field link, but it makes end-to-end testing non-optional: verify that the current relay output, StreamableRun ingest, Cloud Hosted OBS source, confidence view, and intended destinations all show picture and audio correctly. Do not promise a public show that a camera-to-encoder preview alone has proved. If your BELABOX build offers a different codec or pipeline, its support envelope may differ from BEE.

The BELABOX remote's current guidance says 1,500–2,500 ms is a recommended starting range for its relay latency and warns that setting it too low increases glitching and reduces sustainable bitrate. Start inside the supplied range for the encoder-to-relay leg, use the StreamableRun value for the relay-to-ingest leg, and change one value at a time only after a measured rehearsal. A few hundred milliseconds saved is not worth a feed that becomes blocky whenever one carrier slows down.

Watch the dynamic bitrate behavior during the route that matters: walk, enter a busy block, get into a vehicle only if the show will do that, and simulate a single-link loss. The goal is not a screenshot of the highest number. The goal is a profile that avoids constant recovery and leaves enough quality for faces, motion, and readable overlays.

8Build Cloud Hosted OBS around recovery, not decoration

Add the named BELABOX ingest to a Cloud Hosted OBS scene called Main — BELABOX. Build the safe scenes before alerts, chat widgets, and sponsor graphics: BRB / Reconnecting, Clips Fallback, Privacy Hold, and Ending. A remote producer should be able to understand every scene in a glance and make the safe cut without asking the streamer to operate a browser from the sidewalk.

Keep overlays and destination controls in StreamableRun, not in the backpack. BELABOX should capture and deliver the contribution feed. StreamableRun should keep the viewer-facing program organized. This is the practical reason to combine them: the field operator can handle cable, framing, battery, and modems while the producer holds the scenes, audio state, fallback, and public outputs.

• Main — BELABOX: field camera plus only the overlays safe for an uncontrolled moving shot.
• BRB / Reconnecting: no field picture or microphone; use short status text and only cleared, tested audio.
• Clips Fallback: a checked clip list with matched loudness so a short reconnect does not turn into a silent frame.
• Privacy Hold: a fast clean scene for a location, emergency, security request, or other shot that should not be public.
• Producer Preview: monitoring and notes that can never reach program output.

9Set audio, protection, destinations, and the producer handoff

Check audio at three places: headphones at the backpack, Cloud Hosted OBS meters, and a muted public playback device that you briefly unmute with headphones. Look for the usual trap: the video is from the camera but the audio is still a camera scratch mic, a Bluetooth return, or a source that disappears when the camera changes mode. Do not switch the main scene back after a reconnect until the producer confirms usable audio.

Set up Stream Drop Protection and a fallback scene, then rehearse the rule. For a short known source recovery, the producer can use Clips Fallback. For an uncertain or longer recovery, cut to BRB / Reconnecting. For a privacy event, cut to Privacy Hold first and diagnose second. Protection preserves the viewer-facing session while the source recovers; it is not a repair tool for a dead battery, a broken HDMI lead, or a full network outage.

Add destinations only after the private path is clean. Connect the desired Twitch, Kick, YouTube, or custom RTMP output in StreamableRun, confirm the correct account and event page, then enable them one at a time. Keep a public playback view open after launch. Dashboard health proves the contribution is arriving; public playback proves viewers are receiving the right program with the right audio.

• Field operator: camera, focus, cable, power, modem state, and a concise report when anything changes.
• Producer: Cloud OBS scenes, source confirmation, audio state, fallback decisions, and destination health.
• Moderator: chat, privacy reports, and public playback confirmation; do not give scene control without rehearsal and a clear job.
• Everyone: one emergency phrase, such as ‘cut privacy,’ that means the producer cuts first and asks questions after.

Run one private full-path test and four failure drills

Start with a private destination and run the full signal path for long enough to expose heat, battery, and modem behavior. Confirm the camera, microphone, BELABOX relay, StreamableRun ingest bitrate, Cloud Hosted OBS main scene, fallback scenes, and final playback in that order. The public platform page is the final truth, not a local camera screen and not a single green status indicator.

Then rehearse failure on purpose. Do not disable every connection at once; the point is to learn what each layer reports and how the producer responds. Write down the time between the field change, producer action, and public recovery. That gives the team a usable baseline for the day of show instead of a vague feeling that it seemed okay at home.

• Single modem loss: disable or disconnect one field link, watch the BELABOX behavior, keep the program scene up if picture and audio stay healthy, then restore it.
• Contribution loss: stop the source briefly, verify the producer cuts to Clips Fallback or BRB, confirm the public session remains live, then return to Main only after video and audio are back.
• Audio failure: mute or unplug the intended microphone, cut away from the live scene if needed, verify the producer detects it from program audio, then confirm the replacement before returning.
• Privacy interruption: use the emergency phrase and time the cut to Privacy Hold. This is a safety drill, not a chance to debate scene order while the camera stays live.

Day-of-show backpack checklist

Run this before leaving, then repeat the short version at the start location. The backpack is a physical system: a perfect SRT configuration will not fix a partly seated HDMI plug, a nearly empty battery, a hot encoder buried under clothing, or a modem that connected to the wrong carrier. Keep a simple paper or phone checklist so the field operator does not depend on memory while rushed.

• Camera is in the tested HDMI mode, overlays are off, lens is clean, and the cable has strain relief at both ends.
• Microphone, wind protection, and headphones are connected; program audio has been checked, not assumed.
• BELABOX, camera, modems, and backup power are charged; spare cable and power lead are reachable without unpacking the whole bag.
• Modems have data service, are physically secure, and are not all on the same carrier if the show depends on independent routes.
• Ventilation is clear. Check temperature after the rig has been transmitting in the bag, not only while it sits on a desk.
• Correct BELABOX relay is selected, StreamableRun ingest is receiving, scenes are loaded, and fallback media is not muted or missing.
• Producer has the scene map, ingest name, destination list, emergency phrase, and a way to reach the field operator without exposing stream IDs.

Troubleshooting the right layer

Work from the first failed handoff outward. Rebuilding every setting at once usually hides the cause.

Other resources

Use the official BELABOX pages to verify the current hardware, relay, and remote controls for your exact device. The StreamableRun guides below cover the cloud-production jobs that happen after the relay hands off the feed.