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)...