Beam

Beam v1.1.0

microsleep

New Member
Just for the record, this is from the log of my Gaming-PC (sender). The IP 192.168.1.8 is the streamingPC.

13:36:32.161: [xObsBeam] <192.168.1.8:52786> New client connected.
13:37:07.753: [xObsBeam] <192.168.1.8:52786> Warning: Send queue size 3 (6) at video frame 326837524237958.
[25 more same warnings]
13:37:08.204: [xObsBeam] <192.168.1.8:52786> Warning: Send queue size 30 (52) at video frame 326837974237940.
13:37:08.222: [xObsBeam] <192.168.1.8:52786> Error: Send queue size 31 (54), skipping video frame 326837990904606.
[15 more similar warnings]
13:37:08.487: [xObsBeam] <192.168.1.8:52786> Error: Send queue size 47 (81), skipping video frame 326838257571262.
13:37:08.487: [xObsBeam] <192.168.1.8:52786> Receiver timeout.
13:37:08.488: [xObsBeam] <192.168.1.8:52786> Disconnecting client...
13:37:08.488: [xObsBeam] <192.168.1.8:52786> ObjectDisposedException in send loop: Cannot access a disposed object.
13:37:08.488: Object name: 'System.Net.Sockets.NetworkStream'.
13:37:08.488: at System.ThrowHelper.ThrowObjectDisposedException(Object) + 0x42
13:37:08.488: at System.Net.Sockets.NetworkStream.Write(ReadOnlySpan`1) + 0x68
13:37:08.488: at System.IO.Pipelines.StreamPipeWriter.FlushInternal(Boolean) + 0xd3
13:37:08.488: at System.IO.Pipelines.StreamPipeWriter.Complete(Exception) + 0x30
13:37:08.488: at xObsBeam.BeamSenderClient.<SendLoopAsync>d__30.MoveNext() + 0x11dc
13:37:08.488: [xObsBeam] <192.168.1.8:52786> Disconnected.

[ And as mentioned, no buffer warnings or entries like those if I test between the Gaming-PCs ]
 

YorVeX

Member
did you already test to change or swap a cable? since currently most indicators point towards the streaming PC, I would start there. does that one also have a dedicated network card? also, I guess if only PC 1 or only PC 2 are sending a feed to the streaming PC there is no issue there, and the problems only start when both send simultaneously?

the log messages basically just say that frame data cannot be sent fast enough and therefore Beam starts to skip frames to keep the feed at least partially alive. unfortunately that still doesn't really tell us what the cause of this is.

of course there is also still a small chance that there is a bug in Beam. while I have done a lot of tests with all sorts of configurations, I think I haven't tested sending two "big" feeds from two different PCs to a streaming PC. can you tell me more about your configuration? what res and FPS are the two feeds set to, and do you actually receive and composite them at the same time, e.g. for a split screen view?

maybe it's easier if we continue this discussion on Discord, my Discord server has a #tech-talk channel where we could also discuss this in german. don't want to link it here though, I am sure you can find it if you follow my profile information here or on GitHub ;-)
 

microsleep

New Member
Yes exactly, we use Beam for a split screen or dual screen setup. One person is in focus and the second screen is in small and then we change the main screen from time to time :)

Both Gaming PC send their video with 1920x1080 @ 60 FPS. On the streaming PC we scale it down to 636p or 720p. But nothing special. Since we usually don't send gamesound (but music from streamingpc), we don't use audio.

I tested audio though, and it was stuttering/cutoff. But I guesses it has todo with the buffering too, but I didn't investigated it further since it didnt matter for us. I could again check that and post the log entries, but as you will read below, Beam is not the cause of our problem anyway (since I could test NDI again yesterday).

---

Since auto discovery didn't work because of the firewall, I tested NDI again yesterday. And indeed, it was probably blocked by the firewall (sender). We then streamed with NDI for a while. And: We also had disconnects here, although not as often.


--> I think we can rule out a bug in Beam with this!

Thanks for all the help so far, your big time investment and effort <3

I think, I'll join the Discord anyway, thanks :)

---

No, I haven't changed the cable yet. I'll test it today too.

I also have to admit that I forgot to update another plugin. We still use obs-multi-rtmp to stream to Kick as well. I updated that today, let's see if that plays a role. If that doesn't help, I'll also do a test without multistream.

Thanks again for everything, it has helped me a lot so far. Even if it's just for possible causes/solutions and ideas :)

best regards

---

1704891347693.png
 

microsleep

New Member
Unfortunatly can't edit anymore. And doesnt really matter, because Beam is not the cause :)

But to be precise to your questions:

- The StreamingPC has a (new) dedicated Etherner Card & The GamingPCs have both on-board-LAN (both about 3 yrs old, same mainboards)
- I'm not sure if it works flawlessly with only 1 PC. But the warnings appear even with only 1 Gaming-PC, but I didnt stream to Twitch. Since there are no warnings when testing between the GamingPCs (without the StreamingPC), I guessed it won't matter. Will test that too.
 

YorVeX

Member
Unfortunatly can't edit anymore. And doesnt really matter, because Beam is not the cause :)

But to be precise to your questions:

- The StreamingPC has a (new) dedicated Etherner Card & The GamingPCs have both on-board-LAN (both about 3 yrs old, same mainboards)
- I'm not sure if it works flawlessly with only 1 PC. But the warnings appear even with only 1 Gaming-PC, but I didnt stream to Twitch. Since there are no warnings when testing between the GamingPCs (without the StreamingPC), I guessed it won't matter. Will test that too.
A few buffer warnings every now and then would still be OK. As long as it's not warnings that frames are skipped, which is where quality takes a hit and usually it's not acceptable anymore (unless it's like 1 frame dropped every hour or so). But if you get multiple warnings and several skipped frames, then it's not necessary to test with a stream, at that point it means you already got a problem. And 1080p60 shoudn't be an issue on a standard 1 gbps network.

None of the computers involved is otherwise overloaded, right? No high CPU usage and so on?
 

microsleep

New Member
Ok, thats nice to know at least :)

No, none of them has especially high load. On the gaming PCs it depends on the game, but it happens also with games which dont use much cpu/gpu. And the streaming PC is also not running on full load. I use it also to stream music with visualizations, and in that case the streamingPC has much more load but no disconnects (since not using NDI/Beam).

So I'm still testing for software & hardware issues these days. Now step by step, e.g. new cable since today.

Again many thx for your effort and detailed help & explanations. :)

I really appreciate it. And of course I'll come back to report as soon as I can tell more.
 

MrBen_Gaming

New Member
So I have implemented OBS beam and it is working great for sending my local OBS feed out for broadcast. However one problem I have come across now is that I am unable to separate the music track for VOD purposes. Is my only option to add the music at the final stage? Or am I missing a trick here?

Many thanks great plugin
 

YorVeX

Member
So I have implemented OBS beam and it is working great for sending my local OBS feed out for broadcast. However one problem I have come across now is that I am unable to separate the music track for VOD purposes. Is my only option to add the music at the final stage? Or am I missing a trick here?

Many thanks great plugin
Assuming that you're already capturing the music separately in some way (you need to do that anyway to have it on a separate VOD track, even without Beam and a single PC setup), you then just add an audio only Beam sender filter to the device or source you got the music on, call this feed "Music" for example.
1706096535726.png


Then on the receiver OBS just add another Beam receiver source that receives this "Music" feed and assign it to the VOD track in the advanced audio properties, I think it's track 2 by default, so it would look like this:
1706096634977.png


If you need help with the actual audio setup part to get the music separated, which can be a bit tricky depending on how you want to set it up (VoiceMeeter, App audio capture, OBS audio monitoring based on otherwise unused audio devices...), I'd suggest to ask about it on the OBS Discord, there is a separate #audio-setup channel for things like this, as it's a bit out of scope for Beam.
 

MrBen_Gaming

New Member
Assuming that you're already capturing the music separately in some way (you need to do that anyway to have it on a separate VOD track, even without Beam and a single PC setup), you then just add an audio only Beam sender filter to the device or source you got the music on, call this feed "Music" for example.
View attachment 101157

Then on the receiver OBS just add another Beam receiver source that receives this "Music" feed and assign it to the VOD track in the advanced audio properties, I think it's track 2 by default, so it would look like this:
View attachment 101158

If you need help with the actual audio setup part to get the music separated, which can be a bit tricky depending on how you want to set it up (VoiceMeeter, App audio capture, OBS audio monitoring based on otherwise unused audio devices...), I'd suggest to ask about it on the OBS Discord, there is a separate #audio-setup channel for things like this, as it's a bit out of scope for Beam.
Thank you, at the moment I capture it on the source machine. Its separated out using Wave link. So I can do that. I will have a look at how I can exclude it from the main feed.
 

MrBen_Gaming

New Member
So I am spontaneously getting an "[xObsBeam] Warning: High receive buffer size error". I am streaming 1080p over an 1gb network. Would this be responsible for my video audio not quite being in sync and are there any variables I can use to tune it? Other than that though. Great plugin I have started testing it with my stream and I get such an improved performance on the source pc.
 

MrBen_Gaming

New Member
Also something else I am unsure of, I am running beam in the background during my day and I have hit it a couple of times today where I will lose any sort of network socket. Looking at netstat Java.exe has a tonne of ports established. Around 30k.
 

MrBen_Gaming

New Member
So I am spontaneously getting an "[xObsBeam] Warning: High receive buffer size error". I am streaming 1080p over an 1gb network. Would this be responsible for my video audio not quite being in sync and are there any variables I can use to tune it? Other than that though. Great plugin I have started testing it with my stream and I get such an improved performance on the source pc.
Retract that, might not be this. Just a coincidence. Testing again.
 

YorVeX

Member
Just a few notes here that could aid you while investigating this:
  • if the high receiver buffer message only occurs from time to time, it's nothing to be concerned about, it's only becoming an issue if it's happening all the time or if you get the next escalation of the message saying that frames were dropped having reached the max buffer size
  • 30k sockets is a lot, the only case where this might be normal would be if you'd be running some kind of file sharing software (torrent or others), but even for this case it sounds like too many to me, and while that's technically not hitting a limit yet, it's putting a lot of load on the network stack and could indeed cause issues in other programs that depend heavily on network (like Beam)
  • Java is not related to OBS or Beam - if you're unsure what it is, kill the process in task manager and see what is affected by that
  • if after making sure you no longer got so many sockets in use you still get very many receiver buffer warnings, check the network bandwidth that is used in task manager, you can also play with the various compression options that Beam has and observe how network bandwidth and the occurence of these warnings is affected by it to narrow the issue further down

I have gone to lengths making sure that A/V desync doesn't occur even in rough scenarios, I tried a deliberately unstable Wifi, killing and restarting OBS during sessions, overloading the machine and making OBS lag, to name just a few. Basically I've been throwing as much shit at it as I could and tried to break it as hard as I can, then fixed what I found, until I could no longer make it break no matter how hard I tried and it would never become desync.
If you got a reproducible scenario where this still occurs, I am very interested to thoroughly investigate, but then I'd first need a lot more info about your setup. Many pieces of information would be in a log file, uploaded through the Help menu in OBS, one from the sender and one from the receiver OBS each, after you finished a longer session where you ran into that issue (ideally noting when the issue started to occur so that it can be mapped to a timestamp in the log files).

But note that what I just said is for the case where you have sound and video in one stream from the OBS output (the one you configure in the Tools menu in the sender OBS). When you generate/produce/process/send audio and video separately then Beam doesn't have any way of knowing what belongs together with which timing so it can't do much about desyncs.
 

microsleep

New Member
Ok, thats nice to know at least :)

No, none of them has especially high load. On the gaming PCs it depends on the game, but it happens also with games which dont use much cpu/gpu. And the streaming PC is also not running on full load. I use it also to stream music with visualizations, and in that case the streamingPC has much more load but no disconnects (since not using NDI/Beam).

So I'm still testing for software & hardware issues these days. Now step by step, e.g. new cable since today.

Again many thx for your effort and detailed help & explanations. :)

I really appreciate it. And of course I'll come back to report as soon as I can tell more.
Finally, some final feedback from me on my problem. As you suspected from the beginning, the problem was *not* with xBeam :)

Unfortunately, I can't say exactly what the solution was, because I did the following at the same time. BUT it was definitely hardware related:

- Changed cable
- Changed the port on the router
- Reinstalled the LAN card driver again

In any case, everything is now running perfectly again!

Thanks again for your really great support & effort and of course for this great plugin.

Best regards
microsleep

P.S. I now have another instance of OBS running, and xBeam offers me everything I need there too. The audio/video filters for individual sources are also very practical. Just amazing <3
 

MrBen_Gaming

New Member
So my sync issues are happening between sources which are sent separately. So that is my bad.
I was looking at how I could combine the two for transmission together. However I cannot find a way to combine my cam and mic channels together. I tried putting the two into a scene but I cannot attach a beam sender to it. Do you know of any other way I could get around it?
 

YorVeX

Member
So my sync issues are happening between sources which are sent separately. So that is my bad.
I was looking at how I could combine the two for transmission together. However I cannot find a way to combine my cam and mic channels together. I tried putting the two into a scene but I cannot attach a beam sender to it. Do you know of any other way I could get around it?
That's really something which could be debugged better in an interactive chat, to also explore your setup bit by bit. The issues you describe are sounding like what you would run into half way into an audio separation attempt, because by default you would only have the opposite problem, that everything is mixed together and you want it separated, i.e. you set your desktop audio device and input device (mic) in OBS, and then everything would be mixed together in OBS, so when sending this from a Beam output you would have your game/desktop capture, cam, desktop audio (e.g. game sound, Music, Discord...) and mic sound all in one Beam feed and for this scenario nothing would get desync (or you ran into a very rare case that I didn't find and fix yet).

If from there you want to separate your music track for the Twitch VOD track (as you stated above), I don't know how it would happen that suddenly you can't sync your mic (which somehow is suddenly separate?), so I assume there is a few more steps you've taken that I don't know about - and that probably didn't make sense to begin with :-)

But really, I mean it when I say it, this kind of audio stuff is hard, pretty much everyone is struggling with getting it right on their first attempt. Which is why the OBS Discord has an #audio-setup channel only for this. I won't be able to set this up with you here on this discussion forum, unless we want to go back and forth in 200 posts for weeks or months, and it's also not really in the scope of what I am able to support here. It's not really a Beam question either, you'd have exactly the same challenges with NDI or Teleport or even a capture card setup. Coincidentally, only within the last few days I have literally seen someone ask how to do such a setup for NDI, Teleport and capture card each on that Discord (3 different users indepedently from each other), which doesn't surprise me, it's a very common thing.

None of the setups you could use are easy or straightforward. To only give some rough ideas about various concepts (I am by no means very experienced with this either and probably miss or misremember a few things):
  • Use VoiceMeeter to have virtual audio devices. Play your game sound to one virtual device, music to another. Usually you would do this by having the device that is supposed to capture game sound and things like Discord or stuff that is played when you open a browser configured as your default audio device in Windows. This is what you also select as desktop audio device in OBS, so that all of that becomes part of the main feed which will be in the main Beam output (the one configured from the Tools menu on the sender OBS). Then you configure a different virtual audio device for your music player, which can be either done from the settings of the music player itself or in Windows.
    Now in VoiceMeeter you can set up what goes where, make sure that the virtual device the music is played to is routed to your physical audio output (e.g. your headphones). This way you can hear it yourself, but OBS will not capture it in its main feed, since it's not in the virtual device that you configured as your default device.
    Next you add an additional audio capture source to OBS and set this to the virtual device that contains the music. Add a Beam audio sender filter to this, call it "Music".
    On the receiver side you can now add a source for the main Beam output, which will contain your video scene, your mic audio and all of the desktop sound played to the default device on your gaming PC, except the music, since you configured that to play to the separate device. Then you add another Beam source tuned into the "Music" feed which you can then assign to the Twitch VOD track in OBS, and the main audio source to all tracks.
  • Even without VoiceMeeter you can do something similar if you have an audio device in your system that you don't need, e.g. many people have an audio device from their PC monitors. This could be used as a virtual device to play your music to, but only if your monitor doesn't have speakers (mine would play something to a chinch output, and just play nothing when nothing is plugged in). You can then add this audio device to OBS the same way as above (as audio capture) and set it to Monitor Only in the advanced audio properties (or don't assign it to track 1, IIRC Beam will only transmit what is on this track), this way only you will hear the music that is played to it but it will not become part of the Beam output. And then same thing as above, add a Beam filter to it, call it "Music" and follow the steps described in the first bullet point.
  • Another way would be to use the "Application Audio Capture (BETA)" sources, but then you need to capture everything separately and can't use desktop audio. So you add one capture for game sound, one for Discord, one for a browser, whatever you need to be in the main feed. Leave these on default settings so that they're played on both your audio monitor and the main feed. The same way, add an app audio capture for your music player app, e.g. Spotify, and the same as above don't assign it to track 1 or set it to monitor only so that only you hear it, add a Beam filter to it, again, same as above.
In all of these setups your mic sound stays in the main output where also the cam and game sound are, so it wouldn't get out of sync with them (especially not the cam, which is important for lip sync). The music being a separate feed might go out of sync a bit in this setup, but viewers could only ever notice this if you're singing along - maybe then just don't do this :-P

But really, this is only to give you a starting point, try to find help in an interactive chat if you run into issues with it, and don't be ashamed about it, almost everyone is having a hard time getting it right.
 

Naruske

New Member
Are we supposed to keep the compression levels default (I see most are on level 10) is there any noticable visual impact? I'm changing between default density and Qoy (comp level 7) and it appears to look the same. But I'm not sure...
 

YorVeX

Member
Are we supposed to keep the compression levels default (I see most are on level 10) is there any noticable visual impact? I'm changing between default density and Qoy (comp level 7) and it appears to look the same. But I'm not sure...
Density and QOY are both binary lossless formats, meaning you get on the receiver side exactly the same quality you sent on the sender side, hence there is no visible difference between them. They differ mostly about bandwidth and CPU usage and about which color formats they're supporting. Also changing the level for them doesn't have a visual impact, again, only on bandwidth vs. CPU usage (lowering the level means increasing the bandwidth demand and lowering CPU usage, because then a smaller amount of frames are compressed using CPU work).

There is always this trade-off: either you compress more, which means more work for your CPU to do but decreases the amount of data that has to be sent through the network (bandwidth demand), or you only compress a certain percentage of frames, letting the CPU do less work but meaning more data has to be pushed through the network. So the level setting basically is a direct control of said "CPU usage vs. network bandwidth" trade-off. Having this is unique to Beam.

The default in Beam is JPEG, which is a lossy format. It's the same that is used for .jpeg or .jpg image files, just applied to every single frame of the video feed as if they were separate images (30 images per second at 30 FPS, 60 at 60 and so on). The loss of data is achieved in a very clever way so that in most scenarios you won't notice it unless you look very close.

It is the default, because it has the lowest bandwidth needs of all options, and the majority of people have standard Gigabit networks at home, which for video content transmission isn't as fast as you might think - so this option has the highest chance to just work out of the box for most people.

The other options are for enthusiasts or advanced users who want to achieve higher quality levels than Beam with JPEG, NDI, or Teleport (or pretty much any other transmission option) would have, and also have the hardware for it - usually meaning a wired network faster than 1G, or they only want to transmit locally from OBS to OBS (to have one OBS for recording a clean feed, and forward this to a 2nd OBS that adds panels and alerts to this feed before sending it to a live streaming platform), where you can go even completely without compression. On 1G with a beefy CPU using QOY might also be an option, often it would stay around 800-900 Mbps, so just barely staying within the limits of a 1G (meaning 1,000 Mbps) network, which can work if the network isn't used a lot otherwise and it's not an issue that latency in online games might suffer a bit.

This wiki page has a comparison table and more details on them, including a "Which should I use?" section helping with the decision.
 
Last edited:

Sir_Coleslaw

New Member
Hello everyone, if this question has already been answered, a link to the answer will suffice as an answer.

My Specs:

Dual PC Setup:

Transmitter PC (HDR Capable):
7950X3D
4090
3440x1440@144Hz HDR

Receiver PC (Only SDR):
9900K
2070S
SDR Monitor

What settings do I have to make on the OBS transmitter/receiver so that my HDR signal arrives cleanly tone-mapped on the receiver and can be streamed from there to Twitch?

Do I have to do the tone mapping in the OBS transmitter or in the OBS receiver? Currently, my signal on the receiver is very washed out.

My goal is to play in HDR but stream in SDR.


Thank you!
 

YorVeX

Member
Hello everyone, if this question has already been answered, a link to the answer will suffice as an answer.

My Specs:

Dual PC Setup:

Transmitter PC (HDR Capable):
7950X3D
4090
3440x1440@144Hz HDR

Receiver PC (Only SDR):
9900K
2070S
SDR Monitor

What settings do I have to make on the OBS transmitter/receiver so that my HDR signal arrives cleanly tone-mapped on the receiver and can be streamed from there to Twitch?

Do I have to do the tone mapping in the OBS transmitter or in the OBS receiver? Currently, my signal on the receiver is very washed out.

My goal is to play in HDR but stream in SDR.


Thank you!

Unfortunately I don't have any experience with processing HDR in OBS whatsoever and that's more of an OBS question than a Beam question, so I think you should maybe ask about how proper tone-mapping is done on the OBS support forums or Discord.

Beam will just transmit whatever it is given, with the limitation that only uncompressed or format agnostic compression options (LZ4 and Density) support HDR, as you can see in the table here. If it's currently washed out, you're probably using one that doesn't properly support it.

In theory if you don't plan to actually record HDR it can be done on both the sender or receiver OBS, but I'd do it on the sender side, because then you won't be limited in your Beam compression options as stated above, which would especially be a problem if you only have standard gigabit ethernet, that most probably wouldn't suffice for transmitting HDR.
 
Top