Beam v1.0.0

[Resident Stevil]

I seem to be getting a pretty significant audio delay between my gaming and streaming PC. Video doesn't appear to be having issues. Receive delay is 0ms, render is around 30-60ms usually. I can't find a way to either eliminate the delay or sync up the video to the audio.

 

[YorVeX]

I seem to be getting a pretty significant audio delay between my gaming and streaming PC. Video doesn't appear to be having issues. Receive delay is 0ms, render is around 30-60ms usually. I can't find a way to either eliminate the delay or sync up the video to the audio.

Are you using a feed that keeps both audio and video combined from start to end, meaning either the one configured from the Tools "Beam Sender Output" menu in OBS (the recommended way) or a "Beam Sender Filter (Audio/Video)" on a source?

Or are you somehow sending it separately? For the latter case you might need to take care of syncing manually by setting delays/offsets, e.g. using the "Sync Offset" field on the respective audio source in advanced audio properties of the receiver OBS or by adding a Render Delay or "Video Delay (Async)" filter to the receiver video source - depending on what is behind. If you say "audio delay" I'd assume that audio is behind video, so the Sync Offset would be the way to go.

If you're using one of the combined feeds and you are sure the A/V desync isn't already occurring on the sender OBS (can be verified by doing a quick recording there) I would need some OBS logs from sender and receiver to get an idea of what might be going on.

 

[Resident Stevil]

Are you using a feed that keeps both audio and video combined from start to end, meaning either the one configured from the Tools "Beam Sender Output" menu in OBS (the recommended way) or a "Beam Sender Filter (Audio/Video)" on a source?

Or are you somehow sending it separately? For the latter case you might need to take care of syncing manually by setting delays/offsets, e.g. using the "Sync Offset" field on the respective audio source in advanced audio properties of the receiver OBS or by adding a Render Delay or "Video Delay (Async)" filter to the receiver video source - depending on what is behind. If you say "audio delay" I'd assume that audio is behind video, so the Sync Offset would be the way to go.

If you're using one of the combined feeds and you are sure the A/V desync isn't already occurring on the sender OBS (can be verified by doing a quick recording there) I would need some OBS logs from sender and receiver to get an idea of what might be going on.

It's both audio and video combined, not the filter way or sending it separately.

 

[YorVeX]

It's both audio and video combined, not the filter way or sending it separately.

Are these from the same session? I am asking, because the timestamp are hours apart. Would be good to have logs from the same session from both sender and receiver and not different ones. If they are the same, then make sure the clocks are the same, as different timestamps could also cause syncing issues.

Before digging any deeper into it: I saw in the receiver logs that you changed audio monitoring settings for the Beam source there. Did you maybe use that to conclude that audio and video is not in sync? Because OBS has this bug that often when it would start audio buffering, this would be properly buffered and synced for A/V in its stream and recordings, but not for audio monitoring. Meaning your stream and recording would be fine, but after this your monitoring audio would be off by 469 ms:

13:51:19.523: adding 128 milliseconds of audio buffering, total audio buffering is now 469 milliseconds (source: Beam Receiver)

If that is the case, please try to create an actual recording and see whether you also got A/V desync there, don't ever use audio monitoring to check whether audio and video is in sync. Also, seeing that you're apparently capturing arcade/console games through a capture card, please make sure by testing with a recording that audio and video is actually synced on the sender side and it really only gets async when run through Beam, because this issue could also come from the capturing.

 

[Resident Stevil]

Are these from the same session? I am asking, because the timestamp are hours apart. Would be good to have logs from the same session from both sender and receiver and not different ones. If they are the same, then make sure the clocks are the same, as different timestamps could also cause syncing issues.

Before digging any deeper into it: I saw in the receiver logs that you changed audio monitoring settings for the Beam source there. Did you maybe use that to conclude that audio and video is not in sync? Because OBS has this bug that often when it would start audio buffering, this would be properly buffered and synced for A/V in its stream and recordings, but not for audio monitoring. Meaning your stream and recording would be fine, but after this your monitoring audio would be off by 469 ms:

If that is the case, please try to create an actual recording and see whether you also got A/V desync there, don't ever use audio monitoring to check whether audio and video is in sync. Also, seeing that you're apparently capturing arcade/console games through a capture card, please make sure by testing with a recording that audio and video is actually synced on the sender side and it really only gets async when run through Beam, because this issue could also come from the capturing.

I figured out what the problem was. My sender OBS still had some audio filters applied to the main audio that I had forgot to remove. Thank you for your assistance.

 

[YorVeX]

I figured out what the problem was. My sender OBS still had some audio filters applied to the main audio that I had forgot to remove. Thank you for your assistance.

You're welcome, glad you could figure it out!

 

[blanc]

Hi,

I keep seeing this warning a lot and occasionally error too. The network is not overloading it happened regardless of using Density strength 1 or 2. OBS running as Administrator.

I have PC1 (Using 2nd NIC) > StreamPC (Using2nd NIC) using P2P connection (2.5G)
I've done Iperf and it reached 2.5g without issue. Anything that I need to do to resolve this.

00:32:41.250: [xObsBeam] <192.168.1.20:53548> Warning: Send queue size 28 (50) at video frame 464303040900568.
00:32:41.263: [xObsBeam] <192.168.1.20:53548> Warning: Send queue size 28 (49) at video frame 464303057567234.
00:32:41.281: [xObsBeam] <192.168.1.20:53548> Warning: Send queue size 28 (49) at video frame 464303074233900.
00:32:41.539: [xObsBeam] <192.168.1.20:53548> Error: Send queue size 31 (55), skipping video frame 464303324233890.
00:32:41.559: [xObsBeam] <192.168.1.20:53548> Error: Send queue size 31 (55), skipping video frame 464303340900556.
00:32:41.570: [xObsBeam] <192.168.1.20:53548> Error: Send queue size 32 (57), skipping video frame 464303357567222.

 

[YorVeX]

Hi,

I keep seeing this warning a lot and occasionally error too. The network is not overloading it happened regardless of using Density strength 1 or 2. OBS running as Administrator.

I have PC1 (Using 2nd NIC) > StreamPC (Using2nd NIC) using P2P connection (2.5G)
I've done Iperf and it reached 2.5g without issue. Anything that I need to do to resolve this.

00:32:41.250: [xObsBeam] <192.168.1.20:53548> Warning: Send queue size 28 (50) at video frame 464303040900568.
00:32:41.263: [xObsBeam] <192.168.1.20:53548> Warning: Send queue size 28 (49) at video frame 464303057567234.
00:32:41.281: [xObsBeam] <192.168.1.20:53548> Warning: Send queue size 28 (49) at video frame 464303074233900.
00:32:41.539: [xObsBeam] <192.168.1.20:53548> Error: Send queue size 31 (55), skipping video frame 464303324233890.
00:32:41.559: [xObsBeam] <192.168.1.20:53548> Error: Send queue size 31 (55), skipping video frame 464303340900556.
00:32:41.570: [xObsBeam] <192.168.1.20:53548> Error: Send queue size 32 (57), skipping video frame 464303357567222.

What resolution and FPS are you sending through it, are you sure that even 2.5G is enough? Did you double check whether Beam is actually using the right (2.5G) NIC on both sides? You can select which network interface to use in Beam, but maybe you should also check from operating system level (i.e. in Task Manager if you're on Windows) to be sure, who knows, maybe there is a bug in Beam that makes it use the wrong NIC which hasn't been found yet. Also it would be good to check how close you're coming to the 2.5G limit in the Task Manager.

Another thing you can try is increasing any send and receive buffers that you find in the network driver settings of both sender and receiver PCs, also activating Jumbo Frames can help (needs to be done on both sides and set to the same size, e.g. 2048 or 4096, just experiment what works best). I had a situation myself where iperf was able to reach full throughput and Beam didn't, and only when optimizing these things Beam was also able to reach that bandwidth - I suspect this is because iperf uses a different packet size than Beam.

If it's not limited by network bandwidth, it could also be that the sender PC cannot keep up processing the frames fast enough. Try disabling the "Compress from OBS render thread" option on the sender OBS (from Tools -> Beam Output Settings) and see whether it makes a difference:

If that still doesn't help I'd need to see full logs from both sender and receiver OBS.

 

[blanc]

Hi There,

I was sending 1920x1080 at 60FPS, and yeah I can confirm both are connected using the nic specified. Jumbo frames activated on both with 9k on both side.

I'm not sure if the issue with the cat6 slim cable, but since I changed it to normal (not slim) cat6a and cat8 (just to test), I don't see these error anymore. I'll let beam run for few hours and see if these warning/error pops out again and I'll share the logs. :D

 

[blanc]

Hi,

Here's the recent log where the the warning and error still occurring. Haven't tried Compress from OBS render disabled yet.
Maybe the logs can shed some lights on this issue.

 

[YorVeX]

Hi,

Here's the recent log where the the warning and error still occurring. Haven't tried Compress from OBS render disabled yet.
Maybe the logs can shed some lights on this issue.

9K Jumbo Frames is also what I am using, I am on a 10G interface though (and push 2 Beam feeds totalling 8700 Mbps through it without issues, so I know Beam in general is capable of doing such high transfer rates) - you could also try to play with lower values.

Thanks for the logs. Seeing there that you're using I444, this means you lose HW (GPU) processing by OBS in some parts of its compositing chain if I'm not mistaken, moving more load to it's CPU bound thread, making it more important to try disabling the "Compress from OBS render thread" option to uncouple Beams processing from OBS frame processing so that it's not throttled by it.

With the raw bandwidth demand of 2840 Mbps exceeding the capability of your 2.5G interface (and net bandwidth is lower than those 2.5, as you've probably seen when testing with iperf) and with Density buying it's immense performance/speed with a not very high compression ratio, the bandwidth that Beam needs even after applying the compression might still be a bit too high for that interface. If you haven't already, try upping the "Density compression strength" in the Beam output settings. And as I said, it would be good to check with Task Manager or a similar tool the actual throughput that you reach.

If that doesn't help, I'm afraid you'd have to switch to NV12 color format - with this you have the smallest visible quality decrease (compared to lowering resolution or FPS) and biggest performance gain, since OBS can run a lot more parts of its processing on the GPU.
Unless you're streaming to Twitch, then I'd recommend lowering the resolution instead, 1080p is not a sensible choice given the bandwidth limitations they have, even though many streamers (even big ones) are using it.

 

[blanc]

9K Jumbo Frames is also what I am using, I am on a 10G interface though (and push 2 Beam feeds totalling 8700 Mbps through it without issues, so I know Beam in general is capable of doing such high transfer rates) - you could also try to play with lower values.

Thanks for the logs. Seeing there that you're using I444, this means you lose HW (GPU) processing by OBS in some parts of its compositing chain if I'm not mistaken, moving more load to it's CPU bound thread, making it more important to try disabling the "Compress from OBS render thread" option to uncouple Beams processing from OBS frame processing so that it's not throttled by it.

With the raw bandwidth demand of 2840 Mbps exceeding the capability of your 2.5G interface (and net bandwidth is lower than those 2.5, as you've probably seen when testing with iperf) and with Density buying it's immense performance/speed with a not very high compression ratio, the bandwidth that Beam needs even after applying the compression might still be a bit too high for that interface. If you haven't already, try upping the "Density compression strength" in the Beam output settings. And as I said, it would be good to check with Task Manager or a similar tool the actual throughput that you reach.

If that doesn't help, I'm afraid you'd have to switch to NV12 color format - with this you have the smallest visible quality decrease (compared to lowering resolution or FPS) and biggest performance gain, since OBS can run a lot more parts of its processing on the GPU.
Unless you're streaming to Twitch, then I'd recommend lowering the resolution instead, 1080p is not a sensible choice given the bandwidth limitations they have, even though many streamers (even big ones) are using it.

I've changed it to NV12 as per suggestion and disabled Compression from the OBS render thread. However, I'm still seeing those warnings (no errors). Both density settings, 1 and 2, give the same warning despite only using 800mbps-1000mbps (1) and 500-700mbps (2). I'm not sure anymore what else I need to do to make these go away. Or back to Jpeg compression which I don't really want.

Maybe it's driver/realtek performance thingy? Might as well try with 10G since I already have cat6a cables.

Anyway, what adverse effect will it have on the feed if I keep seeing the warning? I know error will make the feed /video skipping or it's safe to ignore.

 

[YorVeX]

I've changed it to NV12 as per suggestion and disabled Compression from the OBS render thread. However, I'm still seeing those warnings (no errors). Both density settings, 1 and 2, give the same warning despite only using 800mbps-1000mbps (1) and 500-700mbps (2). I'm not sure anymore what else I need to do to make these go away. Or back to Jpeg compression which I don't really want.

Anyway, what adverse effect will it have on the feed if I keep seeing the warning? I know error will make the feed /video skipping or it's safe to ignore.

When you'd get the error messages that say frames are being skipped (like you did before), then you'd lose quality, because those frames are then missing from the feed, which can lead to visual stuttering. But when you say with NV12 now you only get the warnings, you wouldn't lose anything and in general it would be fine, though I'd still say something must be wrong, it's definitely not normal and if I was you I'd keep on investigating.

I agree that using JPEG there would be silly, with 1080p60 NV12 you should be able to go even without any compression at all, with that needing only ~1400 Mpbs (though Density at strength 1 can still be a good idea, surprisingly depending on the setup it can lead to lower CPU usage than not compressing, I think that's because it has very little resource usage while saving the network stack some work with data processing, which is also done by the CPU).

But just for the sake of testing, could you still try to enable JPEG, start with level 10, and if you don't get warnings lower the level bit by bit until you get them? So that we figure out which bandwidth is still working?

Maybe it's driver/realtek performance thingy? Might as well try with 10G since I already have cat6a cables.

Could definitely be the case, did you try and increase send and receive buffers in the driver settings? Even on my 10G card the default settings for them were ridiculously low, I couldn't even reach 5G before I upped them myself.

Basically try and set a very high value (999999 or whatever), usually the dialog will then tell you what the maximum is and then you use that maximum. Example of such a setting:

Remember to do it for both receive and send (could also be called "transmit") buffers on both PCs. On my 10G cards (ASUS XG-C100C) it's set to 4096 for both now.

 

[Sir_Coleslaw]

9K Jumbo Frames is also what I am using, I am on a 10G interface though (and push 2 Beam feeds totalling 8700 Mbps through it without issues, so I know Beam in general is capable of doing such high transfer rates) - you could also try to play with lower values.

Thanks for the logs. Seeing there that you're using I444, this means you lose HW (GPU) processing by OBS in some parts of its compositing chain if I'm not mistaken, moving more load to it's CPU bound thread, making it more important to try disabling the "Compress from OBS render thread" option to uncouple Beams processing from OBS frame processing so that it's not throttled by it.

With the raw bandwidth demand of 2840 Mbps exceeding the capability of your 2.5G interface (and net bandwidth is lower than those 2.5, as you've probably seen when testing with iperf) and with Density buying it's immense performance/speed with a not very high compression ratio, the bandwidth that Beam needs even after applying the compression might still be a bit too high for that interface. If you haven't already, try upping the "Density compression strength" in the Beam output settings. And as I said, it would be good to check with Task Manager or a similar tool the actual throughput that you reach.

If that doesn't help, I'm afraid you'd have to switch to NV12 color format - with this you have the smallest visible quality decrease (compared to lowering resolution or FPS) and biggest performance gain, since OBS can run a lot more parts of its processing on the GPU.
Unless you're streaming to Twitch, then I'd recommend lowering the resolution instead, 1080p is not a sensible choice given the bandwidth limitations they have, even though many streamers (even big ones) are using it.

When you'd get the error messages that say frames are being skipped (like you did before), then you'd lose quality, because those frames are then missing from the feed, which can lead to visual stuttering. But when you say with NV12 now you only get the warnings, you wouldn't lose anything and in general it would be fine, though I'd still say something must be wrong, it's definitely not normal and if I was you I'd keep on investigating.

I agree that using JPEG there would be silly, with 1080p60 NV12 you should be able to go even without any compression at all, with that needing only ~1400 Mpbs (though Density at strength 1 can still be a good idea, surprisingly depending on the setup it can lead to lower CPU usage than not compressing, I think that's because it has very little resource usage while saving the network stack some work with data processing, which is also done by the CPU).

But just for the sake of testing, could you still try to enable JPEG, start with level 10, and if you don't get warnings lower the level bit by bit until you get them? So that we figure out which bandwidth is still working?

Could definitely be the case, did you try and increase send and receive buffers in the driver settings? Even on my 10G card the default settings for them were ridiculously low, I couldn't even reach 5G before I upped them myself.

Basically try and set a very high value (999999 or whatever), usually the dialog will then tell you what the maximum is and then you use that maximum. Example of such a setting:
View attachment 102599
Remember to do it for both receive and send (could also be called "transmit") buffers on both PCs. On my 10G cards (ASUS XG-C100C) it's set to 4096 for both now.

I have a question regarding these settings, are there any recommendations for Beam on 10G networks, for example? Because I also use a 10G direct connection via DAC-SFP+ cable between two ASUS XG-C100F cards and wonder whether there is still potential for optimization here.

 

[YorVeX]

I have a question regarding these settings, are there any recommendations for Beam on 10G networks, for example? Because I also use a 10G direct connection via DAC-SFP+ cable between two ASUS XG-C100F cards and wonder whether there is still potential for optimization here.

Didn't get any reports from other 10G users, so I can only tell from my own experience. Transmit Buffers was set to 2048 and Receiver Buffers even to 512 by default - with that I was unable to reach 10G speeds, regardless of the Jumbo Frame setting. After setting both to 4096 (the max for this card I believe) in addition to 9K Jumbo Frames it finally worked well. I also disabled Energy Efficient Ethernet since such power management stuff has too often caused issues for me with various devices and set Priority & VLAN to Packet Priority Enabled, since I am not using VLANs.

I also had some stability issues and had to update the firmware of that card, first I tried one from ASUS that improved the situation but didn't fully solve it, and then I flashed a newer Marvel Aquantia firmware update on it and ever since then it's been rock solid - but you should really only do this if you're having issues with it right now and not only for performance/optimization reasons.

 

[r3dd3vil]

hey vortex thanks for the great work and keep it up! We want new cool features :P

 

[YorVeX]

hey vortex thanks for the great work and keep it up! We want new cool features :P

TBH I am quite happy with where it is right now. Beta version has relaying, and I should probably promote it to become the next stable soon, but I doubt a lot more people than myself would need it.
Anything specific you're missing? Except sync sources, we had that topic already xD