This should not be the case, at most you'd need to build the CEF wrapper, but the OBS team provides precompiled CEF builds for all platforms [0] or you can use the builds provided for free by Spotify [1].
Officially and unofficially, the most you need to do is create an Issue report with valid reproduction steps. You'd be surprised how quickly some issues get fixed just because someone finally provided the missing link in an Issue.
Yeah, I don't agree that using an LLM to generate a PR in a code base is the best line of action. I could see using an LLM to generate information to provide to create an Issue with would be potentially useful. It doesn't generate code in a way that may not be in the project's style. It doesn't hide anything from the devs. Instead, it points the devs to the specific problem and allows the devs to grok what/why/how of the issue. As we've all seen before (I'm assuming), fixing a bug in one place might not be the best fix place for the fix or a fix might reveal an issue somewhere else.
Is this on macOS [0] or another platform? I don't think I've heard of this issue - if you have a log of such a session, please create a bug report [1].
Man I get exhausted just by reading other people's complaints (without environment description or steps to reproduce). I am puzzled by what keeps OSS maintainers going.
- use obs any of the latest versions on macos any version
- have reasonably low storage
- start recording
- couple seconds or minutes later the video on the preview gets frozen and stops being recorded, while audio continues; recording status unchanged
- the freeze usually happens in the moment of switching between apps, allthough this isn't required at all
yes maintainers do it for free for years which deserves recognition but this exact issue existed for years and has been reported in many ways, without any change, and no other apps have ever behaved this way on my devices
I'm not denying you're experiencing this, I believe this issue occurs for you and likely has occured across OS and/or application versions.
My personal MacBook had 8GB of free storage (4.2GB after my test recording). I experience issues with programs like xcode failing to compile or crashes when I open too many files, pages hasn't been able to save a file since the machine had 15GB+ free.
I just download, installed, and recorded 10 minutes of desktop footage with a webcam overlay and audio. Nothing unexpected happened. I watched all 9 minutes and 28 seconds of it and it looks and sounds exactly as I would expect.
I spent my time doing this and writing this comment not to belittle you or your experience, though at this point I would ask you what do you expect to happen?
You did not post an existing bug report, or write one yourself. You've provided no evidence that anyone who contributes meaningfully to the project has experienced or even heard about this issue, let alone anyone who operates the project or consumes it from macos has any notion it is an issue.
Again, I believe this is a real issue. But there is no information here to go off of, especially with my experience, that points to anyway to meaningfully improve an OSS project in regards to your experience. If nobody with the requisite experience is asking the right questions, this will not get fixed. It starts with those people having any information to start with.
How does one operate with only 8GB of free storage? Are you not constantly receiving OS pop ups about low disk space? Are all of your USB ports dead so you can not attach external storage to move some of you (likely) unused files off? Maybe you like living dangerously? Wonder what other aspects of your life you choose to live so dangerously close to the edge as well?
I bought a Mac mini a couple years ago to develop an app and went with the cheapest model: $600 for 256GB version. Once I had Xcode, Visual Studio, and the rest of my development setup installed, I was down to roughly 60GB free. After every build, I moved installation + build/debug files to an external drive to save about 1GB.
Over the following year, roughly 20 releases later, my disk was full. Xcode generates a ton of hidden cruft in the DerivedData folder during every build/release that I wasn't even aware of! I spent a couple days googling and trying free & paid disk space analyzers (sidenote: I didn't realize how good we have it in Windows-land, there are so many good free tools but in Apple-land they are all so frustrating to use and most of them are totally useless for this particular case). Eventually, I found an Apple forum thread explaining where Xcode hides its generated build data, it was like 8GB of stuff per build! I set a calendar reminder for every 12 months to clean this folder.
I can't move anything else to an external drive really because what's left is necessary for build environment. I don't use the Mac for anything except development, so I've literally removed everything and it's down to barebones but it's still a struggle. If I had known I would have invested another $150 for the 512GB version.
I'm probably showing my age here, but I'm astonished to read that 8 GB of free space could be considered so exceptionally low that you'd receive OS alerts about it or that apps would start preemptively failing.
The most my homedir has ever grown in one year is 3.2 GB, and I don't really go out of my way to keep things tidy. I'd be very pissed off if things started pestering me to clear stuff up years before it actually became a problem.
lol! This comment made my night. In short: low available disk space, lots of projects requiring disk space.
No I don't see OS notifications about low disk space (at least on my macbook), some 3rd party applications give me notifications about low disk space though. I can confirm that all of my USB-C ports work! I have 2 local drives and a remote NAS that backup all the 'critical' data from my machine.
Unlike other operating systems I've had experience with, macOS is the most capable of operating in a (near) 'disk full' state. Where something like Windows will go from crying about the available disk space, to failing opening explorer, macOS will continue running just fine for general usage.
> Wonder what other aspects of your life you choose to live so dangerously close to the edge as well?
As for this: I've spent the last year living in India, where most people I've met think they are invincible, so I roll the dice every day!
> macOS is the most capable of operating in a (near) 'disk full' state
I used to get the OS out of space warning a lot from macOS. I used to have a 128GB SSD, and Adobe would fill up the drive with cache in the Application Support folder frequently. My newer MBP has a larger SSD, but I also manage the storage much closer now.
Makes sense, I don't run a lot of applications other than developer tooling that keep very small overwriting caches. So day to day build up isn't a huge issue.
This experience I have of low disk space is only on Sequoia which I haven't seen give an OS notification until 5gb left, which again doesn't happen often.
Are you sure that's not time machine stomping all over it? You system might be snapshotting and having trouble at low disk space. Or if you're swapping a lot, then that could also be a reason?
You can find why it was complicated [0] and why it took so long [1] on GitHub. I do wish I had been faster on it. That said, the RCE required the user to be using a vibe-coded web-based chat overlay that didn't properly sanitize chatter inputs, so has a (hopefully) limited scope.
Thanks for chiming in and linking that, that was an interesting read. As much as I understand CEF's reasoning for making this shift, it's baffling that they don't provide a universal way to implement what you now had to implement yourself.
> the original claim that lack of sanitization "required"* "vibe-coded" functionality*
That claim was ever made. The comment was about actual pieces of software that exist in the real world, not about all possible software that could exist in theory.
In real-world usage, for a user to be exposed, a necessary ingredient was to use a particular piece of software that actually exists and that happens to be vibe coded.
That does not preclude the possibility that a non-vibe-coded piece of software could have been vulnerable. It's just that such a piece of software did not happen to exist.
So why even mention vibe coding? Presumably it's relevant for some other reason. Perhaps the implication is this vibe-coded software is not an established piece of software with lots of users. (Since vibe-coded software is easier to create, maintainers may be less invested in it or committed to maintaining it. Vibe coding changes the economics and opens up the possibility of creating throwaway software.) Or perhaps the implication is that users should be more careful about using vibe-coded software.
Unfortunately, most streamers don't have the best IT security knowledge, and with AI tools now allowing them more and more than what was previously possible, it also opens the door for more vibe coded apps that could have serious security holes.
Should the streamers' apps be more secure? Absolutely, but the underlying tool should also strive to be secure enough for all use cases.
Anyway, thanks for the two links, they were interesting reads.
https://obsproject.com/blog/obs-studio-27-released
reply