Beam

Beam v1.1.0

YorVeX

Member
Since the release of the latest version of OBS 30.0.0, xObsBeam consumes a lot of network bandwidth.
Hm, I don't really see where the link would be, the v30 release didn't change anything that should affect this. I do a lot of tests myself between versions (regularly testing Beam with OBS 30 since the first beta of it) and didn't observe any changes in bandwidth consumption.

Maybe the update somehow has changed your compression settings? That influences the necessary network bandwidth a lot, and of course video settings in OBS like resolution and frame rate. You can always drop a link to a log here (Help -> Log Files -> Upload Current Log File), then I can see your settings and compare that to expected bandwidth needs.
 

Woodsy

New Member
Win11 OBS v30.0.0 - Beam v0.9.8

Audio track > add beam filter > name prompt > click ok > OBS instant crash
Untick 'Use Device Timestamps' on 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)' - > add beam filter > name prompt > click ok > Mouse lags for several seconds and PC is unresponsive > OBS crash

Will only crash on the one audio track 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)'
Two other outputs and a Mic input work fine

Logs with ticked 'Use Device Timestamps' on 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)' :
08:50:55.110: [xObsBeam] filter_get_defaults_audio called
08:50:55.110: [xObsBeam] FilterAudio settings_get_defaults called
08:50:55.110: [xObsBeam] filter_create_audio called
08:50:55.110: [xObsBeam] FilterAudio constructor
08:50:55.110: private source 'Beam Sender Filter (Audio only)' (Beam Sender Filter Audio) created
08:50:55.110: User added filter 'Beam Sender Filter (Audio only)' (Beam Sender Filter Audio) to source '1 Desktop'
08:50:55.110: [xObsBeam] filter_get_defaults_audio called
08:50:55.110: [xObsBeam] FilterAudio settings_get_defaults called
08:50:55.112: - filter 'Beam Sender Filter (Audio only)' (Beam Sender Filter Audio) added to source '1 Desktop'
08:50:55.112: [xObsBeam] filter_save called
08:50:55.112: [xObsBeam] <1> settings_save called
08:50:55.112: [xObsBeam] filter_get_properties called
08:50:55.112: [xObsBeam] <1> Found network interface: vEthernet (Default Switch): <Edited out> / <Edited out> (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: vEthernet (Bridge): <Edited out> / <Edited out> (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: vEthernet (Default Switch (vEthernet (Bridge))): <Edited out> / <Edited out> (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: VMware Network Adapter VMnet1: 192.168.40.1 / 255.255.255.0 (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: VMware Network Adapter VMnet8: 192.168.235.1 / 255.255.255.0 (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: Loopback Pseudo-Interface 1: 127.0.0.1 / 255.0.0.0 (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: vEthernet (Default Switch (VMware Network Adapter VMnet1)): <Edited out> / <Edited out> (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: vEthernet (Default Switch (VMware Network Adapter VMnet8)): <Edited out> / <Edited out> (Local: True)
08:50:55.112: [xObsBeam] <1> Found network interface: vEthernet (Default Switch (Wi-Fi)): <Edited out> / <Edited out> (Local: True)
08:50:55.112: [xObsBeam] <1> Automatic listen port enabled: True
08:50:55.112: [xObsBeam] <1> Didn't find configured network interface "", falling back to loopback interface.
08:50:55.112: [xObsBeam] <1> Network interface set to:
08:50:55.112: [xObsBeam] <1> Didn't find configured network interface "", falling back to loopback interface.
08:50:55.112: [xObsBeam] <1> Network interface set to:
08:50:55.112: [xObsBeam] <1> Connection type changed to: socket
08:50:55.112: [xObsBeam] <1> Didn't find configured network interface "", falling back to loopback interface.
08:50:55.112: [xObsBeam] <1> Network interface set to:
08:50:55.112: [xObsBeam] <1> Connection type changed to: socket
08:50:55.113: [xObsBeam] <1> Network interface set to: Any: 0.0.0.0
08:50:55.113: [xObsBeam] <1> sender restart requested from NetworkInterfaceChangedEventHandler.
08:50:55.115: [xObsBeam] AudioOnly output feed initialized, reserving 23040 bytes of memory per packet.
08:50:55.115: [xObsBeam] <1/1 Desktop> FilterAudio StartSenderIfPossible(): IsEnabled=True, IsActive=False, CanStart=True
08:50:55.116: [xObsBeam] Peer Discovery server: Starting for FilterAudio "Beam Sender Filter (Audio only)" on 0.0.0.0:14424...
08:50:55.116: [xObsBeam] Peer Discovery server: Started and entered receive loop for FilterAudio "Beam Sender Filter (Audio only)" on 0.0.0.0:14424.
08:50:55.116: [xObsBeam] Listening on 0.0.0.0:14424.
08:50:55.116: [xObsBeam] Waiting for new connections on 0.0.0.0:14424.
08:50:55.116: [xObsBeam] Unhandled NullReferenceException: Object reference not set to an instance of an object.
08:50:55.116: at System.Buffer.Memmove(Byte&, Byte&, UIntPtr) + 0x5b
08:50:55.116: at xObsBeam.BeamSender.SendAudio(UInt64, UInt32, obs_audio_data._data_e__FixedBuffer) + 0xad
08:50:55.116: at xObsBeam.Filter.ProcessAudio(Void*, obs_audio_data*) + 0x3b2
08:50:55.116: at xObsBeam.Filter.filter_audio(Void*, obs_audio_data*) + 0x67
Logs with UNticked 'Use Device Timestamps' on 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)' :
08:57:51.207: [xObsBeam] filter_get_defaults_audio called
08:57:51.207: User added filter 'Beam Sender Filter (Audio only)' (Beam Sender Filter Audio) to source '1 Desktop'
08:57:51.207: [xObsBeam] filter_get_defaults_audio called
08:57:51.209: [xObsBeam] filter_get_properties called
08:57:51.209: [xObsBeam] <4> Didn't find configured network interface "", falling back to loopback interface.
08:57:51.209: [xObsBeam] <4> Network interface set to:
08:57:51.209: [xObsBeam] <4> Didn't find configured network interface "", falling back to loopback interface.
08:57:51.209: [xObsBeam] <4> Network interface set to:
08:57:51.209: [xObsBeam] <4> Didn't find configured network interface "", falling back to loopback interface.
08:57:51.209: [xObsBeam] <4> Network interface set to:
08:57:51.210: [xObsBeam] <4> Network interface set to: Any: 0.0.0.0
08:57:51.215: [xObsBeam] Listening on 0.0.0.0:15712.
08:57:51.216: [xObsBeam] Unhandled NullReferenceException: Object reference not set to an instance of an object.
08:57:51.216: at System.Buffer.Memmove(Byte&, Byte&, UIntPtr) + 0x5b
08:57:51.216: at xObsBeam.BeamSender.SendAudio(UInt64, UInt32, obs_audio_data._data_e__FixedBuffer) + 0xad
08:57:51.216: at xObsBeam.Filter.ProcessAudio(Void*, obs_audio_data*) + 0x3b2
08:57:51.216: at xObsBeam.Filter.filter_audio(Void*, obs_audio_data*) + 0x67

Please assist.
Thanks.
 

YorVeX

Member
Win11 OBS v30.0.0 - Beam v0.9.8

Audio track > add beam filter > name prompt > click ok > OBS instant crash
Untick 'Use Device Timestamps' on 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)' - > add beam filter > name prompt > click ok > Mouse lags for several seconds and PC is unresponsive > OBS crash

Will only crash on the one audio track 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)'
Two other outputs and a Mic input work fine

Logs with ticked 'Use Device Timestamps' on 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)' :

Logs with UNticked 'Use Device Timestamps' on 'VoiceMeeter Input (BV-Audio VoiceMeeter VAIO)' :


Please assist.
Thanks.
I wasn't really fond of installing VoiceMeeter in my Dev VM, but since I couldn't repro this with any other sound devices I figured I had to try. But even then I don't get the crash, I can add the filter just fine:
1701922634741.png

Maybe I did something differently than you? Did you add an Audio Output Capture for that virtual VoiceMeeter device and then a Beam filter to that? Maybe you could give a full repro scenario beginning with an empty OBS installation (use portable mode for that) and also a full log.
 

Woodsy

New Member
So I've managed to figure it out.

What i was doing was sending one video stream and 4 audio.
I send ALL audio separately and mute the video stream.
That first audio (that was making it crash) was also the first audio stream which was auto-magically attached and sent by the first video stream.

Much confusion because even when "Enable Beam Sender Output" is unticked on video it blocks that first audio track.

Now after reconfiguration I send one video and 3 audio. using the embedded audio in the video stream instead of sending it separately.
 

YorVeX

Member
So I've managed to figure it out.

What i was doing was sending one video stream and 4 audio.
I send ALL audio separately and mute the video stream.
That first audio (that was making it crash) was also the first audio stream which was auto-magically attached and sent by the first video stream.

Much confusion because even when "Enable Beam Sender Output" is unticked on video it blocks that first audio track.

Now after reconfiguration I send one video and 3 audio. using the embedded audio in the video stream instead of sending it separately.
I'd rather never have Beam crash, even in situations where capturing is not possible it should at least not crash but log an error message. But I tried all sorts of capturing situations, including capturing audio that was already part of a combined audio and video feed, and that didn't cause any crashes either, so as long as I can't reproduce this I'm afraid there's not much I can do. Glad you got it solved for yourself though.
 

r3dd3vil

Member
The short answer is, not really, I'm afraid. If you want the long one, grab a coffee and read on.

Currently Beam provides async filters, which can also only be applied to async sources. They fit Beam's use case perfectly, because for them OBS provides raw video data from the system memory, and transporting this raw data from one OBS instance to another is exactly Beam's main job.

Now, sync filters are a different story. The idea for them is that the data remains in GPU memory and is altered by GPU shaders, no copying between GPU and system memory involved. This means that a sync filter simply doesn't get any raw data to work with from OBS.

The only plugins that I know of to get around this is the OBS NDI plugin and the Source Clone plugin. I checked its sources and NDI uses some weird hack of attaching its own custom video output to the source and fiddling with lots of funny texture functions that I don't understand anything about, Source Clone doesn't but uses even more texture fiddling functions, so that they finally get this data from system memory.

My motivation to copy this solution is somewhere between super low and nonexistent, for various reasons:
  • I don't understand this solution, which will make implementation very hard and debugging even harder, if anything with it breaks (during implementation or later because of OBS updates)
  • Since my plugins are written in .NET I depend on a translation library which I am quite sure right now doesn't provide all the functions I would need for this, so I'd need to file a feature request there first and it might or might not be implemented at some point, before that I can't even start working on it
  • Async filters are pretty close to how outputs work in that I get the same raw data, but still some things were different in bad, confusing and surprising ways, 14 changed files with 3,000 lines of code changed speak for themselves, to the point that I already regret implementing them, with by original sleek, beautiful and clean code now bloated forever (to be honest, I am quite sure that also performance for outputs is a bit worse in the version with filters because of the compromises I had to make) - I can only remotely imagine how this will explode once more if I implement such an ugly beast as the NDI solution
  • The egoistic part: I also don't need sync filters for myself
  • Filters suck anyway, and big time, I implemented them because I know many people want them, but seriously, they cause all sorts of issues you will not have with outputs
    • Lags can cause A/V desyncs, the same lags don't cause this this with outputs - you can see this with NDI, Teleport and Beam, actually even with other internal filters like Render Delay - that's because it's an issue with OBS itself and there's nothing filters can do about this, they all just suffer from this issue
    • Fixed frame buffer for audio only feeds will do nothing to sync it in a global context, because OBS will mess up the timing already at the source (sender) before Beam even gets the data - I didn't expect this and was very disappointed when I found out, but OBS might give you an A/V feed and the separate audio feed already 200 ms behind it, now you can set a fixed buffer of 1000 ms for both feeds in Beam all you want, you will end up with one feed at 1000 ms and one at 1200 ms, the worst part being that one lag later the difference might be 300 ms, good luck syncing that
    • Right now when you use them with enabled frame buffer you will sometimes get situations where the frame buffer underruns, never refills correctly and constantly complains about it with log warnings (also then the desired delay is then not reached) - in my first debugging sessions it looked like this is caused by wrong timestamps sent by OBS, which probably comes from the aforementioned issue
For my own use case I need to have 2 feeds sent to the streaming PC separately, because there is effects I want to apply separately there: the game capture + desktop audio feed, and a cam + mic feed. I would want to use one OBS instance for this and send the cam + mic feed separately using a filter on a source with this. Since video capture is async this would even work with the current filters, but since I know (and have proven in plenty of tests) how bad filters are working, I won't do this, I solve this by using outputs from 2 separate OBS instances that are running on the gaming PC, and you should, too (OBS portable mode makes this possible).

If after all of this you still think you want to use a filter, you can use the Source Clone plugin to clone either the scene or the game capture source and then apply the Beam filter to this cloned source. Needless to say, when a filter solution by itself is bad, such a workaround could be even worse.

Of course it's open source, feel free to implement it yourself or find someone who does it for you, but very likely this someone won't be me, sorry :-(
"If after all of this you still think you want to use a filter, you can use the Source Clone plugin to clone either the scene or the game capture source and then apply the Beam filter to this cloned source. Needless to say, when a filter solution by itself is bad, such a workaround could be even worse." Hello Yotvex, unfortunately i really need to grab that source from pc 2, works on it on pc 1 and send it out from the same pc 2. I've tried with ndi but sometimes is lagging, with the source clone filter there is only audio option and no video. Do you know why?
 

YorVeX

Member
"If after all of this you still think you want to use a filter, you can use the Source Clone plugin to clone either the scene or the game capture source and then apply the Beam filter to this cloned source. Needless to say, when a filter solution by itself is bad, such a workaround could be even worse." Hello Yotvex, unfortunately i really need to grab that source from pc 2, works on it on pc 1 and send it out from the same pc 2. I've tried with ndi but sometimes is lagging, with the source clone filter there is only audio option and no video. Do you know why?
My bad, I thought the Source Clone feature would be able to represent a sync source as an async source, which would include video, but it doesn't. I now removed my suggestion to use Source Clone from the post quoted above so people reading it are not mislead. This would only work if Exeldro would implement this feature in addition, I asked about it in the discussion where you also participated.
 
Last edited:
YorVex, I just set this up to use two instances of OBS...one for casting and one for capturing. Then I sent the video over the Named Pipes and this works for using one PC. This is extremely amazing!! 10/10 Sorry that I don't have any current issues with the plugin as of yet, but I only need it for video only and its working very well.
 

YorVeX

Member
YorVex, I just set this up to use two instances of OBS...one for casting and one for capturing. Then I sent the video over the Named Pipes and this works for using one PC. This is extremely amazing!! 10/10 Sorry that I don't have any current issues with the plugin as of yet, but I only need it for video only and its working very well.
Glad you like it, I'd appreciate if you could also post this text as a review ❤️
 

YorVeX

Member
Finally released the first stable release after a more than 8 months long development and beta phase!

The next 1.1.0 release is also available as a beta version here and mainly focuses on introducing a new relaying feature. Every relay is represented as a source, it can be added just like the receiver source:
1704233352957.png

It is a combination of receiver and sender, so it can receive any feed you select and then be a sender for it again. You would configure the receiver part in the upper area and the sender part in the lower area of the source properties:

1704234256369.png


It is represented as a source in OBS just to have a GUI to configure each relay separately, it doesn't actually output anything. It is also not tied to the OBS settings it is running in, e.g. it can run in an OBS that is set to 30 FPS and relay a 60 FPS feed. The feed is relayed as is, meaning a compressed feed will keep its compression, a raw feed will stay uncompressed.

The main use case for this is if you want to send a feed from one PC to another and on the receiver PC use the feed from two different OBS instances. Receiving the original feed from the sender PC twice could be expensive from bandwidth perspective if using a weak compression or none at all, so instead you would have a relay on the receiver PC receive it through network and relay it on a named pipe as shown in the example screenshot above, then the two OBS instances would consume the relayed feed.

I already successfully tested this for a few hours, using 2 separate relays to receive a 1440p120 feed and another 1080p60 feed from the network (totaling 7.5 Gbps) on a 10G interface (from an OBS that is set to 30 FPS), then consuming each feed from two different OBS instances (that are set to 120 FPS) from those 2 relays, so it should be ready even for quite extreme scenarios.

Since a relay source is not outputting anything, the hide/show action (eye icon) does nothing, starting and stopping a relay is done by going into the properties and toggling the "[X] Enable Beam Sender Relay" checkbox. As a shortcut, you can also use the media controls on a relay source, this area also shows a timer how long the relay has been active:
1704235020220.png

(In OBS "View -> Source Toolbar" needs to be checked for this to be visible)
 
Last edited:

Acey05

Member
Heya, sorry to bother once again, but I was going through the thread and noticed that pretty much you're one of the few people that noticed an OBS issue, the one where if OBS hangs/stutters/delays input-output, it completely desyncs audio and video on the Streaming PC.

You mentioned about the Buffer system that you implemented, so I was curious if it was a fix specifically for that issue (since I too would like to avoid relying on Voicemeter/DAW setup for my entire PC).
 

YorVeX

Member
Heya, sorry to bother once again, but I was going through the thread and noticed that pretty much you're one of the few people that noticed an OBS issue, the one where if OBS hangs/stutters/delays input-output, it completely desyncs audio and video on the Streaming PC.

You mentioned about the Buffer system that you implemented, so I was curious if it was a fix specifically for that issue (since I too would like to avoid relying on Voicemeter/DAW setup for my entire PC).
Whether it helps you depends on where you're having the desync. The fixed buffering delay in regards to syncing only helps in situations where you have a Beam A/V feed and want to sync that (as a whole) to something outside of this feed (another separate Beam feed, event, effect, webcam RTMP feed, audio signal...) and need to be able to rely on a constant delay between the capture on the Beam sender side and the output from the Beam receiver, e.g. 500 ms so that you can also sync everything else to a delay of 500 ms and can be sure it won't suddenly be 700 ms or 300 ms (which can happen without fixed buffering).

It wouldn't help with A/V desyncs within the Beam feed and actually during a lot of tests I haven't seen those occur at all with Beam and OBS 29 or newer.
 

microsleep

New Member
Hello everyone :)

First of all I would like to say that I am very grateful for this plugin. I or rather we used the NDI plugin for our setup for about 10 months. It suddenly stopped working on one of the PCs, which is why I came across xObsBeam while looking for an alternative.

The possible settings and documentation alone convinced me, as NDI is very basic in this respect. In addition to the quality/compression options, the selection of a network interface is also very convenient.

In principle, the plugin works excellently, without the fiddling we had with NDI. The quality is just as good with similar bandwidth usage (possibly even less usage) and it seems to me that the CPU has less load.

Unfortunately, we do have a small problem that I haven't found a solution to here or on Google.

-----

Setup:

My wife and I stream our game to a streaming PC, which sends the stream to Twitch. (PC1 + PC2 --> Router --> StreamingPC --> Router --> Twitch)

OBS 30.0.2 with xObsBeam 1.0.0 is running on all 3 PCs.

Since only one channel appeared for selection on the StreamingPC, I manually configured the interface and port on the gaming PCs during configuration. I also configured the sources in the StreamingPC manually with IP & port.

The problem has existed for some time, but I did the update today and tested everything again.

We have 1 gigabit bandwidth available and with JPEG (compression 10, quality 90) each PC uses approx. 200 Mbit, i.e. a total of 400-500 Mbit.

-----

Unfortunately, there are occasional disconnects to Twitch. According to the Task Manager, there seems to be a "peak" in bandwidth usage, which may be overloading the network but I don't know, just a thought.

The following messages appear in the log files:

12:25:27.504: [xObsBeam] Connected to [::ffff:192.168.1.9]:13630.
12:25:27.525: [xObsBeam] Frame buffering disabled.
12:25:30.569: [xObsBeam] Warning: High receive buffer size of 651963 bytes (> 577275 bytes).

It seems that the higher the bandwidth usage, the more frequently the messages appear.

When testing with 1 PC, I found out that the message does not appear with low quality, e.g. 50-60. In this case, approx. 80-120 Mbit is used.

If the usage increases to about 150 (quality 70), these warnings start. At approx. 200 (quality 80-90) there are very many, perhaps every 10-30s.


----

- The other options such as Density & QOY require too much bandwidth anyway (800 Mbit).
- When testing with 1st PC (without streaming to Twitch) there were no warnings with QOY, but now OBS crashes.
- When I select Density there is the following warning: [xObsBeam] Video data: Frame 754686938528422 skipped by sender.

----

In the meantime I have probably tried everything I could think of. I'm also not sure if this is the cause at all? Unfortunately I'm not a technician, I've just tested everything and hope that someone here can help with the information :)

Any ideas what I could try?

Could it be Windows/Firewall (although we never had such problems with NDI with a total usage of about 400-500 Mbit)?

Could it possibly be an indication that the streaming PC only automatically "recognizes" one channel at a time and not both? But it still works with manual configuration?

Many thx for this great plugin and your possible answer!

Best regards
microsleep

---
P.S.:

Incidentally, this is the output of the log on the gaming PC. It seems that the messages appear at about the same time as the buffer warnings on the StreamingPC. But I can't say for sure.

13:00:50.503: [xObsBeam] Starting output...
13:00:50.504: [xObsBeam] Output started.
13:00:50.533: [xObsBeam] Video output feed initialized with Jpeg compression. Sync to render thread: True. Theoretical uncompressed net bandwidth demand would be 1416 Mpbs.
13:00:50.558: [xObsBeam] Peer Discovery server: Starting for Output "stoic" on 127.0.0.1:13630...
13:00:50.558: [xObsBeam] Peer Discovery server: Starting for Output "stoic" on 192.168.1.9:13630...
13:00:50.558: [xObsBeam] Peer Discovery server: Starting for Output "stoic" on 192.168.56.1:13630...
13:00:50.558: [xObsBeam] Peer Discovery server: Starting for Output "stoic" on 169.254.167.203:13630...
13:00:50.558: [xObsBeam] Peer Discovery server: Starting for Output "stoic" on 192.168.219.1:13630...
13:00:50.558: [xObsBeam] Peer Discovery server: Starting for Output "stoic" on 192.168.5.1:13630...
13:00:50.558: [xObsBeam] Listening on 192.168.1.9:13630.
13:00:51.515: [xObsBeam] <192.168.1.8:59603> New client connected.
13:02:41.174: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:02:41.174: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:02:41.174: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:03:29.732: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:03:29.732: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:03:29.732: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:04:54.476: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:04:54.476: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
13:04:54.476: [xObsBeam] Output Network interface set to: Ethernet: 192.168.1.9 / 255.255.255.0
 

microsleep

New Member
Just had again a look at the logs and perhaps found some more information. The last lines were:

20:55:57.761: [xObsBeam] Warning: High receive buffer size of 1222716 bytes (> 1010481 bytes).
20:55:57.771: [xObsBeam] Warning: High receive buffer size of 1034416 bytes (> 1013523 bytes).
20:55:57.792: [xObsBeam] Warning: High receive buffer size of 1071998 bytes (> 1019598 bytes).
20:55:57.807: [xObsBeam] Warning: High receive buffer size of 1040016 bytes (> 1019961 bytes).
20:55:57.818: [xObsBeam] Warning: High receive buffer size of 1042333 bytes (> 1024890 bytes).
20:55:57.841: [xObsBeam] Warning: High receive buffer size of 1152622 bytes (> 1025031 bytes).
20:55:57.855: [xObsBeam] Warning: High receive buffer size of 1306590 bytes (> 1026912 bytes).
20:55:57.875: [xObsBeam] Warning: High receive buffer size of 1048106 bytes (> 1031226 bytes).
20:55:57.891: [xObsBeam] Warning: High receive buffer size of 1056245 bytes (> 1031415 bytes).
20:55:57.941: [xObsBeam] Warning: High receive buffer size of 1048327 bytes (> 1031973 bytes).
20:55:57.950: [xObsBeam] Warning: High receive buffer size of 1047959 bytes (> 1031973 bytes).
20:55:57.979: [xObsBeam] Warning: High receive buffer size of 1040288 bytes (> 1030869 bytes).
20:55:59.669: [xObsBeam] Warning: High receive buffer size of 1081281 bytes (> 1063857 bytes).
20:55:59.682: [xObsBeam] Warning: High receive buffer size of 1081152 bytes (> 1064910 bytes).
20:56:00.686: [xObsBeam] Warning: High receive buffer size of 1081722 bytes (> 1064961 bytes).
20:56:00.697: [xObsBeam] Warning: High receive buffer size of 1080496 bytes (> 1064964 bytes).
20:56:00.710: [xObsBeam] Warning: High receive buffer size of 1078104 bytes (> 1065075 bytes).
20:56:00.730: [xObsBeam] Warning: High receive buffer size of 1066706 bytes (> 1061283 bytes).
20:56:16.898: WriteN, RTMP send error 10060 (2693 bytes)
20:56:16.899: WriteN, RTMP send error 10038 (80 bytes)
20:56:16.899: WriteN, RTMP send error 10038 (42 bytes)
20:56:16.899: [rtmp stream: 'adv_stream'] Disconnected from rtmp://fra02.contribute.live-video.net/app
20:56:16.899: Output 'adv_stream': Reconnecting in 2.00 seconds..
20:56:16.899: [rtmp stream: 'adv_stream'] Freeing 1597 remaining packets
20:56:17.453: WriteN, RTMP send error 10060 (4097 bytes)
20:56:18.903: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://fra02.contribute.live-video.net/app...
20:56:20.470: WriteN, RTMP send error 10038 (91 bytes)
20:56:20.470: WriteN, RTMP send error 10038 (42 bytes)
20:56:20.470: [rtmp stream: 'multi-output'] Disconnected from rtmps://fa723fc1b171.global-contribute.live-video.net
20:56:20.470: Output 'multi-output': Reconnecting in 2.00 seconds..
20:56:20.470: [rtmp stream: 'multi-output'] Freeing 1144 remaining packets
20:56:20.564: [xObsBeam] IOException while trying to process or retrieve data: Unable to read data from the transport connection: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat..
20:56:20.564: [xObsBeam] IOException while trying to process or retrieve data: Unable to read data from the transport connection: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat..
20:56:20.564: [xObsBeam] Disconnected from [::ffff:192.168.1.10]:13629.
20:56:20.564: [xObsBeam] Disconnected from [::ffff:192.168.1.9]:13629.


I interprete these last lines that the whole LAN gets down:
20:56:22.476: [rtmp stream: 'multi-output'] Connecting to RTMP URL rtmps://fa723fc1b171.global-contribute.live-video.net...
20:56:22.478: No application or playpath in URL!
20:56:23.988: [tuna] Couldn't open song output file \\www.netcay.ch@SSL\DavWWWRoot\owncloud\remote.php\dav\files\stoicails\ownCloud\Psy Lounge\np14.txt
 

YorVeX

Member
while JPEG compression does have some worst case scenarios, peaks that would suddenly go from 400-500 mbit/s to overloading a 1000 mbit/s network are very unlikely, I think it's more likely that there is an issue in the network and then unsent data packets pile up for a bit in the buffer (which is what the high buffer messages indicate) and are then sent in a burst when the network recovered. would be interesting to see a network usage curve from the time when this happens: does it first go down and then up (as described before, first congestion and then recovering in a burst), or first up and then down (this would indeed mean there's a peak which then causes follow-up issues)?

the fact that also NDI worked fine and then suddenly stopped working, and now Beam is also having issues, also points toward network problems, even when the error scenario does look different. although...does it? you said one of the PCs stopped working with NDI, and NDI doesn't have a manual connection mode, so when UDP Multicast discovery fails (this is what a source uses to find an active sender) NDI would indeed stop working, as there is no other way to fetch this feed. and with Beam you describe the same, discovery fails (Beam uses the same UDP Multicast discovery technology that NDI uses), just that with Beam you could make it work anyway, because it has a manual connection mode as a fallback. was that affecting the same PC in both cases?

also, yes, Beam with JPEG indeed would use significantly less bandwidth than NDI (maybe even half of it), if it was good enough for NDIs higher bandwidth needs before and now even fails for the smaller JPEG bandwidth needs, something's definitely broken there.

is any of the connections over Wifi? the reason why it's always recommended against using it for this kind of transmission is exactly that it can work for a year, then a neighbor sets up their new microwave at the other side of the wall where your router is, or also a new Wifi router that interfers with yours, and your network is now forever unstable. or for a week. or for each 2nd day. so using Wifi for this would be a huge gamble and if that's the case it would be pointless to continue debugging at this point, the only sensible course of action would be to go wired.

if it's already wired ethernet, then this could be a multitude of things. I would look at software first. software firewalls could cause both the UDP Multicast discovery failing and other instabilities, temporarily disable it on every PC involved and see whether discovery works again, if it does, you got your offender. ISPs in germany usually give out routers to their customers (instead of just plain modems), in that case extra software firewalls aren't necessary anyway. if one of the systems is a laptop that you sometimes use in networks outside of your home, you can configure the firewall to be disabled in private networks (your home network) and be enabled in others so that it still protects you there.

another piece of software that is known to cause a lot of issues like that is so called network optimizer software. many mainboard vendors like MSI or ASUS ("GameFirst" utility) provide them along with their mainboards and market them as being great for gaming, improving latency and so on, but mostly they cause a lot more trouble than their worth, and especially streamers should never use them. also some NIC vendors (Killer) provide such tools and also independent tools exist like cFosSpeed. whatever it is, if you have it, get rid of it. not only disable, completely uninstall, then reboot and hope it didn't also permanently mess up network settings that are not reverted upon uninstallation.

even more sneaky are certain security software suites, some mess with network traffic although they don't even look like they'd have anything to do with network and just call themselves something with "security". at least temporarily disable them, or better get rid of them altogether (Windows Defender is fine though, you can let that live).

looking at the surprisingly long list of network interfaces that you seem to have, do you have any kind of virtualization software installed, e.g. VirtualBox? this can sometimes cause issues with NDI, because NDI tries to use all network interfaces it finds, including virtual ones. for Beam make sure you always explicitly select the physical network interface you want to use.

if you ruled out software, then hardware is the next thing to look at. try to change network cables, if you don't have a spare one (usually a few accumulate over time, because every new router comes with one), swap those of 2 computers and see if the problem moves or changes.

if you're using your onboard LAN ports (like most people), think about getting a dedicated gigabit LAN card, even if it's only temporarily for ruling out that a specific LAN port is not the problem - you can get decent ones for as low as 10 €.

and while testing all of these things to narrow down where the problems are coming from, it would be good to have something for testing your network that was meant for that use case, I myself use the command line tool iperf for this, but with jperf there is also a graphical interface: https://wiki.ipfire.org/addons/iperf
 

microsleep

New Member
First of all, thank you very much for such a detailed and comprehensive answer! I am very grateful that you have invested so much time and effort to help. This is not a matter of course, thank you very much. <3

The points you raised help me a lot. Now I at least have several starting points to continue my search :)

It is interesting how you also address several points that we have already "gone through" but for different reasons :)

WLAN:
When we first started streaming this way we actually had wifi at first. But then we quickly switched to a wired connection because the problems occurred in exactly the same way as you describe. One day everything works fine, the next day it doesn't, and so on. That's why we've now switched everything to wired.

On-board port:
At some point, blue screens appeared on the streaming PC, which I was able to narrow down to a problem with the network interface using the Windows memory dumps. So I actually bought a dedicated network card and since then everything has been running smoothly for a few months.


---

To the actual problem:

I turned off the Windows firewall on all PCs this morning. When testing Beam with the two gaming PCs, I could now see and select the feed from my wife's PC. But not in the other direction (from me to her).

As you have correctly recognized, I have also installed VirtualBox on my PC, among other things, whereby I have actually also explicitly selected the correct network interface in Beam. Nevertheless, I have now deactivated all additional network interfaces. And indeed, my Beam feed now also appears on my wife's computer and can be selected.

So both points you mentioned are relevant (firewall + VM interfaces).


As a result, both feeds of the gaming PCs are now actually available for selection on the streaming PC and manual configuration is not necessary. Of course I was already thinking, "yes!", and hoping that all is well.


Unfortunately, there are still these buffer warnings in the log file of the streaming PC and after a few minutes of testing there was also the first disconnect. :/

If we only test the beam feed between the two gaming PCs, there are no such warnings. These obviously only affect the streaming PC, regardless of whether both feeds are received simultaneously or only one of the two.


----

Summarized:

- Disable firewalls and VirtualBox network interfaces --> Beam feed visible and selectable without manual configuration

- PC1 -> PC2 (no buffer warnings)
- PC2 -> PC1 (no buffer warning)

- PC1 + PC2 -> Streaming PC (buffer warnings)

----

I think it makes sense to look for further causes on the streaming PC?

Incidentally, it is running a freshly installed Windows10 (in contrast to Windows11 on the gaming PCs). I will also see if there are any tools (pre)installed or if I can find anything else installed or smth. Thanks for the tip that it's better to do without them. And thanks also for the tip about IPFire.

Thanks again for your comprehensive help and great effort. I will of course write again, especially if I find a solution.

Best regards
microsleep
 
Top