Larix Broadcaster SRT and RTMP Setup for StreamableRun Cloud OBS

The direct answer

Larix Broadcaster is useful when you want a flexible mobile encoder instead of an IRL-community-specific app. Softvelum lists support for SRT, RTMP, NDI, WebRTC, RTSP, Zixi, and RIST, plus camera switching, recording, portrait and landscape operation, and streaming to services such as YouTube and Twitch. That makes it a strong field source for creators who need a phone to behave more like a production encoder.

For a serious StreamableRun workflow, do not make Larix carry the whole show. Use Larix to send one clean contribution feed into StreamableRun. Let StreamableRun Cloud Hosted OBS handle scenes, overlays, clips, fallback behavior, multiple destinations, and the remote producer. That split keeps the phone focused on capture and upload instead of turning it into the final broadcast computer.

The simplest setup is Larix on iPhone or Android to a named StreamableRun ingest, then Cloud OBS to Twitch, Kick, YouTube, or custom RTMP. Use SRT when you have tested the network path and need a more resilient contribution route. Use RTMP or RTMPS when compatibility and simple setup matter more than protocol tuning.

Who should use Larix

Use Larix when your stream needs protocol flexibility, a generic professional encoder, or the same phone app across iOS and Android. Moblin and IRL Pro are excellent IRL-native choices, but Larix is often the practical pick for operators who move between SRT, RTMP, RTMPS, WHIP, RIST, NDI, and custom endpoints.

Larix is also a good backup app. If your main IRL app has a profile issue, if a venue blocks one route, or if a producer asks for a clean SRT or RTMP contribution feed, Larix gives the team another known path. The mistake is discovering that backup path during the show. Build the Larix profile before the route, name it clearly, and test it through the same StreamableRun server the team will use live.

Streamers who only need a fast first stream may not need Larix yet. If the goal is one casual mobile stream, a platform app or IRL-specific app may be easier. Larix becomes interesting when you care about transport settings, external mics, camera rotation, multiple output options, UVC input on Android, or a producer who wants a repeatable ingest profile.

• Good fit: a creator who needs SRT or RTMP from a phone into Cloud OBS.
• Good fit: a producer who wants one tested backup mobile encoder across platforms.
• Good fit: a travel stream where the phone may need to change from landscape to portrait or swap cameras.
• Less necessary: a beginner who only wants to tap Go Live once from a platform app.
• Risky without testing: any route where the streamer has never rehearsed the exact Larix profile, ingest URL, audio device, and battery plan.

SRT or RTMP for the phone leg

The phone leg is the path from Larix to StreamableRun. That is where protocol choice matters most. RTMP is familiar, easy to paste, and widely understood. SRT gives you more tools for an unstable contribution path, but it also creates more settings to get wrong.

OBS's SRT guide explains that SRT URLs can include options such as mode and latency, and that latency is measured in microseconds. That detail matters because SRT latency is a recovery window, not just a delay slider. A very low latency value can feel fast on a clean network and then fall apart when a phone hits jitter or packet loss. A larger value can look slightly later but survive a rougher route.

For most Larix-to-StreamableRun tests, start conservative. Pick one protocol, one resolution, one bitrate, and one audio path. Do not test SRT, RTMP, HEVC, camera switching, and a new microphone at the same time. If the stream fails, you will not know which change caused it.

• Pick RTMP or RTMPS when the team needs the lowest setup friction.
• Pick SRT when the route is unstable and the team can test latency, mode, and reconnect behavior.
• Keep H.264 as the safest public-compatible video choice unless the full chain supports HEVC.
• Use a private StreamableRun test before raising resolution, bitrate, or frame rate.
• Write down the working profile so the producer can tell when the phone has drifted from the rehearsal settings.

Build the StreamableRun ingest first

Start in StreamableRun, not on the phone. Create or choose the server, name the ingest something obvious, and copy the ingest URL or connection details into the Larix profile. A profile named Main SRT, Backup RTMP, or Larix iPhone tells the producer what they are looking at during a live recovery.

Keep platform keys away from the phone when you can. Larix should send to StreamableRun; StreamableRun should send to Twitch, Kick, YouTube, or custom RTMP. That keeps the field device from becoming the place where every destination secret lives. It also means the producer can restart or edit a destination without asking the streamer to touch the phone.

After the feed appears in Cloud OBS, build scenes around the source. Use a main live scene, a fallback scene, a technical slate, a clips or BRB scene, and a private test scene. The goal is not to make the setup fancy. The goal is to give the producer known moves when the phone freezes, rotates, overheats, loses signal, or changes audio devices.

• Name the Larix ingest by device and protocol.
• Create a main scene that contains only the production-ready Larix source and needed overlays.
• Create a fallback scene that does not depend on the phone feed.
• Create a technical slate for private testing and producer checks.
• Confirm the destination keys live in StreamableRun, not scattered across field phones.

Camera, audio, and orientation checks

Larix gives you more encoder-style control than a basic platform app, but the physical phone still has the normal mobile problems. Heat, battery, stabilization, mic gain, Bluetooth delay, screen brightness, and orientation can all make a technically correct stream feel bad.

Do not trust the phone preview alone. Watch the StreamableRun Cloud OBS preview, the platform preview, and a normal viewer device. Check whether the image is cropped, whether portrait or landscape is correct, whether text overlays are readable, whether the microphone is too hot, and whether the producer hears audio before the public audience does.

If you plan to rotate the phone, test rotation while live in rehearsal. If you plan to switch cameras, test that too. A camera switch that looks smooth inside Larix can still create a visual jump, exposure change, audio shift, or momentary freeze downstream. The producer should know whether to leave the main scene up or cut to fallback before the streamer changes camera modes.

• Lock orientation unless the stream format actually requires live rotation.
• Use wired or well-tested audio when audio matters more than mobility.
• Carry a power plan that does not block the phone antenna or make the rig too hot.
• Test the exact mount, lens, mic, and battery pack from the real stream.
• Have the producer verify the platform page, not only the cloud preview.

Destination output is a separate job

A common Larix mistake is sending directly to every platform from the phone because the app can publish to many services. That can work for simple streams, but it is a bad default for serious IRL. Each extra destination increases the phone's responsibility and makes recovery messier.

Use one mobile contribution path into StreamableRun, then decide output settings in Cloud OBS. Kick's current help page asks creators to use a custom OBS service, CBR, a two-second keyframe interval, and settings that do not exceed upload capacity. YouTube's live encoder page lists H.264, H.265, and AV1 options over RTMP/RTMPS, with CBR and keyframe guidance. Those are destination decisions. The phone does not need to hold all of them.

With StreamableRun, the producer can start or stop Twitch, Kick, YouTube, and custom RTMP destinations while the Larix feed stays stable. That is the whole point of the cloud layer: the field source contributes the show, and the production server publishes it.

Producer handoff runbook

The handoff should fit on one screen. The producer needs to know which Larix profile is expected, which StreamableRun ingest should light up, what scene is public, what scene is safe, what audio source is live, and who is allowed to restart destinations.

When the phone drops, the producer should not ask the streamer to explain settings while walking. The order should be automatic: cut to fallback, confirm the public destination stays live, watch the StreamableRun ingest, wait for Larix to reconnect, check audio and orientation, then return to main when the platform preview is clean.

When the phone overheats, the producer needs a slower recovery. Cut to fallback or clips, tell the streamer to cool the phone, lower screen brightness if possible, remove unnecessary recording, and reduce the contribution profile only if the team already has a tested lower profile. Guessing new bitrate settings while live is how you create a second problem.

• Main recovery: fallback scene first, diagnostics second.
• Reconnect recovery: wait for stable video and audio before returning to main.
• Audio recovery: mute the bad source, confirm platform preview, then fix the phone.
• Destination recovery: producer restarts the destination in StreamableRun without changing Larix.
• Rollback recovery: switch Larix from SRT to tested RTMP backup only if that profile has already passed rehearsal.

Private test checklist

Run one boring test and one ugly test. The boring test proves the path works under clean conditions. The ugly test proves the path survives the kind of day the streamer actually has.

For the boring test, send Larix to StreamableRun for at least 20 minutes. Check video, audio, sync, orientation, thermal behavior, battery drain, Cloud OBS scenes, and destination preview. For the ugly test, walk away from Wi-Fi, lower signal, lock and unlock the phone if that is safe to test, switch camera once, trigger a fallback scene, and restart one destination. The producer should write down what failed, not only what looked good.

Do not leave the test with a vague feeling that it worked. Save the Larix profile name, protocol, bitrate, resolution, audio device, StreamableRun ingest, destination profile, and fallback behavior. The next stream should start from a known setup, not memory.

• Confirm the phone can start the exact saved Larix profile.
• Confirm StreamableRun receives the feed under the expected ingest name.
• Confirm Cloud OBS scene switching does not break audio.
• Confirm fallback keeps the public stream alive when Larix disconnects.
• Confirm the producer can operate destinations without streamer input.
• Confirm the lower-quality backup profile is already saved.

Other resources

Use these pages to verify Larix feature support, SRT settings, platform output requirements, and the StreamableRun pieces you are building around the mobile encoder.