Receiving IRL SRT in Your Home OBS: Plugin or Managed Server, Now That OBS 33 Changes Plugin Folders

The direct answer

If you receive IRL SRT into OBS on your home PC, you can keep doing it. Nothing in the OBS notes says the setup stops working this month. The plugin option is a legitimate choice, and for a streamer who sits near that PC with solid home upload, it can be the right one.

What changed is the maintenance picture. OBS 33 changes where third-party plugins are supposed to live, and OBS 34 is documented as the version that stops loading the old locations. If your receive path depends on a plugin that is installed the old way, you now own a dated to-do item.

My judgment: keep the plugin if your PC, your home upload, and the person operating the show are all in the same place. Move receive to a managed server if the PC is a single point of failure, if anyone besides you needs to run scenes, or if you do not want OBS version upgrades to be part of your travel prep.

What the dated sources say about OBS 33 and 34

The OBS Knowledge Base article on legacy plugin locations is dated September 21, 2026. It says that starting with OBS Studio 33.0, plugins in legacy locations are flagged with a Legacy indicator in the plugin manager, and that plugins installed under Program Files in the old layout will not be loaded in OBS Studio 34.0 onwards. The new recommended Windows location is under C:\ProgramData\obs-studio\plugins, with one folder per plugin. The same article says macOS plugin locations have not changed, and Linux details were still marked as coming soon.

On the release side, the OBS Studio releases page lists 32.2.2 (August 14, 2026) as the current stable build. 33.0.0 Beta 6 (October 2, 2026) is the newest pre-release. The 33.0 notes list a complete overhaul to plugin loading and say existing third-party plugins will continue to load from the legacy locations until OBS Studio 34.0.

What the obs-irl-source plugin is actually for

The plugin is an independent project from irlserver.com, and its README says it is not affiliated with or endorsed by the OBS Project. It is licensed AGPL-3.0-or-later. The latest release at the time of writing is v2.1.5, published September 23, 2026, and the README says it works on OBS 32.1 and newer.

The problem it targets is real. The README says OBS's built-in Media Source was written for files and general media, and that an IRL SRT stream through a Media Source usually sits 2 to 3 seconds behind real life. It also says that after a stall the built-in source's latency climbs and stays there. The plugin holds a 120 ms audio cushion by default, plays slightly fast (up to 5 percent by default) to catch up after a stall, and exposes a Target Buffer setting you can raise if the stats show underruns.

Those are the author's claims about their own plugin. I did not run it, and I have not measured Media Source or the plugin against each other, so I will not give you a delay number. If delay matters to you, measure it on your own network with your own phone, once, and write the result down.

The open question: where does the plugin install on Windows?

This is the part I could only partly verify. The README's manual Windows install says to extract the zip into your OBS Studio folder, usually C:\Program Files\obs-studio, so the DLL lands in obs-plugins\64bit. I also read the Inno Setup script in the plugin's repository: it copies the DLL to obs-plugins\64bit under the OBS folder and the data files to data\obs-plugins\obs-irl-source.

That is a DLL under Program Files with data stored separately in the OBS data folder, which is close to what the OBS Knowledge Base calls the Program Files legacy structure. It is not an exact match: the article's Program Files example puts the module at plugins\example-plugin\bin\64bit, while this plugin's installer uses obs-plugins\64bit. I have not installed the plugin into an OBS 33 beta, so I cannot tell you whether the Legacy flag shows up for it, and I found no statement from the plugin's author about OBS 33 or 34 plans.

So the honest position is: possibly affected on Windows, unconfirmed, and probably fixable by the author with an updated installer. That is a normal thing for a maintained plugin to ship. macOS and Linux installs go into the user plugins folder, and the OBS article says macOS locations are unchanged.

• Check the plugin's releases page for notes that mention OBS 33, the plugin manager, or ProgramData.
• If you have a spare PC or a duplicate OBS profile, install the OBS 33 beta there and look for the Legacy indicator before it matters.
• If the author ships a new-location build, uninstall the old copy first. The plugin's installer script even warns that two copies loaded at once make the second registration fail.

Checklist: if you keep a home-PC receive plugin

If you decide to stay, treat it like any other production dependency. These are the five things I would settle before OBS 33 goes stable, in the order they tend to bite.

• Plugin location. Open the plugin manager in OBS 33 on a test profile and see whether the plugin is flagged. Write down the installed folder so you can find the old copy later.
• Updates. Decide who updates the plugin and OBS, and when. A plugin update and an OBS update on the same morning as a travel stream is how you end up debugging in a parking lot.
• Latency settings. The plugin's Target Buffer defaults to 120 ms, and the README says to set SRT latency through FFmpeg Options. Raise buffers to what your connection needs, not to the maximum, because the whole target is paid as delay.
• Home upload and uptime. The PC has to hold your platform connection for the entire show. Check upload headroom for your output bitrate, sleep and update settings, power, and what happens if the router reboots while you are two hours from home.
• Who can operate it. If a mod or producer needs to switch scenes, they need remote access into that Windows machine, which means remote desktop software and its own security surface.

Where each path wins

The short version, as a list.

• Keep the plugin when you stream from home or a fixed location, the PC is also your studio, you are the only operator, and a stream that stops when the PC stops is acceptable.
• Move receive to a managed server when the show is mobile, the PC is at home, and a home outage should not end the public stream.
• Move receive to a managed server when moderators or a producer need to run scenes, fallback, and overlays without logging into your desktop.
• Move receive to a managed server when you do not want an OBS or plugin version to be a precondition of going live.
• Run both when you want a local studio machine for some shows. Local OBS can be a source into the managed server rather than the whole show.

What changes when receive moves off your PC

Moving to a managed server does not make the mobile network better. Your phone still has to reach someone over cellular. What changes is which machine owns the problem.

With a home receiver, the phone's SRT has to reach your house: either a port open to the internet for listener mode, or a pull from some server you run. Then the PC decodes it, composes the show, and encodes the platform stream. Each step is something you maintain. With a managed server, the phone connects to a hosted ingest, and the hosted OBS composes and sends the platform output. The failure you watch for becomes the phone link, not the whole chain behind it.

You also lose some control and gain some. You give up local plugins and a machine you can touch. You gain a place where scene switching, fallback, and moderator access are not tied to a Windows desktop in your hallway.

The setup path: field app, ingest, platform

For a serious IRL show on StreamableRun, the shape is simple to describe: Moblin or IRL Pro in the field, a StreamableRun ingest in the middle, then StreamableRun to Twitch, Kick, YouTube, or a custom RTMP destination.

• Create the server and an ingest in StreamableRun. For a phone, pick the ingest type that matches your app: SRTLA_MOBLIN for Moblin, SRTLA_IRL_PRO for IRL Pro. Other types in the product include plain SRT for OBS, SRT_LIVEU, SRT_GENERAL, SRTLA_BELABOX (listed as Other Cloud Servers), and RTMP.
• Copy the ingest URL into the field app. The ingest host is in.streamable.run and the SRT port in the product is 9000. Moblin deep links are available so you do not have to retype long URLs on a phone.
• Build the show scenes in Remote OBS: main camera, an Ingest Offline fallback scene, BRB, and privacy. Configure the low-bitrate and switch-to-offline behavior so a dead feed lands on a scene you designed.
• Add your destinations and run a private test first. Kill the phone link on purpose, confirm the fallback appears, reconnect, and confirm the main scene returns.
• Add moderators last. The three roles are Admin Moderator, Scene Switcher, and Tools Moderator, so a helper can be limited to what they need.

Where StreamableRun fits

StreamableRun is Cloud Hosted OBS plus ingest. If your show is mobile and you want one place that receives the feed, owns the fallback scene, takes moderator access, and sends the final stream to your platforms, it is the option we would point a serious IRL streamer to first. That is a statement about fit, not a benchmark, and it depends on the reader.

I am deliberately not making claims about StreamableRun's OBS version, codec support, or latency here. Those are things to check against the product and test on your own route before you commit a big show.

Who should keep local OBS: desk streamers, people whose home PC is already the studio, and anyone who relies on a plugin or workflow that only exists on their own machine. The plugin question in this guide is also not an argument against local OBS. It is an argument for knowing exactly which machine your show depends on.

A one-evening plan before OBS 33 reaches stable

You do not need to migrate anything this week. A calm evening is enough to turn this from a worry into a decision.

• Install the OBS 33 beta in a separate folder or on a spare machine with a copy of your profile. Never upgrade the production PC to a beta.
• Look at the plugin manager. Note which plugins are flagged and whether the IRL receive plugin is one of them.
• If you test the managed path, run it alongside, not instead. Send a short private stream through it and compare your own experience of delay, recovery after a dropped link, and how easily a second person can switch scenes.