To stream from a phone with Larix and Wowza, configure Larix to send an RTMP feed to the receiving endpoint supplied by your Wowza setup. Then check that Wowza receives the stream and test viewer playback separately; a successful publish does not prove that the playback path is ready.
The exact address, application, stream name and protocol depend on whether you use Wowza Streaming Engine or Wowza Video, and on how that destination is configured. The local Streaming Engine tutorial is a useful example of the sequence, not a universal connection recipe.
Check that your phone and Larix are ready
Larix Broadcaster is the phone-side encoder in this workflow: it captures camera and microphone input, encodes it, and sends it to a destination. Softvelum lists iOS 16.0 or later and Android 7.0 or later for the app. Check the current Larix Broadcaster platform information before installing, because supported operating systems and features can change.
An app meeting its minimum operating-system requirement does not guarantee that every encoding option will be available on every handset. Available hardware encoders, camera modes, frame rates and audio inputs vary by device. Install the app, grant camera and microphone access, and make a short test recording or local preview before arranging the network connection.
Decide where the phone will sit and how long it needs to run. A mount can help keep framing steady, and external audio may be useful if the built-in microphone is too far from the speaker. These are optional accessories, not Larix or Wowza requirements; check the connector and device compatibility before buying anything. Keep the phone powered, avoid blocking ventilation, and consider using Wi-Fi or a stable mobile connection at the actual streaming location.
This is a live camera workflow, rather than a way to turn a prepared video into a continuous channel. If your aim is a recorded programme that runs all day, a phone may not be the right source; a recorded-course stream workflow covers a different kind of setup. For a phone-based event or an occasional live report, the next decision is which Wowza destination will receive the feed.
Choose and prepare the Wowza destination
Wowza Streaming Engine and Wowza Video are separate products and their setup steps should not be conflated. The documented Larix example uses a locally hosted Wowza Streaming Engine instance. A managed Wowza Video workflow provides its own encoder connection details through its setup process. Start with the product and live application you actually intend to use, then copy its current input settings rather than adapting a sample address from another deployment.
For Streaming Engine, the values Larix needs are generally a server address, port, application name and stream name. Wowza documents the general RTMP endpoint form as rtmp://[address]:[port]/[application]; the stream name is supplied as a separate value in the publishing configuration. Wowza lists 1935 as the default RTMP streaming port, but an administrator can configure a different port, so treat it as a documented default rather than a value to assume. See Wowza's connection URL guidance.
For Wowza Video, use the encoder URL and stream key or other connection values shown for the relevant live stream in the current account interface. Wowza's live stream setup documentation describes its hosted workflow. Do not assume that a Streaming Engine application name or playback URL transfers unchanged to Video, or vice versa.
Before opening Larix, confirm that the destination is active and that you have permission to publish to it. In a self-managed setup, the person responsible for the Engine instance may need to confirm that the application exists, the intended input is enabled, and network access to the configured port is allowed. An incorrect address, application, port or security setting can look like an app problem even when Larix is configured correctly.
Treat the stream key or publishing credentials as private. Do not include them in screenshots, public troubleshooting posts or a shared connection profile. If someone else administers Wowza, ask them for the exact encoder values and whether any source restrictions apply. Avoid testing with a real key in a public example; use placeholders when documenting your setup.
Add the RTMP connection in Larix
In Larix, create a connection for the Wowza destination. Enter the RTMP URL using the server and application values supplied by that destination, then enter the stream name or key in the field expected by the configuration. Larix's connection documentation explains its connection settings. The URL and stream name work together; putting the stream name in the wrong field can result in a connection attempt that does not match the receiver's expected path.
A placeholder illustrates the relationship without pretending to be a working universal address:
Server URL: rtmp://your-server.example:your-port/your-application
Stream name: your-private-stream-name
Replace every placeholder with values from your own Wowza setup. Do not copy this as a ready-to-use endpoint. Your deployment may use a different hostname, port, application, authentication method or connection pattern. If the provider supplies a complete URL or a dedicated stream key field, follow those instructions instead of splitting the values based on this example.
Choose the protocol that the selected receiving path supports. The cited end-to-end Larix-to-Engine tutorial uses RTMP. Larix also supports SRT publishing, but SRT is not a drop-in replacement for an RTMP connection: it requires the receiving Wowza path to be configured for SRT and a matching mode and connection information. The presence of SRT in Larix does not establish that every Wowza account or server exposes an SRT input.
For a first test, use a conventional H.264 video and AAC audio configuration where the device and destination support them. Larix describes these as its standard encoding path, and Wowza lists H.264 and AAC-family inputs among compatible RTMP choices. Check the actual server's input requirements if an administrator has constrained codecs or profiles. Keep the initial setup simple: change one setting at a time, so you can identify which change affects the connection or playback.
Start the broadcast and verify ingest
Once the destination details are saved, connect the phone to the network you plan to use and begin streaming from Larix. Give the connection a short test before relying on it for an event. In the Wowza application or source-monitor view, look for the incoming stream and confirm that the source is active. The names and locations of these controls differ by product and interface version, so use the current documentation for your selected destination.
The local Streaming Engine tutorial walks through a Larix publish and then uses Larix Player for playback. It is useful for understanding the order of operations, but its local server values and screens apply to that example, not automatically to a hosted Wowza Video account or a differently configured Engine. Use the receiving application's own status view as the authority on whether it has accepted your source.
If Larix reports a connection failure and Wowza sees no source, check the values in a deliberate order: server address, port, application, stream name or key, then source authentication and network reachability. Confirm that the phone has internet access and that the receiving port is reachable from its network. If you are on a managed Wi-Fi network or mobile connection, try a permitted alternative network to isolate whether the issue is local connectivity or the Wowza configuration.
If Wowza shows the source but the picture is black, frozen or silent, the connection has progressed further: investigate encoding and media rather than repeatedly changing the endpoint. Check Larix's camera and microphone permissions, selected input, codec settings and whether the phone is overheating or under heavy load. Ask the Wowza administrator whether the incoming format is accepted by the application. Record the exact error and the point in the sequence where it appears; that is more useful than changing several settings at once.
Test playback as a separate job
Ingest and playback are separate parts of the path. A source can appear in Wowza while the viewer URL is wrong, a playback protocol is not enabled, or the delivery configuration is incomplete. Determine which output protocol is available for your destination, then get the corresponding playback address from its settings or documentation. For Engine, Wowza explains that a viewer URL depends on the server, application and stream name; depending on configuration, a default application instance may be implicit.
The Wowza Larix tutorial's playback example uses HLS and Larix Player. That is one documented test route, not a requirement that every viewer use Larix Player or that every Wowza setup expose the same HLS address. Use a player that supports the selected playback protocol, and test the actual URL generated for your configured application. A browser, a compatible media player or a platform-specific player may behave differently, so distinguish a player limitation from a server-side delivery issue.
Test from a second device or network if practical. This helps establish that playback is reaching viewers rather than only working inside the environment used to administer the server. Check that the image and audio are present, that the stream continues beyond the first moments, and that the delay is acceptable for the intended use. A news update or two-way session may need different latency expectations from a music or ambience feed.
If your eventual destination is YouTube, remember that a Wowza playback address is not the same as a YouTube ingest address. You would need the appropriate output workflow and YouTube's own current setup requirements; do not paste a Wowza viewer URL into a publishing field simply because both use streaming protocols. For other production arrangements involving multiple sources, a guide to measuring live-stream quality can help you describe what you see without confusing a viewer-side problem with an encoder setting.
Troubleshoot connection and playback faults
A useful diagnosis separates three points: Larix's attempt to publish, Wowza's receipt of the source, and the viewer's ability to play the output. Note which point fails and make one change at a time. This avoids the common loop of replacing a stream key, changing a codec and switching players without learning which part was actually at fault.
| What you observe | First checks | What it suggests |
|---|---|---|
| Larix cannot connect and Wowza shows no source | Recheck destination address, port, application, stream name or key, and any source restrictions | The publishing route or credentials may not match the receiver |
| Wowza shows a source, but the picture or audio is missing | Check phone permissions, selected inputs and accepted encoding settings | Publishing is reaching the destination; inspect the media path |
| Wowza receives the stream, but the player cannot open it | Confirm playback protocol, viewer URL, application and stream name | Ingest may be working while output or playback details are wrong |
| Playback starts but stalls or loses frames | Test at the intended location and network; reduce the encoder target if needed | The phone, network or delivery path may not sustain the chosen settings |
These are diagnostic clues, not guaranteed causes. For a self-managed Engine, an administrator can check the application and source status; in a hosted workflow, follow the destination's account-specific setup and status views. If you cannot change server settings yourself, send the administrator the time of the attempt, the exact Larix error and whether any source appeared. Never send a private stream key as part of a public support request.
A sustained live source also depends on the phone remaining usable. Keep it plugged in where appropriate, prevent accidental app closure, and check that power management is not interrupting capture. A tripod or mount can reduce movement but cannot solve a network drop. If the stream is mission-critical, rehearse the full path from the chosen location and decide in advance how you will resume or switch to a backup source.
Set bitrate for the actual mobile connection
Larix describes its selected bitrate as an encoder target. A target is not a promise that a cellular connection will deliver every packet, and it is not a guarantee of smooth playback. Softvelum's Larix FAQ gives resolution-based suggestions, reproduced below as vendor guidance rather than an independent performance benchmark.
| Resolution | Larix suggested bitrate |
|---|---|
| 2160p | 4500 Kbps |
| 1080p | 3000 Kbps |
| 720p | 2000 Kbps |
| 540p | 1500 Kbps |
| 480p | 1000 Kbps |
| 360p | 700 Kbps |
| 288p | 500 Kbps |
| 144p | 300 Kbps |
The same FAQ says HEVC uses half the listed values and 50 fps or higher multiplies them by 1.6. Those are Larix's rules for its table, not a measured guarantee for your phone or network. The handset must support the selected codec and frame rate, and the destination must accept them. If you need a starting point, choose a resolution suited to the scene and test it at the venue rather than assuming the highest setting is best.
Larix notes that worsening network conditions can cause frame loss with RTMP or RTSP and describes an adaptive-bitrate option. A lower target may make a stream more resilient, though it also reduces image detail. Test at the time and place you intend to broadcast, including the phone's position in the room. If the image breaks up, try lowering bitrate or resolution and repeat the same test before changing other settings.
For a fixed shot of a speaker, a stable medium-resolution picture may be more useful than fine detail that repeatedly freezes. For a scene with movement or small text, you may need a different balance, but the available connection still sets a practical limit. If your goal is a continuous recorded loop rather than live phone capture, an OBS workflow for local video files is a different option to consider; it avoids relying on a handset as the source.
Account for codecs, device limits and operating choices
H.264 video and AAC-family audio are sensible compatibility starting points because they are documented for Larix's standard encoding path and Wowza RTMP input. That does not mean every combination of profile, resolution, frame rate or audio mode is supported in every device and server configuration. If a codec-specific problem appears, compare the Larix output settings with the receiving application's current requirements, then test a conventional configuration before trying less common options.
Phone capability matters beyond the nominal operating-system version. Camera access can be affected by another app using the camera; external microphones may require a compatible adapter; and longer sessions can expose heat, battery or background-task limits that a brief test will not. Keep the camera framing and audio input simple for the first full rehearsal. A small business product demonstration, for example, may benefit more from intelligible close audio and stable focus than from increasing resolution.
The choice between self-managed Streaming Engine and hosted Wowza Video is a choice about control and setup responsibility, not a universal quality ranking. With Engine, use the values and security settings for the instance you or your administrator manage. With Video, use the hosted setup's generated encoder details and its supported output path. Compare the protocol you need, how much configuration you can manage, how viewers will receive the stream and what recovery behaviour your production requires. No current price or universal performance comparison is established here, so check the vendor's current product information for your circumstances.
There is a further distinction between a live phone feed and an always-on channel. Larix needs the phone to keep capturing and publishing; a phone is not a dependable unattended source merely because an app can connect. If you need a static or prerecorded programme to run while your own computer is off, the operational problem is different from sending a camera feed through Wowza. For a broader look at a recorded channel, see the always-on Indian lofi stream guide.
A final rehearsal should follow the same route as the real stream: same handset, app profile, network location, Wowza destination and player. Verify ingest, then verify viewing. Write down the working destination labels and non-secret settings so you can repeat them, but store the key securely and avoid sharing screenshots that reveal it. Check the current official product pages again if your interface or account has changed since setup.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can I use the same RTMP URL for every Wowza setup?
No. The server address, port, application and stream name depend on the configured destination, and Wowza Video uses its own hosted setup details. Treat examples as illustrations only and copy the current values supplied for your account or Engine instance.
Does the Larix-to-Wowza tutorial work unchanged with Wowza Video?
No. The tutorial demonstrates a local Wowza Streaming Engine workflow, including its own publishing and HLS playback example. Wowza Video is a separate hosted workflow, so use its current encoder settings and playback instructions rather than carrying over the tutorial's local values.
Should I use RTMP or SRT from Larix?
RTMP is the protocol used in the documented Larix-to-Engine example and is a straightforward starting point when the receiving application is configured for it. Larix also supports SRT, but select it only when the receiving Wowza path is configured for SRT and supplies matching connection details.
What should I test if the stream connects but viewers cannot watch?
Check playback separately from ingest: confirm the output protocol is enabled, use the viewer URL for the correct application and stream, and open it in a compatible player. If Wowza shows the incoming source, avoid changing the phone's endpoint until you have checked the delivery and playback settings.