Supported Bit Versions
  1. 64-bit
Source Code URL
https://github.com/YorVeX/xObsBeam
Minimum OBS Studio Version
29.0.0
Supported Platforms
  1. Windows
  2. Linux

xObsBeam​

OBS plugin to transmit lossless (raw or QOI/LZ4 compressed) video and audio feeds between OBS instances. An alternative to NDI and Teleport for A/V transmission.
Currently in BETA, expect bugs and crashes, not ready for production use!

1680640780652.png


Prerequisites​

  • OBS 29+ 64 bit
  • Windows
    • tested only on Windows 10, but Windows 11 should also work
  • Linux
    • not regularly tested
    • binary build created on Ubuntu 20.04 WSL environment, therefore linked against glibc 2.31

Use cases​

This plugin transmits a video and audio feed from one OBS instance to another. The video feed can be compressed using QOI and/or LZ4 with minimal CPU usage or even transmitted raw with no added compression CPU usage at all but at the expense of extreme bandwidth needs. In all cases the transmission is completely lossless. The most common scenario would be transmitting audio and video feeds from OBS on a gaming PC to OBS on a streaming PC.

Both NDI and Teleport in comparison transmit their video feeds using a lossy compression (albeit almost visually lossless to be fair) and most of the time have lower bandwidth needs than this plugin.

No solution is better or worse in general, it's just different tradeoffs regarding CPU/GPU usage, bandwidth needs and quality. What works best in a given scenario depends (among other things) on the specific use case and available resources. It's also very hard to predict how it will perform for any given setup, so it's best to test it out and play with the settings.

Raw local transmission​

The obvious case where compression seems unnecessary is when transmitting data from one OBS instance to another within the same machine (so no network between them). E.g. when the first OBS instance is for recording and it sends the feed to a second OBS instance for streaming, which adds some panels, alerts, animations and other effects only for the stream which shouldn't be visible in the recording (other solutions to achieve that currently don't seem to be really stable). In that case both encoding and decoding work would also hit the same machine.

Standard setups​

Standard setups (i.e. typical 1 Gbps consumer network gear) will almost always want to use the QOI compression and maybe LZ4 compression at FAST level in addition. You get a truly lossless video feed with low CPU usage on the bright side, but be warned that QOI/LZ4 have some worst case scenarios where bandwidth usage could have significant spikes. Make sure to run tests with various scenarios and see whether your setup is up for the task.

"Small" sources​

Transmitting sources with low resolution and/or low FPS through the network could actually be feasible even over a standard 1 Gbps network, e.g. for a retro game or a cam feed of an old webcam that you want to include. Especially when also the source PC is "retro" it helps a lot to save on CPU sources by not having to compress the data or using the CPU friendly QOI/LZ4 compressions.

High bandwidth network​

For enthusiast or semi-professional setups with expensive network devices it could be feasible to transmit raw video feeds over a network.

Here is some example configurations and their necessary bandwidths for the video feed (audio usually is negligible), exact numbers might vary a bit between xObsBeam versions but it helps to get a general idea:
ResolutionFPSNV12/I420 bandwidthI444/P010/I010 bandwidthBGRA bandwidth
720p30312 Mpbs632 Mpbs840 Mbps
720p60632 Mpbs1264 Mpbs1680 Mbps
900p30488 Mpbs984 Mpbs1312 Mbps
900p60984 Mpbs1976 Mpbs2632 Mbps
1080p (FHD)30704 Mpbs1416 Mpbs1896 Mbps
1080p (FHD)601416 Mpbs2840 Mpbs3792 Mbps
1440p (2K)301264 Mpbs2528 Mpbs3368 Mbps
1440p (2K)602528 Mpbs5056 Mpbs6744 Mbps
2160p (4K)302840 Mpbs5688 Mpbs7592 Mbps
2160p (4K)605688 Mpbs11384 Mpbs15184 Mpbs


Remember that NV12 is the OBS default. If you choose a different color format also the load on the sender will increase in addition to the bandwidth demand.

If you want to get this number for your specific configuration just start the Beam output and check the OBS log, it will show a line like this:
Code:
[xObsBeam] Video output feed initialized, theoretical net bandwidth demand is 632 Mpbs

Note that this is the theoretical minimum net bandwidth that is needed on a network. To measure your available net bandwidth you can use a tool like iperf, e.g. for a 2.5 Gbps connection it could be something like 2.37 Gbps.

In addition there still needs to be enough headroom available for spikes that can occur at any time and of course for all other traffic that wants to use the same interface. Depending on how sensitive this traffic is and how good all involved network devices are (switch, router, network card, cable, the chain is as good as its weakest link) other traffic might suffer long before you get even close to any theoretical limits, e.g. if you play a latency sensitive game on a cheap router your latency might already double our triple when only using half of theoretically available bandwidth or less because of how network packets are prioritized. Also other traffic originators might have spikes too.

If it's just that little bit of extra bandwidth that you lack to get it working, you can try to use only LZ4 at FAST level, it could e.g. bring an 800 Mbps feed down to 600 Mbps with very low CPU usage if you're lucky.

Usage​

Install the same version of the plugin (different versions are never guaranteed to be compatible to each other) into all OBS instances that you want to transmit video/audio feeds between.

Installation​

Before installing make sure that OBS is not running.

Open an Explorer window and into the address bar paste this and press enter:
%APPDATA%\obs-studio
This will redirect to a location like C:\Users\<YourWindowsUsername>\AppData\Roaming\obs-studio. Extract the files from the downloaded .7z file to this folder (= copy the contained obs-plugins and data folders to it). This will install the plugin for the current Windows user.

If you need to install the plugin for all users on the system you can also extract the downloaded .7z file (= copy the contained obs-plugins and data folders) into the OBS Studio installation directory. The default location for this is
C:\Program Files\obs-studio
This needs admin permissions.

The folder structure in the downloaded .7z file is prepared so that you can extract the file (= copy the contained files) into your user home and on many systems this will just work already.

However, depending on the distribution and OBS installation method (manual, distro repo, snap, flatpak...) the location of this folder can vary, so if it doesn't work from the user home you might have to look around a bit.

Example locations for the plugin .so (and .so.dbg) file are:
~/.config/obs-studio/plugins/ (The structure the .7z is prepared for)
/usr/lib/obs-plugins/
/usr/lib/x86_64-linux-gnu/obs-plugins/
/usr/share/obs/obs-plugins/
~/.local/share/flatpak/app/com.obsproject.Studio/x86_64/stable/active/files/lib/obs-plugins/
/var/lib/flatpak/app/com.obsproject.Studio/x86_64/stable/active/files/lib/obs-plugins/

Unfortunately the expected location of the locale, which can be found in the data folder, can vary also.
If you get missing locale errors from the plugin you can try to copy the "locale" folder found inside the data folder to:
/usr/share/obs/obs-plugins/<plugin name>/locale
~/.local/share/flatpak/app/com.obsproject.Studio/x86_64/stable/active/files/share/obs/obs-plugins/<plugin name>/locale
/var/lib/flatpak/app/com.obsproject.Studio/x86_64/stable/active/files/share/obs/obs-plugins/<plugin name>/locale

If in doubt, please check where other "en-US.ini" files are located on your system.

The steps to update an older version of the plugin to a newer version are the same, except that during file extraction you need to confirm overwriting existing files in addition.

Sender configuration​

One OBS instance will be the sender, on this instance go to the OBS main menu and select Tools -> Beam.

1680640797411.png


A dialog will appear where you can configure the sender identifier and how the sender will accept receiver connections. Named pipe connection is the recommended connection type for local (within the same machine) connections, as it has the least overhead and therefore should come with the smallest resource impact. If you need to connect receiver and sender from different machines you need to use a TCP socket connection. Compression configuration depends on the setup and use case, read above sections for more information.

⚠️ During beta very many compression settings will be available to play around with, however, that doesn't mean they're all sensible choices. In fact, 80+% of combinations won't make sense, i.e. have high CPU usage but still also high bandwidth usage. After it has become a bit clearer what good combinations are others will be removed again when moving towards a stable release. In the meantime it's very important that you experiment and measure for yourself. If unsure, a safe option is using only LZ4 at FAST (level 1) for the lowest CPU usage and lowered but still very high bandwidth usage - it's also a compression mode that reliably works for color formats other than BGRA. If you're fine with setting the color format to BGRA (which comes with a CPU usage hit of its own but in some scenarios also with a quality boost depending on your inputs) then disable LZ4 and use QOI level 5, which is at already a bit less than half of raw bandwidth if you're lucky, or QOI level 10, which could get you down to less than a third of raw bandwidth usage on a sunny day while still being relatively nice to your CPU.

It doesn't seem reasonable to ever use higher LZ4 compression levels than FAST but since it was very easy to implement them I decided to put it in at least for the beta period, maybe someone finds a scenario where it's actually a good choice.

For the "Compress from OBS render thread" option the rule of thumb would be to leave it enabled as long as you're not dropping frames in any of the OBS instances, if you do, then disable that option (will be more likely to be necessary the higher the compression level you pick).

In any case I would be happy about reports of your experimentation results in the OBS forum.

1681262385042.png


Check the "Enable Beam output" box if you want your output to be active now. Press OK to save the settings.

Note that as soon as the output is active your resource usage from OBS will go up, as OBS is now providing data to this plugin (regardless of whether the plugin is doing something with it at this point). Also certain video and audio settings (e.g. video resolution, FPS...) are locked in the OBS settings as long as an output is active. If you want to change those settings, you first need to disable the Beam output again.

An output is currently the only way to send data. A filter based sender solution to send only the data of a single source might be added to xObsBeam as a new feature later.

Receiver configuration​

At least one OBS instance will be the receiver (multiple receivers can connect to a sender), on a receiver instance add a new source of type Beam.

1680640821592.png


Double click the source to edit its properties.

1681176420727.png


Make sure to select the same connection type that you previously selected for the sender, also enter the pipe name that you configured for the sender ("BeamSender" in this example). Press OK to save the settings.

Now you can show the new Beam source (click the eye icon next to it) and it should connect to the sender and start to receive data.


FAQ​

  • Q: Why is the plugin file so big compared to other plugins for the little bit it does, will this cause issues?
    A: Unlike other plugins it's not written directly in C++ but in C# using .NET 7 and NativeAOT (for more details read on in the section for developers). This produces some overhead in the actual plugin file, however, the code that matters for functionality of this plugin should be just as efficient and fast as code directly written in C++ so there's no reason to worry about performance on your system.


  • Q: Will there be a 32 bit version of this plugin?
    A: No. Feel free to try and compile it for x86 targets yourself, last time I checked it wasn't fully supported in NativeAOT.

  • Q: Does this work with all color formats and color spaces including HDR?
  • A: It should work fine when not using compression for every available OBS color format/space setting including HDR, since OBS data is just transferred 1:1. This is also true when using LZ4 compression. QOI compression, however, is designed only for RGB(A). Its basic logic on byte level will still achieve some compression in most scenarios, but results may vary a lot, hence xObsBeam will show a warning when you enable QOI on any other color format than BGRA.


For developers​

C#​

OBS Classic still had a CLR Host Plugin, but with OBS Studio writing plugins in C# wasn't possible anymore. This has changed as of recently as you can see, this plugin is fully written in C#.

Source code is available, I hope it can be a starting point for other C# developers who also want to look into OBS plugin programming using .NET 7 and NativeAOT.

Used libraries/technologies​

This plugin uses the following libraries/technologies:

Compression is simply applied to each frame separately, QOI is not a video codec anyway and LZ4 not even tailored for images. It just so happens that QOI is compressible and LZ4 is a very fast compression algorithm, creating a good combination to further reduce bandwidth needs while still staying lossless and keeping CPU usage low.

Credits​

Many thanks to kostya9 for laying the groundwork of C# OBS Studio plugin creation, without him this plugin (and hopefully many more C# plugins following in the future) wouldn't exist. Read about his ventures into this area in his blog posts here and here.

Also thanks to fzwoch for his wonderful Teleport plugin and for many interesting discussions on Discord that helped me along the way of creating this and other plugins.
  • 1680640810062.png
    1680640810062.png
    10.2 KB · Views: 64
  • 1680640827874.png
    1680640827874.png
    11.3 KB · Views: 57
  • 1681176103652.png
    1681176103652.png
    23.3 KB · Views: 53
  • 1681176278511.png
    1681176278511.png
    22.1 KB · Views: 50
  • 1681176322971.png
    1681176322971.png
    21.9 KB · Views: 49
Author
YorVeX
Downloads
391
Views
2,655
First release
Last update
Rating
5.00 star(s) 2 ratings

More resources from YorVeX

Latest updates

  1. Version 0.7.3 Beta

    What's Changed b61c4e8: Fix feed getting distorted/greenish colors with certain settings since...
  2. Version 0.7.2 Beta

    What's Changed 28bf7db: Support JPEG frame skipping only for lossless mode (wasn't working...
  3. Version 0.7.1 Beta

    Known issues in this release #14: Odd resolutions like 1279x719 cause screen distortions when...

Latest reviews

God tier plugin, This is the plugin what I needed for a long time. now I can some 5GbE, or faster NIC.
In v0.6.0-beta, I didn't face any bug, even the network is not that fast to fit my need. but a beam source doesn't refresh itself, when a sender setting have changed.
Also I hope there is beam video filter to send a certain source to another OBS.
YorVeX
YorVeX
Thanks for the review and the feedback! A filter for a single source will certainly be implemented later, I just want to sort out a few other things first. Regarding the refresh issue it would be nice if you could describe your issue more thoroughly in the Discussion area. Changing a sender setting should actually make any source disconnect, reconnect and use the new settings.
Top