Beam

Beam v1.0.0

Go to download
Overview Updates (25) Reviews (2) History Discussion
T

TheClawTV

New Member
Hi, I'm trying this out.. but my receiver PC doesn't see the sender. Same version everything, hardwired over ethernet on the same network. Receiver PC doesn't see it in available feeds and manual pipe name also doesn't work.
 
YorVeX

YorVeX

Member
TheClawTV said:
Hi, I'm trying this out.. but my receiver PC doesn't see the sender. Same version everything, hardwired over ethernet on the same network. Receiver PC doesn't see it in available feeds and manual pipe name also doesn't work.
Click to expand...
Pipe is only for setups where both receiver and sender are on the same PC, it doesn't work through network. You need to set both sender and receiver to socket mode.

But thanks for posting this, it reminds me that I actually wanted to make socket mode the default, because that's what most people will want.
 
T

TheClawTV

New Member
YorVeX said:
Pipe is only for setups where both receiver and sender are on the same PC, it doesn't work through network. You need to set both sender and receiver to socket mode.

But thanks for posting this, it reminds me that I actually wanted to make socket mode the default, because that's what most people will want.
Click to expand...
Ah ok, sorry about that.
I set both to socket, they still don't see each other.
 
YorVeX

YorVeX

Member
By default the Beam output isn't enabled (this time intentionally), make sure you have this option checked on the sender from Tools -> Beam at the top of the window, you wouldn't be the first to have overlooked that:
1690489080389.png


If you still have the settings of a Beam source open on the receiver, make sure to close it and open it again, now the sender should appear on the list.

If it still doesn't, read on.

In some networks the automatic discovery through UDP Multicast isn't possible, the main reasons usually are:

- you have a network device in your chain that simply doesn't support this kind of packet and therefore doesn't forward it, often the case with cheap switches, but could basically be any device, including routers
- one or both of the clients are on Wi-Fi, many routers are by default configured to not forward this kind of packet through Wi-Fi, because it can have a negative impact on Wi-Fi performance, for some it's not even configurable
- a firewall is blocking it

There can be other reasons, but whatever it is, that kind of situation is what manual connection mode is for. And that is configured like this:

Sender
Find out the IP of your sender computer, if you don't know how, you can use the interface list in Beam on the server from the Tools -> Beam menu, usually you should find something like "Ethernet", "LAN", or "Wi-Fi" there, in my case the IP we are looking for would be 10.0.0.16 (more commonly you would find there something starting with 192.168... like my VirtualBox interface):
1690488846855.png

This step is only meant to use the list for finding the IP, so you can otherwise leave it set to Any, but setting it to your Ethernet/Wi-Fi interface is also fine. Just don't use any virtual interfaces or Loopback, that wouldn't work.

Still on the sender you also want to disable this option, because you need to configure this port in the next step on the receiver, so you need it to be a fixed and reliable number:
1690489327013.png

Usually you can leave the port set to the default of 13629. If you really think you need to change it, make sure to set it to a number higher than 1024, in best case a 5 digit number to be on the safe side.

Receiver
Open the settings of a Beam source and tick this box:
1690489640846.png

For the Beam sender host address you enter the IP address that you discovered in the step above, for the port the same (or leave it set to its default of 13629 if you haven't changed it). Now you should be able to receive the feed from the sender.

Other troubleshooting
If it still doesn't work, temporarily disable your firewall on both computers. If it now works (the automatic discovery or at least a manual connection) you need to find out how to configure your firewall to allow Beam connections, that's nothing I can help you with, though.
 

Attachments

  • 1690489003486.png
    1690489003486.png
    1.7 KB · Views: 25
  • 1690489077713.png
    1690489077713.png
    3.7 KB · Views: 17
Last edited:
R

RaceDriverMIKU

Member
When the transmitting bandwidth exceeds bandwidth available of ethernet, happens this
4K60 NV12, 1Gbps ethernet.
commit size is about 220GiB, memory usage is 7.6GiB, 90% of Skipped frames due to encoding lag. and it crashs at some point.
It is ok to transmit 640*480 I444, and no memory leak?, but disabling Beam doesn't make memory usage normal.
1691070663459.png
 
YorVeX

YorVeX

Member
RaceDriverMIKU said:
When the transmitting bandwidth exceeds bandwidth available of ethernet, happens this
4K60 NV12, 1Gbps ethernet.
commit size is about 220GiB, memory usage is 7.6GiB, 90% of Skipped frames due to encoding lag. and it crashs at some point.
It is ok to transmit 640*480 I444, and no memory leak?, but disabling Beam doesn't make memory usage normal.
View attachment 96366
Click to expand...
As you can see from the table on the first post 4K60 NV12 would need more like 6 Gbps, you try to squeeze it through a 1 Gbps line, what exactly do you expect to happen? Of course it will fail and break and drop most frames.
1691091900324.png

I agree that this shouldn't cause a memory leak nevertheless, and if it does, it's probably a bug. But fixing that bug won't solve your actual problem, you will still not be able to squeeze 6 Gbps through a 1 Gbps line.

Just use the above table to get an idea what would be possible in raw mode. But I'd rather suggest to lower the bandwidth demand by using some compression, if you have only 1G Ethernet the easiest would probably be to use lossy JPEG compression. There is no table for that, because when using compression the actual necessary bandwidth varies a lot depending on content, so I cannot give any universal numbers how much bandwidth JPEG compressed 4K60 NV12 would need for you, you'd just have to try and see what works.

but disabling Beam doesn't make memory usage normal
Click to expand...
If memory was leaked, then it was leaked, the only way to recover from that is to restart OBS. And then use a setting you have sufficient bandwidth for.
 
R

RaceDriverMIKU

Member
Is it a known bug? I didn't see anyone talks about memory leak. I meant that if bandwidth is insufficient, memory leaks.
I know it will never work properly at all, I'm just wating for a cheap realtek 5GbE controller. I will connect PC to PC directly, and use 1080P I444.
Also, I think things like downloading something, or SMB can cause memory leak at the point.
 
Last edited:
YorVeX

YorVeX

Member
RaceDriverMIKU said:
Is it a known bug? I didn't see anyone talks about memory leak. I meant that if bandwidth is insufficient, memory leaks.
I know it will never work properly at all, I'm just wating for a cheap realtek 5GbE controller. I will connect PC to PC directly, and use 1080P I444.
Also, I think things like downloading something, or SMB can cause memory leak at the point.
Click to expand...
No, I wasn't aware of such a bug until now. Will have to make some tests and try to reproduce it later, probably at some point during the weekend. I created GitHub issue #25 for it.
 
YorVeX

YorVeX

Member
As a heads-up, I have done some more tests and will pretty likely remove these compression options in the near future.
  • JPEG lossless (BGRA)
    • the compression rate is good, but its CPU load is horrible and therefore it's totally contradicting the whole idea of offloading some load from a gaming PC to a streaming PC
  • PNG (lossless, BGRA)
    • compression is worse than QOIR (also lossless BGRA) with higher CPU load at the same time, will be removed in favor of QOIR lossless
  • QOIR lossy (BGRA)
    • The combination of lossy and BGRA is already weird (usually the point of using BGRA is to avoid losses), and when lowering the quality to the point where it's already having a very visible negative impact it still needs more bandwidth than lossy JPEG at the standard 90 quality setting while causing higher CPU load, so it really is worse in all aspects
The following options will remain for compatibility and ease of use reasons, because they work without external dependencies (separate library files that need to be available in specific versions), but will be hidden from the options if better options through external dependencies are available:
  • QOI (lossless, BGRA)
    • will be hidden if QOIR is available, since QOIR lossless is better in all aspects (lower CPU usage, higher compression ratio)
  • LZ4 (lossless, all formats)
    • will be hidden if Density is available, which also works on all color formats and can produce roughly the same compression ratio with lower CPU usage
Let me know when you are currently relying on any of these options and have a case for when they actually make sense that I missed, otherwise expect them to be gone in one of the next releases.


Also the next release will probably introduce QOY, a compression similar to QOI but working with the OBS standard NV12 color format. Here's a few highlights:
  • NV12 is already lossy about the colors, but when you're using OBS with its default setting (which is very likely) then you're already living with this - but the exciting thing about QOY is, that it transports the original NV12 data without introducing additional losses (unlike JPEG)
  • since you don't need conversions, OBS will not cause extra CPU load for this, in general it's more in the area of QOIR or a bit better
  • I am working on a managed implementation directly in Beam, meaning it will be available without needed any external libraries
  • raw 1080p60 NV12 needs more than 1400 Mbps bandwidth, but for my test feed QOY was able to push it to roughly 800-850 Mbps, which might be just enough compression to actually make lossless 1080p60 NV12 usable on the common 1G networks that most people have at home, given enough CPU power - no promises though, your mileage will vary
 
Last edited:
YorVeX

YorVeX

Member
RaceDriverMIKU said:
When the transmitting bandwidth exceeds bandwidth available of ethernet, happens this
4K60 NV12, 1Gbps ethernet.
commit size is about 220GiB, memory usage is 7.6GiB, 90% of Skipped frames due to encoding lag. and it crashs at some point.
It is ok to transmit 640*480 I444, and no memory leak?, but disabling Beam doesn't make memory usage normal.
View attachment 96366
Click to expand...
I cannot reproduce any memory leak with the current 0.8.3 version. I changed my network card to 1G mode and set OBS to transmit 1080p60 BGRA, which would need 3800 Mbps and therefore constantly disconnects, because the available bandwidth is not sufficient. I let this run for a long time, the memory consumption stays stable. Left side receiver, right side sender:
1691438110639.png

Please do a test with OBS configured to run only Beam and check whether the problem still occurs, it might be caused by something else if you indeed have a memory leak somewhere (your screenshot doesn't show this).
 
R

RaceDriverMIKU

Member
youtu.be

SHANA VID 20230809 165202

1920x1080, 60000/1000, I444, Rec. 709, Limited
youtu.be youtu.be
Download zip file from github, and install xObsBeam only, launch it as portable mode.
Memory also leaks from my laptop when I host it, but seems that garbage is collected at some point, not just keep growing.
Maybe it is because I set max of page file about 230GiB?(I did same thing with my laptop)
Receiver side is just working fine, memory usage graph is just like what you've uploaded. if the resoultion is too big, memory usage fluctuates, but no leak, at least.
 
YorVeX

YorVeX

Member
RaceDriverMIKU said:
youtu.be

SHANA VID 20230809 165202

1920x1080, 60000/1000, I444, Rec. 709, Limited
youtu.be youtu.be
Download zip file from github, and install xObsBeam only, launch it as portable mode.
Memory also leaks from my laptop when I host it, but seems that garbage is collected at some point, not just keep growing.
Maybe it is because I set max of page file about 230GiB?(I did same thing with my laptop)
Receiver side is just working fine, memory usage graph is just like what you've uploaded. if the resoultion is too big, memory usage fluctuates, but no leak, at least.
Click to expand...
That page file is crazy big, why did you set it that high? Just let Windows manage it.

Just for clarification, when in the video you say "started" at 0:28 this is when you connect the receiver, right?

Since I cannot reproduce it myself here there must be a difference between your setup and mine that we didn't find yet - and it's important to find it to be able to fix it. What might help is if you could start this portable OBS with --verbose mode, run the test (a minute should be enough), then exit OBS, restart OBS and upload the previous log and send the link to the log here.
1691597243728.png


Another question: what happens when you transmit with a speed that your 1G connection can handle, e.g. 720p30 with NV12 just to be on the safe side? Do you still get ever-increasing memory usage on the sender PC or does it stay stable in this case?
 
R

RaceDriverMIKU

Member
YorVeX said:
Just for clarification, when in the video you say "started" at 0:28 this is when you connect the receiver, right?
Click to expand...
Yes, this is when I enable Beam source from receiver side to receive the stream.
YorVeX said:
Another question: what happens when you transmit with a speed that your 1G connection can handle, e.g. 720p30 with NV12 just to be on the safe side? Do you still get ever-increasing memory usage on the sender PC or does it stay stable in this case?
Click to expand...
If bandwidth is sufficient, there is no ever-increasing memory usage at all just like using OBS without any plugins. and I tried streaming 720P 30FPS I444 for about an hour yesterday, no leak at all.(PC to PC directly by RTL8153 NIC for both)
It does stay stable in this case.

Log with -p --verbose.
 
YorVeX

YorVeX

Member
RaceDriverMIKU said:
Yes, this is when I enable Beam source from receiver side to receive the stream.

If bandwidth is sufficient, there is no ever-increasing memory usage at all just like using OBS without any plugins. and I tried streaming 720P 30FPS I444 for about an hour yesterday, no leak at all.(PC to PC directly by RTL8153 NIC for both)
It does stay stable in this case.

Log with -p --verbose.
Click to expand...
Thanks for taking the time, because of your report and your log I could now find out what the problem is.

Normally you need to calculate the effective FPS by dividing the FPS numerator by the denominator, but Beam didn't correctly do this. For the recent versions I already fixed this in some cases where I noticed this, but apparently I still missed a few cases where Beam still only takes the numerator. For the standard FPS settings this is not a problem, because 60 is 60/1 for numerator/denominator or 30 is 30/1. But for some reason you have set it like this according to the log:
1691705265354.png

If calculated correctly, this would also result in 60 and be fine, but since Beam only takes the numerator it thinks you're running at 60000 FPS in some areas of its code :-)

I wonder how this is happening though, did you manually configure it like this for some reason:
1691705395356.png


For you as a workaround just set it to 60/1 and you should no longer get the memory leak and instead get the normal behavior of Beam reconnecting roughly every second when the bandwidth is not enough.

The fix will be part of the next release, I don't think we need a hotfix specifically for this, because it will only be an issue in the rare combination of less common FPS settings like this and constantly insufficient bandwidth.

Thanks again for taking the time to report this problem!
 
Last edited:
You must log in or register to reply here.
Top