The first decision is not an OBS setting: it is whether viewers will receive RTMP or WebRTC from Wowza. Both routes can start with OBS publishing to Wowza over RTMP, but they require different playback configuration and have different compatibility and latency expectations.
For an RTMP audience, use Wowza’s documented low-latency setting for the live application and test with the player you intend to use. For browser-oriented WebRTC playback, check codec compatibility and WebRTC setup first; transcoding can help compatibility, but adds delay. Neither route has a universal latency result.
Choose a delivery path before changing settings
Write down what your viewers will use to watch before you configure the encoder. The choice between RTMP playback and WebRTC playback changes the delivery side, even if the OBS-to-Wowza publishing leg is RTMP in both cases.
| Route | OBS publishes | Viewers receive | What to weigh |
|---|---|---|---|
| RTMP to RTMP | RTMP to a Wowza live application | RTMP | A direct documented workflow; the player and its buffer settings affect delay and smoothness. |
| RTMP to WebRTC | RTMP to Wowza | WebRTC | Browser-oriented, lower-delay playback is possible; source codec compatibility, WebRTC configuration and any transcoding matter. |
| OBS WebRTC/WHIP publishing | WebRTC using WHIP, where supported | Depends on the Wowza workflow configured | Consider it only after confirming that your OBS version and Wowza account support the required publishing path. |
The first two rows are the two primary choices covered here. In each, OBS sends RTMP to Wowza; it is the protocol from Wowza to the viewer that changes. The third row is a separate publishing approach, not an automatic variation of the first two. OBS documents WHIP for version 32.1.0 and newer, with a provider URL and bearer token, but you must verify that the provider endpoint and your Wowza setup support it. See the OBS WHIP guide before planning around it.
If you are building a continuous channel rather than a one-off broadcast, keep the delivery decision separate from the content schedule. A guide to scheduling pre-recorded videos for a 24/7 YouTube stream addresses the publishing pattern; it does not remove the need to configure and test the player route described here.
Understand the RTMP-to-RTMP route
This is the straightforward route when your playback workflow uses an RTMP player. Create or select a live application in Wowza Streaming Engine, take the connection details from that application, and enter them in OBS. Once the stream is arriving, enable Wowza’s low-latency behaviour for the live application, then test the resulting playback in the actual player.
Wowza’s quick-start documentation shows the general shape of the connection: a server address containing the application path and a separate stream name or key. Use the values supplied for your own application rather than copying a demonstration URL or key from a guide. Credentials identify your stream; do not publish them in screenshots, public chat or an open configuration file.
The low-latency setting is specific to the RTMP playback workflow. Wowza documents enabling Low-latency stream in Streaming Engine Manager for the live application, saving the change and restarting that application. Its XML alternative sets the application stream type to live-lowlatency, followed by an application restart. Follow the current instructions for the version you run; changing an application configuration is not a substitute for confirming that the viewer is using the intended application and playback method.
The player buffer is a separate part of the route. Wowza says that setting NetStream.setBufferTime() to zero minimises RTMP playback latency, while warning that playback may become less smooth. It suggests trying a value slightly above zero, such as 0.1 or 0.25, if zero causes instability. Wowza also notes that, in its documented player context, with H.264 at 30 fps, any positive buffer introduces at least 2–3 seconds of latency, with more delay at lower frame rates. Keep that caveat attached to that player context; it is not a universal result for every RTMP player or stream.
A zero buffer is therefore not an unconditional improvement. A devotional stream that needs continuous, predictable audio may be better served by a little more buffering than by brief interruptions. A live discussion where a small delay is noticeable may justify testing a tighter buffer. In either case, judge the setting from the viewer’s playback and not only from OBS’s preview.
Understand the WebRTC playback route
For this route, OBS publishes RTMP to Wowza, and Wowza delivers playback over WebRTC. It can suit browser-based viewing where low delay matters, but it is not achieved by simply selecting a low-latency option in OBS. Wowza’s live application, WebRTC playback and any signalling and TLS requirements must be set up for that delivery method.
Compatibility is a practical constraint. Wowza’s RTMP-to-WebRTC guidance describes cases where the incoming audio or video codec, or its profile, needs transcoding for WebRTC playback. Transcoding can make an otherwise incompatible source usable, but Wowza warns that it adds startup time and latency. If the source can pass through in a compatible format, that avoids this particular processing step; do not assume it can until you check the source and the current Wowza documentation.
B-frames are another point to check in an OBS source intended for WebRTC delivery. Wowza recommends disabling B-frames for WebRTC, including for RTMP source streams used in its RTMP-to-WebRTC workflow. This is not a promise that every other encoder setting will be accepted: verify the complete codec and profile requirements for the Wowza feature and playback client you are using.
Wowza reports expected latency of one second or less for passthrough WebRTC output and two seconds or less for transcoded output in its RTMP-ingest-to-WebRTC guidance. Treat these as route-specific estimates from the documented workflow, not a service guarantee. The actual delay depends on the network path, player and geography, as well as whether the stream passes through or is transcoded. Wowza’s RTMP-to-WebRTC documentation describes the relevant compatibility and workflow considerations.
There is a different Wowza Video real-time workflow that discusses OBS Enhanced for Real-Time at approximately 500 ms and says RTMP can add approximately one second in that context. That page’s figures belong to that product context; they are not interchangeable with the RTMP-to-WebRTC estimates above. Confirm which Wowza product and workflow your account uses before relying on a figure. Low delay is a property of an end-to-end route, not a setting shared identically across products.
Configure OBS and Wowza for your selected route
For the basic RTMP publishing connection, open Settings → Stream in OBS and select Custom. Enter the RTMP server address and stream key or name supplied by the Wowza live application. Wowza’s Streaming Engine quick start illustrates the connection pattern and checking that the incoming stream becomes Active in Streaming Engine Manager. Labels can differ by version, so use the current application details rather than relying on a screenshot as an exact map of your interface.
Before you start, confirm that the application is live and that you have copied the right connection details into the matching OBS fields. Start streaming in OBS, then look in the Wowza application’s Incoming Streams view to confirm the stream is Active. If it does not appear, resolve publishing and connection problems before diagnosing playback latency: there is no useful viewer-delay test until Wowza is receiving the intended source.
Set OBS output resolution and frame rate to suit the content, the available upload connection and the computer doing the encoding. Higher resolution or frame rate can increase encoder and network demands. For example, a static study scene may not benefit from a higher frame rate as much as a fast-moving demonstration, while a small text overlay still needs enough resolution to remain legible. Make one change at a time and test a sustained session. If you are also tuning a YouTube stream, the quality settings and fixes guide gives broader OBS checks; those general checks do not replace Wowza’s route-specific configuration.
For RTMP playback, enable Wowza’s Low-latency stream option for the live application in Streaming Engine Manager, save, and restart the application. If you manage the configuration in XML instead, Wowza documents setting Streams/StreamType to live-lowlatency and restarting. Then verify playback with the RTMP client and buffer behaviour you actually plan to use.
For WebRTC playback, first ensure the selected Wowza application and account are configured to deliver WebRTC, including the required signalling and TLS setup. Check the source audio and video codecs, profiles and B-frame setting against Wowza’s current documentation. If transcoding is required, record that as part of the expected route and test its startup and end-to-end delay; do not tune OBS under the assumption that it is a passthrough stream.
Check compatibility and latency expectations
Latency is the time from an event at the source to its appearance at the viewer. To compare two routes fairly, observe a visible event or audible cue at OBS and at the receiving player from the same test, rather than comparing a local preview to a remote player. A phone stopwatch is sufficient for a practical check if you can see both ends clearly, but the result is an observation for that test, not a platform-wide measurement.
| What to check | RTMP playback | WebRTC playback |
|---|---|---|
| Wowza output path | RTMP live application and compatible RTMP player | WebRTC playback configured for the application |
| Key setting or constraint | Wowza low-latency application behaviour; player buffer | WebRTC signalling and TLS; codec and profile compatibility |
| Processing trade-off | A smaller buffer can reduce delay but may reduce smoothness | Transcoding can address compatibility but adds startup time and latency |
| Published expectation | No universal figure; player and buffer context matter | Wowza reports ≤1 second passthrough and ≤2 seconds transcoded for its documented RTMP-to-WebRTC route |
The WebRTC estimates in the table refer only to Wowza’s documented RTMP-ingest-to-WebRTC workflow. Network conditions, player implementation and geography can alter the result. The RTMP player guidance about positive buffering is likewise limited to Wowza’s stated H.264-at-30-fps context. Do not combine estimates from different products or routes into a single promise.
Compatibility should be established before latency tuning. A player that cannot decode the output, a mismatched profile or an incomplete WebRTC setup is a configuration problem, not a delay problem. If you are unsure whether the source is being transcoded, check the Wowza stream or transcoder status and the current product documentation. Avoid enabling processing merely to see whether it helps: it can change both startup behaviour and delay.
If you intend to publish a long-running video loop rather than a live camera or desktop feed, also test transitions and audio continuity over the actual route. The mechanics of keeping sound continuous across files are covered in this guide to audio between videos on a continuous stream. A smooth local file transition does not prove that the Wowza player route is stable, so include the transition in remote playback checks.
Test the stream and troubleshoot delay
Start with a baseline: note the OBS output settings, whether Wowza is passing through or transcoding, the playback protocol, player buffer if applicable, and the viewer’s network. Record the time from a clear event at the source to the same event at the playback device. Repeat under the conditions that matter to your audience, such as a mobile connection, and change just one setting before testing again.
If OBS reports dropped frames, investigate the publishing connection before lowering player buffers or changing codecs. OBS explains that dropped frames indicate an unstable connection or a bitrate the connection cannot sustain. Its troubleshooting guidance suggests trying a different ingest server and reducing video bitrate; it gives around 75% of total upload speed as a starting point, not a universal ideal. The OBS dropped frames guide is useful for separating network loss from playback delay.
Check whether the computer can encode the chosen resolution and frame rate without falling behind. Reduce output demands if the encoder or machine is struggling, then observe whether the incoming stream becomes more stable. Do not simultaneously change resolution, frame rate, bitrate and Wowza playback settings: if the result changes, you will not know which adjustment helped.
For RTMP playback, check that the low-latency application setting was saved and the application restarted. Then review the player buffer and test the trade-off between lower delay and interruptions. For WebRTC, check the client path, signalling and TLS configuration, then confirm whether transcoding is occurring and whether the source codec and profile match the documented workflow. A delay that appears only after transcoding may be an expected processing cost rather than a network fault.
Test more than one viewer device if your audience will watch on different browsers or networks. Record whether the delay is consistent, whether playback starts slowly, and whether it stalls after starting. Startup time and steady-state latency are different observations. A useful test report might say, “WebRTC playback started slowly on one phone, then the source event appeared after a short delay on wired playback,” rather than converting one informal test into a promise for all viewers.
If the goal is an always-on channel, distinguish production continuity from delivery latency. OBS running on a local computer means that computer, its power and its network are part of the broadcast chain; a low-latency configuration does not remove that operational dependency. Where a pre-recorded YouTube channel needs to keep broadcasting while your computer is off, StreamNeo addresses that specific continuous-running burden by taking an uploaded video and your YouTube stream key to keep the broadcast running remotely. It is YouTube-only and is not a Wowza playback route, so it is not a substitute for this setup when Wowza is the required delivery platform.
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
Does the Wowza low-latency setting also configure WebRTC?
No. The Wowza live-lowlatency setting described here is for RTMP clients. WebRTC playback has its own application, signalling, TLS and codec compatibility requirements, so confirm those against the WebRTC workflow you are using.
Can OBS send RTMP to Wowza while viewers watch over WebRTC?
Yes, Wowza documents an RTMP-ingest-to-WebRTC-playback workflow. The source codec and profile must be compatible, and transcoding may be needed; it adds startup time and latency. Test the actual Wowza application and playback client rather than assuming RTMP ingest alone enables WebRTC.
Will WebRTC always be faster than RTMP playback?
There is no universal comparison that applies to every player, network and route. Wowza’s published expectations for its RTMP-to-WebRTC workflow distinguish passthrough from transcoded output, while RTMP playback depends in part on the player buffer. Measure the route your viewers will use.
Should I use WHIP instead of RTMP from OBS?
Only if your OBS version and Wowza provider setup support the required WHIP endpoint and credentials. OBS’s guide applies to version 32.1.0 and newer and requires a provider URL and bearer token. Check current official documentation before changing the publishing route.