I notice that these bindings are published by StreamLabs. I think their whole application is an Electron based monstrosity. It sure had the sluggishness to indicate that it was when I tried it. Meanwhile vanilla OBS has been performant for as long as I’ve been using it.
So that’s one use case; building bloated Electron based software where a native application was doing the job excellently already.
Automation. The same reason that Office apps can be scripted with VBScript. It seems like OBS is GPLv2 so may be somewhat amenable to having external automation, but I suspect that may be a controversial opinion. Going that path depends on how risk averse you are.
OBS is open source software and various third parties have tried to wrap it up into a commercial services offering. They embed it in something like an Electron app and then have it talk with their paid-for services, all through node.
Manually curating all of these videos would take a lot of time and effort.
In order to record these videos, I have scripts set up that load high level games ready to spectate, start watching via the League of Legends spectator client, play the replay back, start recording using OBS, programmatically adding an overlay to the videos showcasing information (which would be much harder to do post-production as this would require re-encoding a full 25-50 minute video each time), stop recording with OBS, and then upload to YouTube with relevant title / description / thumbnail.
I could (and have looked into) hooking directly into windows APIs to do the recording, and editing of the videos, but it is much easier with OBS.
The purpose of this code is to find the active league of legends executable, create a 'Game Capture' source with the league of legends window as the input, and then add that source to a 'Scene', and then start recording when triggered, and stop recording when triggered.
The function (setupScene) on line 55 is the interesting OBS stuff.
Unfortunately this doesn't include any overlay stuff, but it's all done in a similar way, where I add a source with a locally hosted server as a 'Browser' Source on top of the gameplay, with the parameters of the URL telling the server what information I want to be displayed on the website.
Yes, but people like to be able to search on YouTube 'Lee Sin Challenger Replay' and immediately get a video of a high level game with a familiar video UI.
For anyone lacking some backstory here, OBS Studio is a highly performant, completely open source, native C/C++ app. It's honestly one of the best real time video compositing tools, and works directly with ffmpeg, x264, NVENC, etc. They recently released official support for Wayland as well!
Streamlabs OBS is a fork of OBS Studio with an added Electron wrapper. Streamlabs' primary focus for their OBS fork is to integrate directly with their paid services and other integrations. Due to the electron wrapper, "SLOBS" is known to underperform and crash unexpectedly.
Personally I'm concerned for the direction of Streamlabs OBS, with more and more of it's code becoming closed source or otherwise unavailable. They are also declining new streaming services be added to the tool, unless the service pays money, or has enough clout. For their business, the direction makes complete sense however I can't help but feel this is hurting the overall open source community.
> Streamlabs OBS is a fork of OBS Studio with an added Electron wrapper.
Somehow this is the first time that I'm learning that OBS has a documented internal interface that can be separated from its UI at all, let alone imported into other projects. It's not really Streamlab's product that makes this interesting, so much as that there are a number of other scenarios where it might be nice to build a tool around OBS without building an extension into the app itself.
I'm kind of curious now to see what would be possible here. Maybe it would be overkill, but it would be interesting to try and get OBS's backend working as, say, a quick command line gif tool. OBS also supports setting itself up as a virtual camera, which is really useful, but it's a little cumbersome to manage that through the UI itself, maybe a smaller wrapper would be more useful. Or even if it's possible to embed libobs and use it headlessly on a Raspberry Pi with a couple of webcams as the source.
Maybe people have already done this stuff and I'm just out of the loop.
I haven't looked into who might have built on top of OBS in the way you describe, but I agree it is a powerful possibility thanks to the efforts of its maintainers and GPLv2.
Curious, is SLOBS not architected to run OBS separately as service? Electron has its issues but, for example, a Slack client crash does not take down the service.
It's ease of use with streamlabs (a must/default on streaming platforms), makes it the first thing people are reaching for when streaming.
I think the only concern is taking attention away from an opensourse solution when they could get more funding/attention to keep it current. Though I doubt it will ever go away, since once you deal with a crash or something weird with SLOBS you immediately go back to OBS.
Its OBS on training wheels, shiny pay for more shiny training wheels.
I don't want a real time video compositing tool, I want a tool that records (one window, one region of the screen, or one capture device) at its native resolution. And ShareX (a Windows-only screenshot tool) manages to achieve the first 2 with a better UI than OBS Studio (though possibly with lower performance), though OBS Studio recently added "Resize output (source size)" which makes OBS's UI substantially smoother for this use case.
Isn't it "deprecated"? I remember back when hacking on node in something like 2010-12 reading that GYP was being deprecated by the V8 team and discussions about phasing it out?
I'm guessing 2) would be easier to implement as 1) would require using the FFI of the wrapping language, which can be challenging. Also, the scripting language is likely to be well-documented as I assume it's core functionality readily available from the GUI. (Although, as a counter-example to this, I found GIMP's Scheme scripting terribly under-documented, so not always.)
> For bonus points, present a case for one of them being better than the other
2) is clearly better because it treats the whole OBS application as a black box and just pipes (or whatever) scripting command strings to OBS.
1) is clearly better because performance. Ee're talking about a video streaming app, so performance is essential.
25 comments
[ 3.3 ms ] story [ 66.6 ms ] threadSo that’s one use case; building bloated Electron based software where a native application was doing the job excellently already.
OBS is open source software and various third parties have tried to wrap it up into a commercial services offering. They embed it in something like an Electron app and then have it talk with their paid-for services, all through node.
I run a few channels similar to this one, which provide value by showcasing how the top-end League of Legends players play the game:
https://www.youtube.com/channel/UCMvtjPFhJR0BeErid-s1Zbg/vid...
Manually curating all of these videos would take a lot of time and effort.
In order to record these videos, I have scripts set up that load high level games ready to spectate, start watching via the League of Legends spectator client, play the replay back, start recording using OBS, programmatically adding an overlay to the videos showcasing information (which would be much harder to do post-production as this would require re-encoding a full 25-50 minute video each time), stop recording with OBS, and then upload to YouTube with relevant title / description / thumbnail.
I could (and have looked into) hooking directly into windows APIs to do the recording, and editing of the videos, but it is much easier with OBS.
But I'm also using this code in a consumer focused desktop client, for gamers to record their own gameplay and review it back (replays.lol)
The obs-studio-node integration code can be found here: https://github.com/davidweatherall/replayslol-obs-recorder/b...
The purpose of this code is to find the active league of legends executable, create a 'Game Capture' source with the league of legends window as the input, and then add that source to a 'Scene', and then start recording when triggered, and stop recording when triggered.
The function (setupScene) on line 55 is the interesting OBS stuff.
Unfortunately this doesn't include any overlay stuff, but it's all done in a similar way, where I add a source with a locally hosted server as a 'Browser' Source on top of the gameplay, with the parameters of the URL telling the server what information I want to be displayed on the website.
The overlay is just a website, with a transparent background, and content determined by the parameters. - Here is what the website base code looks like - https://gist.github.com/davidweatherall/68e6d4422ce4c0b6fbcc...
Streamlabs OBS is a fork of OBS Studio with an added Electron wrapper. Streamlabs' primary focus for their OBS fork is to integrate directly with their paid services and other integrations. Due to the electron wrapper, "SLOBS" is known to underperform and crash unexpectedly.
Personally I'm concerned for the direction of Streamlabs OBS, with more and more of it's code becoming closed source or otherwise unavailable. They are also declining new streaming services be added to the tool, unless the service pays money, or has enough clout. For their business, the direction makes complete sense however I can't help but feel this is hurting the overall open source community.
Somehow this is the first time that I'm learning that OBS has a documented internal interface that can be separated from its UI at all, let alone imported into other projects. It's not really Streamlab's product that makes this interesting, so much as that there are a number of other scenarios where it might be nice to build a tool around OBS without building an extension into the app itself.
https://obsproject.com/docs/backend-design.html
I'm kind of curious now to see what would be possible here. Maybe it would be overkill, but it would be interesting to try and get OBS's backend working as, say, a quick command line gif tool. OBS also supports setting itself up as a virtual camera, which is really useful, but it's a little cumbersome to manage that through the UI itself, maybe a smaller wrapper would be more useful. Or even if it's possible to embed libobs and use it headlessly on a Raspberry Pi with a couple of webcams as the source.
Maybe people have already done this stuff and I'm just out of the loop.
I think the only concern is taking attention away from an opensourse solution when they could get more funding/attention to keep it current. Though I doubt it will ever go away, since once you deal with a crash or something weird with SLOBS you immediately go back to OBS.
Its OBS on training wheels, shiny pay for more shiny training wheels.
For example, it can't tolerate WHITESPACES in paths, and the pull request for the fix been sitting rotting for years.
1. a (typically) non-compiled language wrapper around the internal library
2. a (normally) non-compiled language used for scripting inside the application
Guess which one is easier to do? For bonus points, present a case for one of them being better than the other
I'm guessing 2) would be easier to implement as 1) would require using the FFI of the wrapping language, which can be challenging. Also, the scripting language is likely to be well-documented as I assume it's core functionality readily available from the GUI. (Although, as a counter-example to this, I found GIMP's Scheme scripting terribly under-documented, so not always.)
> For bonus points, present a case for one of them being better than the other
2) is clearly better because it treats the whole OBS application as a black box and just pipes (or whatever) scripting command strings to OBS.
1) is clearly better because performance. Ee're talking about a video streaming app, so performance is essential.
https://obsproject.com/forum/resources/obs-websocket-remote-...
NodeJS lib:
https://www.npmjs.com/package/obs-websocket-js