Beam

Beam v1.1.0

Go to download
Overview Updates (26) Reviews (4) History Discussion
R

RaceDriverMIKU

Member
I updated to 0.8.4, and I tried 60000/1000 FPS, memory leaking still occurs when bandwidth is insufficient. and It also behaves obviously differently in receiver side. n/1 is keep disconnecting, so keep flashing. n*1000/1000 is not, beam source is keep showing, just lagging, not flashing.
I know n/1 FPS doesn't make any problem, so it doesn't matter to me, doesn't bother me, and I do not want to use FPS with drop frame. by the way, I tried it because there is a new version, and I found it is not fixed yet. anyway, in some edge cases, the problem can occur.
1693315952407.png

Also 59.94 FPS which is 60000/1001 has the same memory leaking issue. and I believe some of HDMI monitors, usually old ones still using 60000/1001(59.94) FPS. and If I remember correctly, some article, recording something projecting which FPS is 59.94 by OBS as 60FPS causes jittering in video due to frame time mismatch.
(59.94 is NTSC color framerate stardard with drop frame to prevent affecting monochrome broadcasting)
And the reason I use n*1000/1000 FPS is, When the OBS Studio was kind of new, maybe 10-ish version? using non-standard FPS as integer fps value causing weird frame time issue, but n*1000/1000 fixed the issue(it is all fine now, no matter whether setting n/1, or n*1000/1000). so to explicitly specify using non drop frame framerate.

log with -p --verbose, framerate 60000/1001(set common FPS value as 59.94)
 
Last edited:
YorVeX

YorVeX

Member
RaceDriverMIKU said:
I updated to 0.8.4, and I tried 60000/1000 FPS, memory leaking still occurs when bandwidth is insufficient. and It also behaves obviously differently in receiver side. n/1 is keep disconnecting, so keep flashing. n*1000/1000 is not, beam source is keep showing, just lagging, not flashing.
I know n/1 FPS doesn't make any problem, so it doesn't matter to me, doesn't bother me, and I do not want to use FPS with drop frame. by the way, I tried it because there is a new version, and I found it is not fixed yet. anyway, in some edge cases, the problem can occur.
View attachment 97189
Also 59.94 FPS which is 60000/1001 has the same memory leaking issue. and I believe some of HDMI monitors, usually old ones still using 60000/1001(59.94) FPS. and If I remember correctly, some article, recording something projecting which FPS is 59.94 by OBS as 60FPS causes jittering in video due to frame time mismatch.
(59.94 is NTSC color framerate stardard with drop frame to prevent affecting monochrome broadcasting)
And the reason I use n*1000/1000 FPS is, When the OBS Studio was kind of new, maybe 10-ish version? using non-standard FPS as integer fps value causing weird frame time issue, but n*1000/1000 fixed the issue(it is all fine now, no matter whether setting n/1, or n*1000/1000). so to explicitly specify using non drop frame framerate.

log with -p --verbose, framerate 60000/1001(set common FPS value as 59.94)
Click to expand...
Thanks for testing and reporting again so quick, you're a real race driver! :-)

Remember when I said "but apparently I still missed a few cases where Beam still only takes the numerator"? Guess what, just found one more case I missed and that you're apparently running into.

That's fixed now too, hopefully it's the last one (no guarantees though :-D). It will be in 0.8.5, which won't take as long as 0.8.4 to get released, I want this to be mostly a cleanup release with this fix and some compression options removed or conditionally hidden as described here.

By the way, 0.8.4 introduced QOY compression, which has a chance to make 1080p60 with NV12 usable on a 1G connection (it should push the feed to around 800-850 Mbps peaks), maybe you want to give this a try.
 
YorVeX

YorVeX

Member
Every system is different, but I can say for my system that using JPEG with the new compression level option allows for a setting that has both lower bandwidth and CPU usage than NDI, which is quite exciting!

However, there is one caveat: this option means that a certain percentage of frames is compressed and the rest is sent raw. That isn't an issue for lossless compression, but for JPEG being a lossy compression it might give weird results, e.g. for level 5 (meaning every other frame is compressed) you get a feed that constantly alternates between a compressed frame that has a small quality loss and one that doesn't. I don't think many people in the world have ever tried to composite a video feed of such a mixture, hence I have no clue what potential side effects this might have.

With JPEG being visually lossless I cannot see it in my test video feed, but encoders like x264 might be reacting in unexpected ways when encoding such a feed, it might produce a higher bitrate demand resulting either in lower quality in fixed bitrate environments (e.g. a live stream to Twitch) or increased file size when recording with quality based settings like CQP.

Also obviously don't set the JPEG quality level too low at the same time so that the difference between the frames is as small as possible, I wouldn't go under 90.

Happy experimenting :-)
 
YorVeX

YorVeX

Member
Next and last milestone in beta phase is adding filters to transmit content of only single sources, which I will be working on during the next days. As soon as this is finished it will be released as 0.9.0 version. The 0.9.X line will be the Release Candidate line, there will be no more features added and only bugs fixed. If a 0.9.X version has been stable for a reasonable amount of time, it will be re-released as 1.0 stable and the "beta" tag will be dropped.

For anyone currently thinking about using it in production: even as it is now in 0.8.5, it's already very stable, I don't see any crashes or any more memory leaks myself or got reports of them. Should be worth trying. Only when you're using unusual resolutions 0.8.5 still has an issue that is already fixed in the source code and will be in the next release.
 
KattPhloxworthy

KattPhloxworthy

Member
I noticed you'd removed the PNG compression. For one of my computers, I need alpha channel support. Do any of the remaining compression schemes support alpha channels?

--Katt. =^.^=
 
YorVeX

YorVeX

Member
KattPhloxworthy said:
I noticed you'd removed the PNG compression. For one of my computers, I need alpha channel support. Do any of the remaining compression schemes support alpha channels?

--Katt. =^.^=
Click to expand...
The YUV formats in OBS (including the default NV12) don't include an alpha channel, only BGRA does, and for BGRA there is still QOI and QOIR which do have alpha channel support. Especially QOIR has both better compression and lower CPU usage than PNG.
Another option would be Density, which will need more bandwidth but has lower CPU usage.
 
Last edited:
YorVeX

YorVeX

Member
BenAndo said:
I'm excited to see filter support for Audio/Video Filter sources.
Are there plans to also add filter support to individual scenes?
Click to expand...
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).

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 :-(
 
Last edited:
BenAndo

BenAndo

Member
Wow, thank you for the very insightful write-up. Very interesting indeed.
I do agree that stability should come before new features so I appreciate your desire to keep this plugin lean and stable above all else.
The source clone work around sounds like an alright compromise for those that really need it. I myself don't currently need it, but was curious nonetheless.

I have seen Multi-RTMP plugin added support for individual scene outputting over RTMP. OBS officially added WHIP/WebRTC outputting in version 30, so maybe someday it'll be possible to output individual scenes using WHIP/WebRTC or SRT. A bit off topic from this, but interesting developments regardless. I'm guessing Soure Record plugin also had to do some fancy texture coding to do its implementation of grabbing a source as a video feed.
 
YorVeX

YorVeX

Member
BenAndo said:
Wow, thank you for the very insightful write-up. Very interesting indeed.
I do agree that stability should come before new features so I appreciate your desire to keep this plugin lean and stable above all else.
The source clone work around sounds like an alright compromise for those that really need it. I myself don't currently need it, but was curious nonetheless.

I have seen Multi-RTMP plugin added support for individual scene outputting over RTMP. OBS officially added WHIP/WebRTC outputting in version 30, so maybe someday it'll be possible to output individual scenes using WHIP/WebRTC or SRT. A bit off topic from this, but interesting developments regardless. I'm guessing Soure Record plugin also had to do some fancy texture coding to do its implementation of grabbing a source as a video feed.
Click to expand...
Both of these plugins are working differently, they don't use raw pixel data (like NDI, Teleport and Beam) from OBS but already encoded data produced by the encoder that was selected.

For RTMP you would need an RTMP server (e.g. nginx with RTMP module or maybe also ffmpeg could do that) as intermediate receiver and then have the receiving OBS instance connect to it (from a VLC or media source). I have actually used this exact setup many years ago, but it was never very stable (had a lot of the infamous A/V desync issues, also the overall delay would keep on rising until it was a minute long) and nginx was a nightmare to get configured correctly. Maybe nowadays it would work better, but now I got a 10G network and prefer to just transmit raw, which has the lowest possible CPU/GPU usage.

The way I understand this article you could also output a RIST or SRT feed without needing an intermediate server or any plugin at all and receive these feeds directly in OBS with a media or VLC source. Though that's also only for the main output and not for filters or separate sources/scenes. This actually sounds like a pretty nice solution, but I guess when you can use x264 or NVENC for this, might as well directly record/stream the feed from there.

I am not sure whether I want to look into this (regardless of filters) for Beam when OBS can do this with it's base features already, the only gain here would be ease of use, since setting it up with OBS sounds like it would be a bit harder for people that are not really tech-savvy, with entering srt:// protocol and IP address stuff and so on. Also I could offer an easy standard preset for the encoders where they would use a bandwidth suitable for the 1G networks most people use which would be visually lossless, and Beam would add the frame buffering to potentially make this work over Wifi. So there certainly would be some value to it, I need to think about it. That's definitely nothing for the 1.0 release though.
 
YorVeX

YorVeX

Member
Beam currently only supports English and German. As we're closing in on a 1.0 stable release (leaving beta phase) I'd happily take contributions for translations for more languages to be included, you'll be given credit in the release note when it's included in a release. If you want to help, please:
  • Open the latest English translation file from the GitHub repository and click the download button on the right side:
    1694926142461.png
  • Open the file from the location where you saved it with a text editor, most convenient would be one that supports syntax highlighting, on Windows you could e.g. use the free Notepad++ editor for this, but the standard Windows editor would also work
  • Change the text between quotation marks to the text translated to your language, make sure to keep any empty lines, the quotation marks and everything before and including the equal sign intact
  • Save the file as a new file and change the name to contain your ISO language code instead of the one for US American English (e.g. change en-US.ini to pt-BR.ini)
  • If you have a GitHub account or don't mind making one I would appreciate if you could create a new feature request here in the Beam GitHub repository, titled "Add <your language> translation", and attach the .ini file that you created. But it's also fine if you respond here and attach or link the file.
  • It's a lot of text, you can also add an incomplete translation for others (or you at a later time) to complete later, please then state explicitly that the translation is not complete yet
 
KattPhloxworthy

KattPhloxworthy

Member
A bit of an update:

I used the .7z file instead to set this up. Unfortunately, there are issues with this release on the audio side.

  • Only the left channel is playing across the link (I'm using an OBS-to-OBS setup, though the sources are NOT using it in the filter form, but out the back of OBS, i.e. Tools/Beam Sender Output).
  • There's a pretty incessant buzz on the right channel.
If you need anything, please let me know.

Thanks!

--Katt. =^.^=
 
YorVeX

YorVeX

Member
KattPhloxworthy said:
A bit of a heads-up, but my Windows 10 systems are reporting the installer as being a virus. I suspect this is a false positive, but I figured you ought to know.

--Katt. =^.^=
Click to expand...
Yeah, these false-positives are a common issue seen with many OBS plugin installers (or installers in general when they aren't signed with an expensive certificate), not much I can do about that. People who are scared by this can always use the manual .7z installation (though you can also manually extract the installer with a program like 7z and then you'll see that it contains the same plugin files, except for some additional files the installer needs for itself).
KattPhloxworthy said:
A bit of an update:

I used the .7z file instead to set this up. Unfortunately, there are issues with this release on the audio side.

  • Only the left channel is playing across the link (I'm using an OBS-to-OBS setup, though the sources are NOT using it in the filter form, but out the back of OBS, i.e. Tools/Beam Sender Output).
  • There's a pretty incessant buzz on the right channel.
If you need anything, please let me know.

Thanks!

--Katt. =^.^=
Click to expand...
Thanks for the report, I can reproduce it here, will investigate and come up with a fix as soon as possible. Might take several hours as I got no time right now, in the meantime I'd suggest to go back to the last version where it still worked, which is 0.8.5 - I also temporarily changed the main download link here to point to this version instead of 0.9.2. Implementation for these goddamn filters just messed up everything... >:(
 
KattPhloxworthy

KattPhloxworthy

Member
YorVeX said:
Yeah, these false-positives are a common issue seen with many OBS plugin installers (or installers in general when they aren't signed with an expensive certificate), not much I can do about that. People who are scared by this can always use the manual .7z installation (though you can also manually extract the installer with a program like 7z and then you'll see that it contains the same plugin files, except for some additional files the installer needs for itself).
Click to expand...

It's not so much the warnings I frequently get that get to me; I know all about those. This was the first time I've seen a plugin outright BLOCKED ENTIRELY, whether by the browser or the AV software. Worse is that the software doesn't allow for those of us who have a reasonable idea of what we're getting into.

The jerks...

Per your recommendation, I downgraded to 0.8.5 in the meantime. Thankfully, I don't need it in filter form.

--Katt. =^.^=
 
YorVeX

YorVeX

Member
KattPhloxworthy said:
It's not so much the warnings I frequently get that get to me; I know all about those. This was the first time I've seen a plugin outright BLOCKED ENTIRELY, whether by the browser or the AV software. Worse is that the software doesn't allow for those of us who have a reasonable idea of what we're getting into.

The jerks...

Per your recommendation, I downgraded to 0.8.5 in the meantime. Thankfully, I don't need it in filter form.

--Katt. =^.^=
Click to expand...
The level of blocking is just as random as the detection itself, if you look up whatever the AV says it detected, you will find that it's something generic determined by heuristics and not actually a specific piece of malware.

The installer does three things that malicious software also does: self-extraction, write to protected space (in this case the program files folder with OBS, which you need elevated permissions to write to) and the third point is that it writes to an existing protected directory instead of one of its own (like the OBS installer does), which is something that malware likes to do to hide itself.

But all of these things are needed for an OBS plugin installer, and that alone already makes any AV give it a high threat scoring, and then there's some random factors only AV vendors know which determine how many alarm bells it will be ringing. One factor certainly also is how widespread something is. Installers that have been around a while and have been seen by many AV installations and deemed safe will stop to trigger detections at some point, but my brand new beta releases, well, not so much ;-)

Heuristics really introduce the random part here, I can create an installer that AV software says is totally fine, then do nothing but change the installer icon to a different design, rebuild, and suddenly it's the most dangerous installer the software has ever seen and needs instant quarantining.

By the way, which AV software was it for you? You only said Windows, but I am also on Windows 10 with all the latest updates (that's where I am developing this and building the installer) and I didn't get any warnings. I would've thought that I'd learn about at least the standard Defender warnings myself while creating the installer. Or are you using additional software? If so, just get rid of it, it just doesn't make sense anymore nowadays, Defender is enough and beside that it's more important to develop good habits like double-checking locations where you are getting software from, not clicking random links from e-mails or chats, keeping your system updated, use strong (and varying passwords) and so on.

As far as I know the OBS dev team plans to implement a plugin manager at some point, although there is no ETA. This is the only thing that will probably finally solve the issue with AV detections on OBS plugin installers.

The good news is, now that I have to fix that bug and create another installer this also means rolling the dice again, maybe we get lucky and AV likes the next installer better :-D
 
Last edited:
You must log in or register to reply here.
Top