Keep your main platform in OBS's Settings > Stream, then use the free obs-multi-rtmp plugin to add one target for each extra platform. Every target sends another upload, even when it reuses the main encoder. I'd choose this route when the destinations accept the same video settings and your connection can carry their combined bitrate; a cloud relay is the better starting point when upload is the limit.
OBS's native Stream page has one selected Destination. The plugin adds a separate dock called Multiple output, so your main stream and the extra targets have separate start controls. The steps below use stable version 0.7.4.5, released October 25, 2026, by SoraYuki. It is free software under the GPL-2.0 license.
Choose the build before changing OBS
The maintainer's OBS resource lists OBS 32.2.0 as the minimum, while the stable plugin's build configuration targets OBS 32.2.1. Those are different facts: a minimum version and a build target. Neither confirms compatibility with OBS 33.0.1. Before upgrading an existing streaming setup, look for a maintainer release that explicitly covers your OBS branch, and keep the working OBS/plugin pair backed up.
Version 0.8.0.0 is a prerelease with a different Edit targets window. Its instructions don't match the Add new target and Modify controls in 0.7.4.5. Use the release label to decide which instructions fit the copy you have.
Add up the upload before adding targets
Each target sits after the encoder on the signal path. In the plugin's output creation code, each target gets its own output object. Sharing the encoder saves another video encode; each destination still needs its own network stream.
Budget the video and audio for the main output and every target. If the main service sends several renditions through a feature such as Enhanced Broadcasting, include all of that traffic too. The OBS connection guide suggests 75% of measured upload speed as a starting point for one stream. For multistreaming, I'd apply that headroom to the combined traffic, because every output leaves through the same connection.
For example, a connection measured at 20 Mbps gives a 15 Mbps starting budget. Three streams, each carrying 4 Mbps video and 0.16 Mbps audio, add up to 12.48 Mbps before transport overhead. These are example numbers, not a platform preset: use the destinations' encoder requirements and your sustained upload to choose the real values. Leave room for overhead and other traffic, then check the result with every intended output running.
If one output works but the combination starts dropping frames, reduce the combined traffic or send one stream to a cloud relay. Changing an encoder preset won't create more upload capacity.
Install the package that matches your OBS
Download from the maintainer's release page linked above. The OBS Plugins Guide explains why the operating system, CPU architecture and OBS installation method must match the plugin. Close OBS before changing its plugin files, and back up an existing copy first.
| Your OBS installation | Package in the 0.7.4.5 release | What decides the route |
|---|---|---|
| Standard Windows x64 | windows-x64-Installer.exe | The installer uses the common OBS plugin folder. Keep its fixed destination. |
| Windows portable or a specific manual installation | windows-x64.zip | Use the manual package for that OBS copy. The standard installer doesn't let you redirect its folder. |
| macOS | macos-universal.pkg | The package is universal; its packaging source targets the current user's OBS plugins folder. |
| OBS installed through Flatpak, x86_64 | flatpak-x86_64.flatpak | Use the Flatpak plugin route, rather than copying a native Ubuntu plugin into the sandbox. |
| Native Ubuntu 24.04 or 26.04 | The matching ubuntu-24.04.deb or ubuntu-26.04.deb | Match the distribution release. A dbgsym.ddeb file contains debug symbols and isn't the normal plugin package. |
Windows installation warning: when an existing copy is detected, this installer's prompt says Yes = Install, No = Remove. Do not choose No to remove just this plugin: the 0.7.4.5 installer script removes the shared plugins folder recursively. That can affect other plugins. Use the scoped rollback procedure below if you need to take obs-multi-rtmp out.
After installation, reopen OBS and find Multiple output in the Docks menu. If it isn't listed, check Help > Log Files > View Current Log for a plugin-load error before copying more files. A missing dock is an installation or compatibility problem; a stream key can't fix it.
Add one target for the extra platform
- Set up the main platform under Settings > Stream in OBS. Leave that destination there.
- In Multiple output, choose Add new target. Give the target a name that identifies the extra platform.
- For a platform providing an RTMP or RTMPS ingest address and stream key, choose RTMP as Protocol. Open the Service tab and enter that platform's server address and key in their separate fields. Copy the pair from the same channel's live dashboard.
- Choose the video and audio encoders as described next, then save with OK.
- Keep the small checkbox to the left of Start checked for each target you intend to use.
The Service and Output tabs use properties supplied by OBS, so the fields depend on the selected protocol. Use the ingest method the platform supports. A channel page URL isn't an ingest address, and one platform's key doesn't authenticate another platform.
The checkbox has an Enabled tooltip. In 0.7.4.5's start logic, an unchecked target won't start from its own Start button, a hotkey or Start all. Unchecking a running target force-stops that target, so don't use the box as a harmless way to hide it during a broadcast.
Reuse the encoder when the destinations agree
In Video Settings > Encoder, choose Reuse the streaming encoder as OBS when the extra destination accepts the main stream's video format and settings. This is my starting choice for matching destinations because it avoids another video encode. Scene, Resolution and Framerate become unavailable for that target: the video is already encoded.
Choose Audio Settings > Encoder separately. The plugin obtains video and audio encoders independently; custom video with reused audio still depends on the native audio encoder. If a reused encoder isn't available, the target can fail to start. For a clear first rehearsal, start the native OBS stream before manually starting the extra target.
When a destination needs different video settings, select a compatible encoder for that target instead of reuse, then choose the resolution and other settings its ingest requires. That adds encoding work as well as the separate upload. Don't change every destination to the same codec just because the encoder appears in a menu; the receiving service has to accept it.
Know which Start and Stop you are using
Start Streaming in OBS controls the native main stream. A target's Start controls that target. The dock's Start all and Stop all buttons loop over the plugin targets; they don't start or stop the native OBS stream.
For a linked workflow, open Modify for a target and use Other Settings > Sync start with OBS and Sync stop with OBS. These follow OBS streaming events. Start Recording doesn't trigger them. A start request can still fail, so read every target's status and receiving dashboard rather than assuming the buttons made every destination live.
Check platform rules before sending the same live
A working target doesn't grant permission to simulcast. Twitch's written simulcasting terms require a Twitch viewer experience no worse than elsewhere, prohibit directing viewers away to the concurrent broadcast, and prohibit combining other platforms' activity, such as merged chat, on the Twitch stream. Check those terms and any agreement attached to your account before choosing overlays or promoting the other destinations.
Check every other destination's live-stream access and simulcast conditions too. Keep stream keys out of screenshots, shared logs and public support posts. A target using a real channel's key may go public as soon as it starts; a preview in OBS doesn't make the receiving broadcast private.
Export privately; import only after stopping targets
Use Export Config before replacing the plugin or rebuilding the list. The exported JSON includes stream keys, so store it as a private credential backup. The plugin also keeps its configuration in obs-multi-rtmp.json under the active OBS profile; switching profiles can therefore change which targets you see.
Import Config replaces the entire target configuration. It doesn't add one target to the existing list. In the export/import code, importing is refused while a target is running. Export the current list first, choose Stop all, wait for every plugin target to stop, then import and confirm the replacement. Check the names, servers, encoder choices and Enabled boxes before starting anything again.
Find where an extra stream stops
| What you see | Where it stops | First check |
|---|---|---|
| No Multiple output entry in Docks | Plugin loading | Package, architecture, OBS compatibility and the current OBS log. |
| Disabled, or Start does nothing for that target | Target enable state | Check the box to the left of Start. |
| Failed to create encoder object | Encoder selection or availability | Review video and audio choices separately; if reusing, start the main stream for the rehearsal. |
| Incorrect RTMP address or failed connection | Target service or route | Recopy the ingest address and key from that destination, then check its dashboard and your network. |
| Streaming in the dock, but no audience broadcast | Receiving platform | Check the service's ingest preview and any separate action required to make it live. |
| One stream works; several together drop frames | Combined upload | Recalculate video plus audio for every output, allow overhead and compare destinations one at a time. |
The plugin distinguishes Connecting, Streaming, Reconnecting and specific error messages. A connection error alone doesn't identify a bad key: it can also be the server address or network path. Work from the displayed message and destination dashboard before reinstalling.
Remove only this plugin if you need to roll back
Stop all plugin targets and the native OBS outputs, then quit OBS. Keep the private configuration backup and a copy of the working plugin folder together. Move only the identified obs-multi-rtmp folder or bundle outside the folders OBS searches; preserve every other plugin.
For the standard Windows installer, the plugin's own folder is normally C:\ProgramData\obs-studio\plugins\obs-multi-rtmp. Confirm the actual location before moving it. Do not remove the parent plugins folder or choose the installer's No = Remove branch. Manual, portable and older installs may use a different location.
On macOS, the examined current-user package and bundle destination point to ~/Library/Application Support/obs-studio/plugins/obs-multi-rtmp.plugin. Confirm that bundle before moving only it. For a Linux package, use the package manager that installed that specific plugin. Restore the backed-up plugin and matching configuration to return to the previous pair, then check loading and outputs before another broadcast.
Use a different route when it removes your limit
Aitum Multistream is worth checking when you want multiple outputs tied to a vertical workflow. SE.Live combines multistreaming with StreamElements' account connections and chat tools. Match either plugin's current release to your OBS and operating system before switching; another local-output plugin still needs an upload budget.
When upload is the constraint, a cloud relay changes where the streams split. OBS sends one stream to the relay, which forwards it to the destinations. Restream describes adding destinations without another upload from your computer; its plan limits and supported destinations decide whether it fits. That routing change is the reason to choose a relay over adding more local targets.
Rehearse the whole route before the real broadcast
Use each service's test or private option where it offers one, and keep any public destinations disabled until you're ready to send them a broadcast. Start the main output, then the extra target, and check the receiving picture and sound on both services. Finally run the intended combination long enough to see whether network drops or reconnects accumulate.
Rehearse stopping as well: Stop all for the plugin targets, then Stop Streaming for the main output unless your chosen sync workflow already stopped the extras. Confirm that every receiving service has ended the broadcast. The useful finish line is a complete picture and sound at each destination, with start and stop behavior you can predict.
