Beam

Beam v1.1.0

As a reference, I just tried sending raw 1080p60 BGRA (that should theoretically have 3729 mbps net bandwidth) over my 10G network and according to Windows Task Manager get a 4.1 gbps throughput, so that's what you always have to expect on top of the net values, quite significant difference. The good news is that it's 100% stable here with Beam.

When I started this plugin my only use case was local (named pipe) transmission, but then I just couldn't resist to try it over network and I am happy it really is working. Looking forward to hear about the LACP results.

I tried to open it up at full 1080p59.94 (doing ATSC framerates here) at BGRA. Machines slowed to an abject crawl. Throughput never got faster than 960 or so megabits per second.

However, I'm having better luck with JPEG compression, regardless of color format, though I'm having the best sound sync using NV12+lossy JPEG. I'm having to do some tweaking to make sure I'm not overwhelming the computers. I'm not sure if it's the LACP that's getting overwhelmed or doing the overwhelming, or if it's the encoding of the video before hitting the wires.

As I'd previously noted, I'm running three sixth-gen Core i7s in my array, the Core i7 6700, in two of the setups with LACP, with the third LACP setup running on a Ryzen 7 5800X. They quickly get overwhelmed if I use LZ4 or QOI compression or none at all. Is there any way of telling where things start to go south so I can report on that?

Also a final note, audio channels are in the right places now. Thanks for that fix!

--Katt. =^.^=
 

YorVeX

Member
I tried to open it up at full 1080p59.94 (doing ATSC framerates here) at BGRA. Machines slowed to an abject crawl. Throughput never got faster than 960 or so megabits per second.

However, I'm having better luck with JPEG compression, regardless of color format, though I'm having the best sound sync using NV12+lossy JPEG. I'm having to do some tweaking to make sure I'm not overwhelming the computers. I'm not sure if it's the LACP that's getting overwhelmed or doing the overwhelming, or if it's the encoding of the video before hitting the wires.

As I'd previously noted, I'm running three sixth-gen Core i7s in my array, the Core i7 6700, in two of the setups with LACP, with the third LACP setup running on a Ryzen 7 5800X. They quickly get overwhelmed if I use LZ4 or QOI compression or none at all. Is there any way of telling where things start to go south so I can report on that?

Also a final note, audio channels are in the right places now. Thanks for that fix!

--Katt. =^.^=
It sounds a bit suspicious that you would stay exactly close to a 1 gbps limit, as if the LACP bonding wouldn't be used correctly for Beam so it has only the bandwidth of a single gigabit connection. Do you have to select a specific network interface to use the bonded one? If so, I assume you have done that for the Beam sender?

But as I said earlier, selecting an interface is currently not yet possible for the Beam receiver, so maybe the receiver is not using a bonded interface? It's using the default interface, so maybe that's just one of the single interfaces? Also make sure to do an iperf comparison tests between the same machines to be sure you get your full speed there.

That said, since my test has shown that 1080p60 BGRA needs 4.1 gbps you won't be able to do that anyway when even your bonded interface only provides 4 gbps at max. You would have to use compression or go down to at least I444 (which would need only roughly 3 Gbps and should leave you with enough buffer). Or on BGRA are you sure LZ4 on FAST with nothing else selected is already too much for the system? You could also try QOI with a very low level, since this last release the lower levels are actually really low, level 1 would compress only 10% of the frames and level 2 20%, maybe one of these low levels is already sufficient to get it far enough down from 4 Gbps.
 
It sounds a bit suspicious that you would stay exactly close to a 1 gbps limit, as if the LACP bonding wouldn't be used correctly for Beam so it has only the bandwidth of a single gigabit connection. Do you have to select a specific network interface to use the bonded one? If so, I assume you have done that for the Beam sender?

But as I said earlier, selecting an interface is currently not yet possible for the Beam receiver, so maybe the receiver is not using a bonded interface? It's using the default interface, so maybe that's just one of the single interfaces? Also make sure to do an iperf comparison tests between the same machines to be sure you get your full speed there.

That said, since my test has shown that 1080p60 BGRA needs 4.1 gbps you won't be able to do that anyway when even your bonded interface only provides 4 gbps at max. You would have to use compression or go down to at least I444 (which would need only roughly 3 Gbps and should leave you with enough buffer). Or on BGRA are you sure LZ4 on FAST with nothing else selected is already too much for the system? You could also try QOI with a very low level, since this last release the lower levels are actually really low, level 1 would compress only 10% of the frames and level 2 20%, maybe one of these low levels is already sufficient to get it far enough down from 4 Gbps.

I'll have to do some more testing, but selecting the IP address of the LACP virtual interface should, at least in theory, be more than adequate to specify that interface, albeit in an indirect fashion. That said, I hadn't actually tried specifying the address to listen to (I let it bind to all addresses), so that's an action item for me to check.

I'll try the other items you'd mentioned to see if I can get anything in that department. I may be a bit as I have a few things going on elsewhere IRL that's keeping me busy at present. More as I get it.

Thanks!

--Katt. =^.^=
 

FunkyJamma

New Member
Current update broke the plugin everything is just green on the receiving end. I dont use any compression so not sure where the issue is. Reverting back to previous version fixes the issue.
 

YorVeX

Member
Current update broke the plugin everything is just green on the receiving end. I dont use any compression so not sure where the issue is. Reverting back to previous version fixes the issue.
Thanks for the quick report. Windows or Linux? Which OBS version?
And did you update both sender and receiver(s)? This is always very important.
 

FunkyJamma

New Member
Thanks for the quick report. Windows or Linux? Which OBS version?
And did you update both sender and receiver(s)? This is always very important.
They are both windows 10 The receiver is on OBS 29.1.2 and the broadcaster is on OBS 29.0.2 Both installations have the same plugin version.

Sidenote: Not sure if this has been fixed in the current version but I also get crackly sound from time to time. You can hear it here in my stream from last night. https://www.twitch.tv/videos/1832629734
 

YorVeX

Member
They are both windows 10 The receiver is on OBS 29.1.2 and the broadcaster is on OBS 29.0.2 Both installations have the same plugin version.

Sidenote: Not sure if this has been fixed in the current version but I also get crackly sound from time to time. You can hear it here in my stream from last night. https://www.twitch.tv/videos/1832629734
A quick update on this, I could already pinpoint it to commit 03cf2ae having introduced this issue, now I have to narrow it down to the exact part of these changes. Will try to come up with a fixed release as fast as possible, in the meantime just keep on using the old version.

About the audio issue, no, there haven't been any fixes specifically for that so I would assume the problem still exist in the newer version. In the clip you say something about being back and some kind of restart, and I can see that the problems stay throughout the entire clip (though they get better after the first few seconds). Do you by any chance have this option enabled in the Audio settings?
1685481871225.png

I remember that during some tests with Teleport or NDI I noticed that when this option is enabled there is a random chance of this issue occurring right after starting OBS and then staying for the entire session, and an OBS restart means you have another chance of getting this issue vs. not getting it. I talked about it here in my last text segment.

But even if you don't have that option enabled, I would still be curious whether the behavior is the same: you either have it right from the OBS start or you don't. To investigate further, could you please before you start your next streams always do a quick test recording on the sender? If you hear sound issues in this test recording, don't go live but restart OBS and retry until you get a recording where audio is fine. When it's fine go live and check whether the problem exists on the receiver recording.

This will help us narrow down whether the issue already exists in the sender OBS (and OBS has various audio issues by itself unfortunately, e.g. there is this funny thing that might finally get a fix in the next OBS 29.2.X release) or whether it's really something coming from Beam.

If it's coming from Beam then you could try enabling some frame buffering on the receiver and also should keep an eye out for any commits for GitHub issue #12, which will further improve this buffering to help feed video and audio frames in a more steady frequency into OBS.
 

YorVeX

Member
Ok I will try these things and report back.
Great, and thanks again for the quick report, fix is out now as you see.

I am sure you're aware it's a risk to work with beta versions for your live stream (as you've just got demonstrated), but on the other hand I am happy about brave people like you, because only when the plugin is really used the important bugs are found and we can reach a stable version as early as possible.

Out of pure curiosity, the clip was in 1080p60 and you said you're not using any compression. Even with the lowest bandwidth demand on NV12 color format (OBS default) you'd need at least a 2.5G or faster network. Is that what you're using, or are you transmitting within the same PC?
 

FunkyJamma

New Member
Great, and thanks again for the quick report, fix is out now as you see.

I am sure you're aware it's a risk to work with beta versions for your live stream (as you've just got demonstrated), but on the other hand I am happy about brave people like you, because only when the plugin is really used the important bugs are found and we can reach a stable version as early as possible.

Out of pure curiosity, the clip was in 1080p60 and you said you're not using any compression. Even with the lowest bandwidth demand on NV12 color format (OBS default) you'd need at least a 2.5G or faster network. Is that what you're using, or are you transmitting within the same PC?
I stream mostly on weekends so i havent had the chance to test it yet but. Yes I do have the network to support it. It actually has its own isolated network that only links the gaming pc with the streaming pc. This network card only transmits the video feed from this plugin and nothing else. I am also aware of the risk of beta versions. I have no issues trying out unready software.
 

FunkyJamma

New Member
Ok I have a new Issue now and I can't seem to be able to fix it. I updated to the new version on both installs. The receiving computer is choppy no matter what I do. Its laggy and every few seconds it locks up/skips. It didnt do this before and now even reverting back to the previous version which was working is also doing the same thing.
 

FunkyJamma

New Member
Ok new update I got it working but now im not even sure what version im running. Can you add version number inside of plugin UI and on the archive? Would make things easier to trouble shoot and making sure same versions are installed.
 

YorVeX

Member
Ok I have a new Issue now and I can't seem to be able to fix it. I updated to the new version on both installs. The receiving computer is choppy no matter what I do. Its laggy and every few seconds it locks up/skips. It didnt do this before and now even reverting back to the previous version which was working is also doing the same thing.
If Beam is dropping frames you should find information about this in the OBS logs (Help -> Log Files -> View Current Log). Also Beam is extremely talkative there if you set OBS to verbose mode while it's in beta, you would do that by creating a shortcut to obs64.exe and add "--verbose" (without the quotes) to the end of it, separated with a space from the reset. Since you're dealing with Beta software it's probably worth to keep this --verbose shortcut around for a while so that you can fire it up as needed. Can also give a lot of insights about what Beam is doing, but it might have a performance impact of its own so I'd rather not leave it on when going live.

Another thing that would be good to have set up and ready is iperf so that you have an independent way of measuring your max network throughput. E.g. I found that my 10G LAN card (or its driver) seems to be a bit buggy, sometimes it would only send 1.5G at max despite both the driver and LED indicators on the card and switch saying it's 10G. Then I need to restart the LAN card or reset it by changing a driver setting (and then back) and then it's fine again. For this reason I always have the iperf server run on the streaming PC and doing a 10 second measurement is part of my stream start script on the gaming PC:

Code:
echo|set /p="Check bandwidth to streaming server: "
iperf -c 192.168.0.2 -p 5002 |find /I " sec "
pause

(replace 192.168.0.2 with the IP of the streaming server on the network interface for the video feed)

And the last thing that comes to my mind is that you said you use a dedicated network connection for the video feed. Are you sure it's still using that connection and not the other connection? Even without iperf in Windows Task Manager you can also see the actual throughput while Beam is running, if you have another 1G connection and you only get exactly 1G through Beam this would be an indication that it's using the wrong interface (and Task Manager also shows on which interface the traffic is going through).
 
Last edited:

YorVeX

Member
Ok new update I got it working but now im not even sure what version im running. Can you add version number inside of plugin UI and on the archive? Would make things easier to trouble shoot and making sure same versions are installed.
The number is written to the logs on each startup, e.g.:
1685653509922.png


If you're on windows you can also right click the xObsBeam.dll, select Properties and activate the Details tab, you will have the "File version" there:
1685653568903.png
 
The number is written to the logs on each startup, e.g.:
View attachment 94673

If you're on windows you can also right click the xObsBeam.dll, select Properties and activate the Details tab, you will have the "File version" there:
View attachment 94674

Frequently, you can also determine versioning information just by hovering over the DLL in question. It all depends on how the DLL was built. For example, it'll work with your plugin.

--Katt. =^.^=
 

FunkyJamma

New Member
ok just did a 2 hour stream and I noticed that as soon as I turn on enable beam output the audio on the machine starts crackling. This includes my headphones. and its heard on the stream. This is from the broadcasting machine. I have checked this multiple times after i ended the stream. I restarted the computer, used obs in admin and non admin modes etc. All of them as soon as i click apply to Enable Beam output the audio starts to crackle.
 

YorVeX

Member
ok just did a 2 hour stream and I noticed that as soon as I turn on enable beam output the audio on the machine starts crackling. This includes my headphones. and its heard on the stream. This is from the broadcasting machine. I have checked this multiple times after i ended the stream. I restarted the computer, used obs in admin and non admin modes etc. All of them as soon as i click apply to Enable Beam output the audio starts to crackle.
Crackling audio is usually coming from sample rate mismatches, can you upload your latest log to the analyzer and check whether it shows any errors regarding the audio configuration? From OBS main menu select Help -> Log Files -> Upload current log file and then click the Analyze button.

Beam on the sender machine doesn't do anything with audio except telling OBS "give me the raw audio data please" as soon as you enable the Beam output. When activating the output triggers this it means something with your audio setup is not right. The usual check list would be to make all the sample rates match, disable any extra effects (Windows calls them "Enhancements" in the audio settings I believe), try with or without exclusive mode and update to latest audio drivers (or if already on the latest driver version sometimes the opposite can also help, moving back to a bit older drivers, many vendors offer at least the previous driver version on the website). Also disable any audio devices you don't need, e.g. disable any on-board sound chips if you're using a dedicated sound card and disable HDMI audio devices from your monitors or audio from webcams if you don't need them.

Audio setup is so tricky that it even has a support channel of its own on the OBS Discord (and BTW going there and ask for help might also be an option, but since Beam is beta software you should then probably verify first whether it also happens when you enable any other outputs, like those from NDI or Teleport):
1685763320149.png
 
Last edited:
Top