How to Connect a LiveU Solo or Solo PRO Stream Backpack to StreamableRun

What this setup actually connects

A LiveU backpack is the field-contribution half of the job. It takes your camera and microphone signal, uses the network links available to the unit, and gets that contribution out of the street, venue, car, or trail. StreamableRun is where that contribution becomes a viewer-facing show: Cloud Hosted OBS can hold scenes, overlays, a safe fallback, destinations, and the producer controls that should not live on the backpack.

For the SRT route in this guide, the real signal path is camera and audio into Solo or Solo PRO, LiveU Reliable Transport (LRT) from the unit to LiveU's cloud, SRT caller from LiveU's cloud into the StreamableRun LiveU ingest, then Cloud Hosted OBS to Twitch, Kick, YouTube, or a custom RTMP destination. LiveU documents that Solo SRT output requires LRT and that its cloud makes the final SRT caller connection. That means a good camera preview on the backpack is not proof that the whole path is healthy; test the actual destination path.

This is deliberately a full show setup, not a repeat of the short add-an-ingest page. The field operator owns camera, audio, power, cables, and network. The producer owns scenes, the public output, and recovery. Keeping those jobs separate is why a bonded encoder can make a hard travel stream more manageable instead of merely more expensive.

Prerequisites before you open either dashboard

Have the exact unit, camera cable, audio setup, power plan, and network gear that will be used on the show. A Solo PRO accepts HDMI or, on the SDI/HDMI model, SDI input; do not plan an SDI camera around the HDMI-only unit. LiveU lists external cellular modems, Wi-Fi, and Ethernet as available connection types for Solo PRO, while the actual number of links depends on the model, cables, kit, and service you have. Check your own hardware instead of assuming every backpack has the same modem count.

You also need a LiveU Solo Portal login with the service needed for the output path you plan to use. LiveU states that SRT on Solo requires LRT, and that Solo SRT support applies to Solo firmware 7.1 or later and Solo PRO. Do not buy, renew, or change a LiveU service because a generic tutorial says so; confirm the entitlement shown for your unit and ask LiveU support if the SRT destination type or the applicable Solo PRO zone is missing.

• A powered camera with a clean, tested HDMI or SDI output that matches the Solo model.
• The actual field microphone path, plus headphones for checking it before departure.
• Solo or Solo PRO, the correct video cable and strain relief, charged internal battery, and a tested external power plan if the show will outlast it.
• Your real external modems, SIM/data arrangements, Wi-Fi or Ethernet only where those will truly be available, and a secure way to carry the cables.
• A running StreamableRun server, a Streamable account allowed to edit ingests and destinations, and a separate communication channel for the producer and field operator.
• A private, unlisted, or otherwise safe test destination. Do not make the first SRT connection while your public channel is waiting.

3Build and prove the field side first

With the unit off or not transmitting, connect the camera to the input that matches the Solo model and secure the cable so walking will not pull it loose. Connect the intended microphone and confirm that the camera is sending the audio you expect. If the camera has an internal mic, do one deliberately bad test: cover or mute the external mic and make sure you can tell which source viewers would hear. It is much easier to find a camera scratch track in a quiet room than on a sidewalk.

Power the unit, let its network connections come up, and use the local display or Solo Portal to confirm that the camera image and each connection look normal before you start a destination. Solo PRO has a local display and web-based remote control; use both only as confidence checks, not as a substitute for a viewer-side test. Keep the operator's first job simple: a clean picture, intelligible audio, secure power, and no loose connector.

4Create the dedicated LiveU ingest in StreamableRun

Start the StreamableRun server, go to Ingests, and select the LiveU / DSLR Camera connection details for the ingest you will use. Give the ingest a name that answers a producer's question under pressure, such as LiveU Main - Street Camera. Do not reuse a mystery ingest that might also be attached to a backup phone or another creator.

Reveal and copy the values shown for the LiveU connection: Profile, URL and Port, Stream ID, and Latency (ms). The StreamableRun app's current LiveU ingest implementation presents those as a separate LiveU SRT connection, with a 1,500 ms default latency and the profile 1080p50/60 H.264 No Nulls. Treat the displayed values as the source of truth for your account. Do not invent a passphrase, alter the host, append random query parameters, or use a stream ID from another ingest.

• Keep the Stream ID private. It identifies the incoming contribution path.
• Write down the ingest name and the Cloud OBS source name together; the producer should never have to guess which incoming feed is live.
• If you have a backup phone or a second LiveU, create and label it as a separate ingest. A backup source is only useful when it can be selected quickly.

5Create the SRT caller destination in the LiveU Solo Portal

Open the LiveU Solo Portal, choose the correct unit, add a new destination, and select the destination type LiveU calls SRT-OUT-Caller-Solo. LiveU's current SRT instructions use that destination type for Solo and Solo PRO. Name the destination after the show and Streamable ingest, not after a vague location; for example, StreamableRun - Main - Portland Test.

Enter the StreamableRun URL and Port into LiveU's Primary URL field, and enter the StreamableRun Stream ID into LiveU's Stream ID field. LiveU describes the Stream ID as the SRT equivalent of a stream key. Its documentation says the SRT caller destination can take an optional passphrase, so leave that field empty unless StreamableRun explicitly supplies a matching passphrase. A made-up passphrase will prevent the receiver from accepting the contribution.

Enter the StreamableRun displayed Latency (ms) in LiveU's SRT Latency field. LiveU's generic starting point is 500 ms for many internet destinations and advises raising it when a destination is hard to reach or unstable. StreamableRun displays its own LiveU ingest latency for this path, so use that supplied value for this setup first, then test before changing it. This SRT latency is not the same control as the Solo PRO unit-to-LiveU-cloud latency mode.

6Choose codec, profile, and LRT behavior without guessing

For this StreamableRun path, start with the H.264 profile StreamableRun displays. H.264 is the safe first contribution codec when the full chain includes a cloud source, Cloud OBS, monitoring, and several possible platform destinations. LiveU says Solo PRO can offer H.264 or HEVC on an SRT caller destination, while HEVC from Solo PRO requires that SRT output path. That does not make HEVC an automatic upgrade: only use it after your StreamableRun ingest, Cloud OBS decode, recording, confidence monitor, and all final destinations have passed a real rehearsal.

LiveU's No Nulls documentation explains that its SRT caller profiles can be either a constant-mux MPEG-TS profile or a No Nulls profile that forwards the variable-rate stream without padding. StreamableRun presents 1080p50/60 H.264 No Nulls for the LiveU connection, so select the matching profile shown by your dashboard instead of changing it to a hardware-receiver profile from an unrelated workflow.

For Solo PRO, LiveU currently documents 800 ms, 1 second, and 5 seconds as unit-to-cloud latency choices. That setting covers the unit through the Solo cloud, not the next SRT leg to StreamableRun. The 800 ms release note warns that the choice can affect resiliency and specifically points streamers in challenging bandwidth toward the 1- or 5-second options. Pick the field setting after testing the actual route; do not chase the smallest number during a crowded event.

7Start contribution and verify it at the StreamableRun ingest

Save the LiveU destination and start the unit transmitting. LiveU says its cloud will keep retrying the SRT caller connection while the unit remains streaming if the first connection attempt fails. Give the path time to establish, then return to the same StreamableRun ingest and check that its bitrate monitor is receiving the feed. Confirm picture motion and audio meters, not just that a status dot has changed.

If the source does not arrive, stop here. Recheck the copied URL and port, Stream ID, selected destination, profile, and the LiveU service or zone status before you rebuild scenes or add platforms. A source that is not arriving cleanly cannot be repaired by Cloud OBS. Keep the public destinations off until this check is clean.

8Build the Cloud Hosted OBS scene map around the LiveU source

In Cloud Hosted OBS, add the LiveU ingest to a clearly named main scene. Build the show before adding decorative overlays: prove the source in Main LiveU, then make BRB / Reconnecting, Clips Fallback, Privacy Hold, and Producer Preview scenes. A scene collection with five readable choices is more useful than twenty half-finished ones when the backpack loses a modem or the camera needs to move through a private area.

Keep any stream chat, alerts, sponsor graphics, captions, or lower thirds in Cloud OBS, not on the backpack. The field operator should not have to touch an overlay to fix a microphone or an HDMI lead. StreamableRun is the right production layer for a serious LiveU workflow because it keeps Cloud Hosted OBS, the field ingest, fallback scenes, multiple source options, remote production, and destination management in one operating path.

• Main LiveU: the camera contribution plus only the overlays safe for a moving shot.
• BRB / Reconnecting: no live camera or field microphone, short status wording, and safe bed audio only if licensed and tested.
• Clips Fallback: a checked playlist with matched loudness so a short reconnect does not become a silent dead frame.
• Privacy Hold: a fast non-camera scene for addresses, faces, medical events, security, or a field instruction that cannot be shown.
• Producer Preview: confidence monitoring and notes that never go to program output.

9Set up disconnect protection, audio, and destinations

Enable and rehearse Stream Drop Protection for the workflow you are using, then give the producer an explicit rule: cut to Clips Fallback for a short source recovery, BRB / Reconnecting for a longer or uncertain recovery, and Privacy Hold when the reason to cut is safety rather than signal. Bonding improves the contribution path; it does not make the LiveU, camera, battery, cable, cloud output, or platform destination impossible to fail.

Listen to the LiveU source inside Cloud Hosted OBS with headphones. Confirm that program audio follows the intended mic, that camera scratch audio is not doubled, and that BRB, clips, and privacy scenes cannot leave the live field mic open. A producer needs an emergency mute. The field operator needs a basic spoken cue such as 'hold audio' and a way to acknowledge it without arguing on the public feed.

Add final destinations in StreamableRun after the private source and scene test. Connect Twitch, Kick, YouTube, or a custom RTMP destination one at a time, start only the safe test destination first, and have someone watch playback as a viewer. The contribution profile is not a license to assume each platform accepts every final encoder setting; Cloud Hosted OBS is where the team can keep platform-facing output consistent while the LiveU remains focused on field contribution.

10Hand the live operation to a producer without sharing chaos

Before the public stream, give the remote producer one short card: LiveU ingest name; main, fallback, and privacy scene names; which destination is primary; who owns the LiveU Portal; the field operator's contact method; and the rule for cutting away. The producer does not need the backpack in their hands. They need enough access to protect the program while the field operator protects the camera and themselves.

Give the moderator a different job. They watch the public destination from a viewer account, note recurring playback or audio problems, flag privacy trouble, and tell the producer when chat is seeing something the control preview missed. They should not diagnose cellular radio behavior from chat messages. One complaint is a clue; a repeated pattern plus the producer's monitors is a reason to act.

Run a private end-to-end test and three failure drills

Run the exact backpack, destination, Cloud OBS scene collection, audio kit, and producer handoff you intend to use live. Twitch Inspector can help with a Twitch health test, and YouTube supports private or unlisted live settings; use the safe option your destination supports. The key check is the complete chain, including the viewer side. A green LiveU preview and a clean StreamableRun ingest do not prove that the public platform received the intended program audio.

Do the drills on purpose, with a watcher recording what viewers saw and how long recovery took. A drill is successful only when the team can repeat the recovery in the same order, not when the source eventually returns after everyone tries random controls.

• Contribution-loss drill: stop the LiveU transmission or interrupt a test connection in a safe way. Producer cuts to Clips Fallback, checks that the destination session stays live, waits for the ingest to return, checks audio, then returns to Main LiveU.
• Audio drill: create the failure you fear, such as disconnecting the field mic where it is safe to do so. Producer switches away or mutes, field operator restores the real input, producer checks meters and listener playback before returning.
• Privacy drill: use the agreed cue. Producer cuts to Privacy Hold immediately, moderator confirms the public view is safe, and the team decides whether to resume from the camera or stay away while the field changes position.
• Destination drill: bring up one final platform output and verify title, orientation, program scene, audio, and actual playback. Then add the next destination. Do not discover a bad key or rejected profile by starting every platform at once.

Travel and day-of-show checklist

Pack and check the physical route first, then the account route. A forgotten short HDMI lead, uncharged modem, old destination selected in the Solo Portal, or Stream ID pasted from the wrong ingest can undo the best scene collection. Leave enough time to reproduce the connection where you will actually start the stream, especially if the first live location is a venue with guest Wi-Fi, an underground entrance, or a crowded cellular sector.

• Camera, lens, media, HDMI or SDI lead, audio adapter, mic, headphones, and strain relief checked as one kit.
• Solo battery and external power tested under load; modems and any power bank charged; no cable is pulling against a port.
• LiveU Portal has the correct StreamableRun SRT caller destination selected; URL and Stream ID match the named ingest.
• Cloud Hosted OBS opens with Main LiveU, Clips Fallback, BRB / Reconnecting, and Privacy Hold ready; live field mic is absent from fallback scenes.
• Producer, field operator, moderator, and backup contact know their jobs and the first recovery cue.
• One viewer watches the real destination; platform credentials and Stream ID stay with the people who actually need them.

LiveU Solo and Solo PRO troubleshooting table

Start with the point where the chain first disagrees with reality. Do not change codec, latency, scene settings, and destination credentials all at once; one controlled change gives you a useful result.

Other resources

Use these official pages to verify the LiveU-specific behavior against your unit and service, then use the related StreamableRun guides to rehearse the part viewers actually experience.