Beam v1.1.0

[YorVeX]

no available beam feed how to ? i use teleport and ndi it show

NDI and Teleport constantly advertise their feeds into your network using broadcasts, even when no source is really active and regardless of a receiver searching for it or not. This means the source in the sender OBS is sending the discovery packets and a receiver OBS can pick them up.

For Beam, it works in the opposite direction. The sender/source is not sending any discovery information until asked for it by a receiver. When you search feeds in the receiver, it sends a broadcast asking for available feeds into your network and all available sources will then respond with their information and be added to the list on the receiver side.

Now, UDP Broadcast/Multicast packets always can have issues in a network in both directions, e.g. because of your router settings or how your network is designed. It might be that the sender PC can't reach the receiver PC or vice versa via this protocol. Depending on which direction works and which doesn't, you can have a situation where Beam can discover sources and NDI/Teleport can't, or NDI/Teleport can discover sources and Beam can't, which seems to be the case for you.

My plan for the future is to make Beam use both approaches simultaneously, to have more scenarios where discovery in Beam is working. But right now, you need to use manual connection mode if discovery doesn't work for you. In the source or Beam output settings, select a LAN IP address from the interface list (e.g. 192.168.100.1) - and on the receiver side enter that IP. Also choose a manual port on the source/output and enter the same port in the receiver. Then you should be able to connect regardless of connectivity.

An example, sender (output) on the left side, receiver on the right side:

 

[ugie]

and 1 more question for what is named pipe ? so we send it to our own computer? isnt it better just use game capture then? for what scenario is it used?

 

[KattPhloxworthy]

and 1 more question for what is named pipe ? so we send it to our own computer? isnt it better just use game capture then? for what scenario is it used?

A "named pipe", in the context of a Unix system, is a special "file" which serves as what it says, a "named pipe". One application writes to it on one side while another reads from it. It essentially allows two programs to talk to each other on the same computer.

I'm not sure how it works on Windows systems, but on Linux and macOS (which uses a FreeBSD-like OS in the form of Darwin underneath the GUI), they look like actual "files", but with a special flag on it to tell the system that, instead of being a normal file, it's something special. That allows programs to treat it as a "normal file", using a lot of the same functions (remember the saying, on Unix everything is a file, from normal files to sockets to pipes).

--Katt. =^.^=

 

[YorVeX]

and 1 more question for what is named pipe ? so we send it to our own computer? isnt it better just use game capture then? for what scenario is it used?

What Katt said. The term "file" (while technically correct) might be misleading, it's not actually written to a disk in this scenario. The whole point of it is to have data exchange happen in system memory, which is a lot faster and has a smaller performance impact compared to running this through a network.

There is multiple edge cases where this can be handy (e.g. for troubleshooting or testing), but the most common scenario I implemented it for is this setup:

Your gaming PC sends a Beam feed to one OBS instance on the streaming PC that is meant for recording only, let's call it "Recording OBS". This is sent normally through the network. This OBS instance is recording the feed to the disk. But it also has a Beam output running itself based on named pipe. Using this, it's passing the same feed on to another OBS instance that is running on the streaming PC that we call "Streaming OBS".
The "Streaming OBS" takes the original feed, but shows additional overlays such as stream panels, alerts when someone is following/subbing/donating, funny clips that users can activate and so on. And it is configured to stream to e.g. Twitch. This can be achieved by running OBS in portable mode instead of using the installer version.

With this setup, you get a live stream with all the features that make a stream more interactive, but also still have a separate recording you can use as base to cut something for YouTube without these things that were mostly relevant to the stream and might be in the way of cut scenes.

With this as a base you're super flexible. You can also have "Recording OBS" receive and record the original 1440p feed but "Streaming OBS" only runs with 1080p because more is not really feasible with Twitch's low bitrate limits. You can also have "Recording OBS" already add some effects that you don't want to run on the gaming PC, e.g. some resource intensive shaders. You can at any time move a chat overlay to "Recording OBS" when you think it should be in the recording, or to "Streaming OBS" if you only want to have it in the stream.

I was even running 3 OBS instances on my streaming PC, because I also recorded my face cam separately from the game feed. This way you can later choose to use scenes either with or without the cam or the cam feed separately when cutting a video for YouTube.

For all of these cases where you need to pass on a feed within the same PC, named pipes have the lowest latency, highest stability, lowest resource usage (especially because you don't need to compress, sending raw is no issue because you practically have infinite bandwidth)...

 

[Iraito]

My CPU usage in jpeg mode doesn't go up at all and it looks like it's actually sending RAW data, any solution?

 

[YorVeX]

My CPU usage in jpeg mode doesn't go up at all and it looks like it's actually sending RAW data, any solution?

Not an issue I have ever heard of.

In OBS from the main menu select: Help -> Log Files -> View Current Log.
This opens a new "Log Viewer" window. Now watch this window while you disable the "Enable Beam Sender Output" check mark and enable it again a second later. When you enable it, do you see something like this?

If not, maybe you see a different message there telling you what's wrong.

 

[KattPhloxworthy]

I finally have a decent 10GbE network in the form of some older Intel AT2-based adapters, an Intel Converged dual-port adapter and a Cisco Nexus 10GBaseT network switch.

I have most of my setup working except for one.

I have four computers on the 10GbE backbone, notably:

• VTuber (runs VTubing software)
• Gaming (runs game or whatever I'm presenting, along with having my headphones and mike)
• Studio (puts the stream together)
• Encoder (makes the stream and pushes it out to Twitch, YouTube, anywhere else or some combination thereof

The VTuber and Gaming machines funnel into the Studio machine, then the Studio machine passes the completed stream to the encoder machine.

Here's how things are looking thus far:

VTuber -> Studio: Works. This goes double because I have to send an alpha channel-enabled stream to overlay on the rest of a scene, requiring me to use BGRA for colorspace, so no JPEG can be used. (I've figured out how to make an opaque stream which can use a mask to communicate an alpha channel, but that's something I'll work on later.)
Gamer -> Studio: Works. I tried both with JPEG and lightly-compressed streams. Both methods work fine. Can stay at NV12 for colorspace.
Studio -> Encoder: Does NOT work. I had to fall back to NDI to make it work.

Everything is using OBS Studio 31.0.1 and Beam 1.1.0. Also, save the VTuber machine which is still running the copy of Windows 10 Pro it came with, everything else is running Windows 11 Pro. The VTuber, Studio and Encoder machines are all Hewlett Packard EliteDesk 800 G2 machine using Core i7 6700 processors, and my gaming machine is a Ryzen 9 7950X3D.

Playing a game of Left 4 Dead 2 while running a full-up streaming setup while using QOY compression with NV12 on the gaming machine and Density compression using BGRA on the VTuber machine throws anywhere from 600Mbps to 1.5Gbps into the studio machine total, and the Studio takes it without batting an eye.

I ran a test recording of what it might be like to stream with this entire setup. It worked extremely well save for that last link, which, again, I had to fall back to NDI to make work. I recorded the result to nearly fully simulate the entire workload of streaming, of course, minus the outbound Internet traffic. I am extremely pleased with how things are going thus far.

Even though the NDI link is theoretically lossless, it's a bit more compressed.

Any suggestions of how to make that last link work or at least to troubleshoot it? I even made sure that Windows Firewall fully permitted OBS Studio to send and receive traffic on a private network and that the interfaces involved are on private segments.

Thanks in advance!

--Katt. =^.^=

 

[KattPhloxworthy]

I finally have a decent 10GbE network in the form of some older Intel AT2-based adapters, an Intel Converged dual-port adapter and a Cisco Nexus 10GBaseT network switch.

I have most of my setup working except for one.

I have four computers on the 10GbE backbone, notably:

• VTuber (runs VTubing software)
• Gaming (runs game or whatever I'm presenting, along with having my headphones and mike)
• Studio (puts the stream together)
• Encoder (makes the stream and pushes it out to Twitch, YouTube, anywhere else or some combination thereof

The VTuber and Gaming machines funnel into the Studio machine, then the Studio machine passes the completed stream to the encoder machine.

Here's how things are looking thus far:

VTuber -> Studio: Works. This goes double because I have to send an alpha channel-enabled stream to overlay on the rest of a scene, requiring me to use BGRA for colorspace, so no JPEG can be used. (I've figured out how to make an opaque stream which can use a mask to communicate an alpha channel, but that's something I'll work on later.)
Gamer -> Studio: Works. I tried both with JPEG and lightly-compressed streams. Both methods work fine. Can stay at NV12 for colorspace.
Studio -> Encoder: Does NOT work. I had to fall back to NDI to make it work.

Everything is using OBS Studio 31.0.1 and Beam 1.1.0. Also, save the VTuber machine which is still running the copy of Windows 10 Pro it came with, everything else is running Windows 11 Pro. The VTuber, Studio and Encoder machines are all Hewlett Packard EliteDesk 800 G2 machine using Core i7 6700 processors, and my gaming machine is a Ryzen 9 7950X3D.

Playing a game of Left 4 Dead 2 while running a full-up streaming setup while using QOY compression with NV12 on the gaming machine and Density compression using BGRA on the VTuber machine throws anywhere from 600Mbps to 1.5Gbps into the studio machine total, and the Studio takes it without batting an eye.

I ran a test recording of what it might be like to stream with this entire setup. It worked extremely well save for that last link, which, again, I had to fall back to NDI to make work. I recorded the result to nearly fully simulate the entire workload of streaming, of course, minus the outbound Internet traffic. I am extremely pleased with how things are going thus far.

Even though the NDI link is theoretically lossless, it's a bit more compressed.

Any suggestions of how to make that last link work or at least to troubleshoot it? I even made sure that Windows Firewall fully permitted OBS Studio to send and receive traffic on a private network and that the interfaces involved are on private segments.

Thanks in advance!

--Katt. =^.^=

I found my problem. It turns out I had jumbo frames enabled on the encoder PC, but not the others.

Furthermore, I didn't have jumbo frames enabled on the switch, whether globally or per-interface (which my Nexus's NX-OS supports).

I had thought that the Nexus might have jumbo frame support enabled by default. Nope...

I added per-interface configurations to enable jumbo frames and made sure all the other computers' 10GbE interfaces had jumbo frames enabled and things are now all fully working.

Going to do another straight-up recording test to prove it offline, then do a full stream.

Sorry about that. (blush)

--Katt. =^.^=

 

[YorVeX]

When I saw the first message on my smartphone and couldn't answer right away, I was already wondering how the hell I should be able to find a fix for this when you've already come this far with such a complex setup and knowing that you're quite knowledgeable about these things in general. That's along the lines of what I was going to respond.

What a relief you actually solved it yourself already :-D

About jumbo frames, I found that their compatibility depends a lot (especially a lot more than other things) on having the latest drivers and being lucky to have devices that play well with each other or ideally are all from the same vendor. In my setup, using the highest value (16348 bytes) had lots of issues like lost packets and strongly fluctuating bandwidth, despite both Ethernet cards communicating being the same model with the same driver and OS. Maybe it's the 2 switches in between that can't handle them properly (they're unmanaged, meaning there's nothing for me to configure). However, 9014 bytes are working perfectly fine (and also 4088 bytes). That's how my drivers show these settings, I know others show 16K, 9K, 4K and 2K instead. So if you still have some issues, try lower values, they're usually already good enough anyway, even 2K makes a lot of difference to having no jumbo frames for the high bandwidth usage Beam has.

 

[KattPhloxworthy]

When I saw the first message on my smartphone and couldn't answer right away, I was already wondering how the hell I should be able to find a fix for this when you've already come this far with such a complex setup and knowing that you're quite knowledgeable about these things in general. That's along the lines of what I was going to respond.

Yep, you definitely know me well enough by now. ;3

What a relief you actually solved it yourself already :-D

Yeah, imagine my relief. ;D

About jumbo frames, I found that their compatibility depends a lot (especially a lot more than other things) on having the latest drivers and being lucky to have devices that play well with each other or ideally are all from the same vendor. In my setup, using the highest value (16348 bytes) had lots of issues like lost packets and strongly fluctuating bandwidth, despite both Ethernet cards communicating being the same model with the same driver and OS. Maybe it's the 2 switches in between that can't handle them properly (they're unmanaged, meaning there's nothing for me to configure). However, 9014 bytes are working perfectly fine (and also 4088 bytes). That's how my drivers show these settings, I know others show 16K, 9K, 4K and 2K instead. So if you still have some issues, try lower values, they're usually already good enough anyway, even 2K makes a lot of difference to having no jumbo frames for the high bandwidth usage Beam has.

Funny part: I ALMOST bought a TP-Link 8-port unmanaged ten-gigabit switch; would have set me back $300 and tax.

A local recycling place I get a lot of my gear at for my streaming setup had two Cisco Nexus C9372-TX-E switches, which I ended up buying for half that. :P

The upshot of which, if you ignore the four noisy dual-fan cooling packs and that I have to power the switch with one of the two redundant 650-watt power supplies, you get a switch having six times the ports and six 40 gigabit QSFP+ uplinks (like I'll ever get to NEED them), full management, and enough switching fabric bandwidth that you'll NEVER even come close to saturating (approximately 1.4 terabits per second), as well as a second switch just like it, I'd say that was money well spent.

Well, that and getting several ten-gigabit ethernet cards I had to do some finagling to get the drivers of three of them (I actually got four Intel AT2-based eight-lane PCIe Gen2 cards off someone via Craigslist for $15 each) to install under Windows 10 and 11, requiring me to not only disable driver signature enforcement and to turn that off on another machine, I had to disable secure boot, but I had to tell the driver's .inf file that I wanted to install it under something a bit more recent than Windows 7 or even Vista!

Only my gaming machine got a new ten-gigabit card with appropriately-recent (as well as actually properly-signed for Windows 8/8.1/10/11) drivers (at least I might be able to play Valorant once I decide to lock down the bootstrap process on this machine). And it got an extra ten-gig port to boot! The card is an Intel Converged dual-port four-lane PCIe Gen3 card, setting me back about 150 bucks and tax.

All the cards are set to 9014-byte frames and the config on the Nexus on those ports are as follows (per a post on the Cisco forum):

tengbeswitch01# show run int ethernet1/1

!Command: show running-config interface Ethernet1/1
!Time: Wed Feb  5 00:00:20 2025

version 7.0(3)I3(1)

interface Ethernet1/1
  description Studio PC 10GbE interface
  mtu 9216

Anyway, did a stream a couple of nights ago. Except for one machine crash (which was not stream-ending) and a game crash, it went pretty much perfectly! I used density-based compression on all links as it uses the least amount of CPU at the expense of more bandwidth used. But that's okay! That's why I got the gear! I have never been happier!

--Katt. =^.^=