Add get/set source visibility functions

fauxnik commented

2025-08-16 14:19:39 -05:00

(Migrated from github.com)

Description

This exposes a javascript function for determining the visiblity of arbitrary OBS sources and another for modifying said visibility. These functions are available to browser sources with the requisite permissions: ReadUser or higher for getSourceVisible, Advanced or higher for setSourceVisible.

Motivation and Context

Excerpt from https://github.com/obsproject/obs-browser/issues/73#issuecomment-3190645799:

I've found myself surprised to find that there's no setVisibilityState or setSourceVisibility. I was hoping to hide the browser source when an html video element finishes playing so that the source's hide transition can be triggered, and the automation software I use can later show the source again with a new URL.

I could see someone arguing that getSourceVisibility would make sense too, as the visibility of another source/non-browser source can't be determined [using the browser's Document Visibility API].

How Has This Been Tested?

I'm still working on figuring out how to build obs-browser, so the change hasn't been tested yet. I'd appreciate any tips you have regarding this as it appears the obs-studio build process has changed since the last time the obs-browser build documentation was updated.

Types of changes

New feature (non-breaking change which adds functionality)

Documentation (a change to documentation pages)

Checklist:

My code has been run through clang-format.
I have read the contributing document.
My code is not on the master branch.
The code has been tested. ← working on this, see above
All commit messages are properly formatted and commits squashed where appropriate.
I have included updates to all appropriate documentation (that I'm aware of).

### Description   This exposes a javascript function for determining the visiblity of arbitrary OBS sources and another for modifying said visibility. These functions are available to browser sources with the requisite permissions: ReadUser or higher for `getSourceVisible`, Advanced or higher for `setSourceVisible`. ### Motivation and Context    Excerpt from https://github.com/obsproject/obs-browser/issues/73#issuecomment-3190645799: > I've found myself surprised to find that there's no `setVisibilityState` or `setSourceVisibility`. I was hoping to hide the browser source when an html video element finishes playing so that the source's hide transition can be triggered, and the automation software I use can later show the source again with a new URL. > > I could see someone arguing that `getSourceVisibility` would make sense too, as the visibility of another source/non-browser source can't be determined [using the browser's Document Visibility API]. ### How Has This Been Tested?    I'm still working on figuring out how to build _obs-browser_, so the change hasn't been tested yet. I'd appreciate any tips you have regarding this as it appears the _obs-studio_ build process has changed since the last time the _obs-browser_ build documentation was updated. ### Types of changes   - New feature (non-breaking change which adds functionality)     - Documentation (a change to documentation pages) ### Checklist:   - [x] My code has been run through [clang-format](https://github.com/obsproject/obs-studio/blob/master/.clang-format). - [x] I have read the [**contributing** document](https://github.com/obsproject/obs-studio/blob/master/CONTRIBUTING.rst). - [x] My code is not on the master branch. - [ ] The code has been tested. ← working on this, see above - [x] All commit messages are properly formatted and commits squashed where appropriate. - [x] I have included updates to all appropriate documentation (that I'm aware of).

👍 2

Fenrirthviti commented

2025-08-17 00:57:40 -05:00

(Migrated from github.com)

We have previously rejected additions to the JS API as it's not really something we feel is sustainable long-term for the project.

Is there a reason that you cannot use the websockets API for this?

We have previously rejected additions to the JS API as it's not really something we feel is sustainable long-term for the project. Is there a reason that you cannot use the websockets API for this?

deemonrider commented

2025-08-22 19:34:08 -05:00

(Migrated from github.com)

We have previously rejected additions to the JS API as it's not really something we feel is sustainable long-term for the project.

Is there a reason that you cannot use the websockets API for this?

Heyo,

There are very good reasons for implementing this:
I want to provide a browser source via HTTPS to my users and read out data from OBS to ensure it’s configured correctly.

Can I use WebSockets?
No. Browser sources prevent mixed content: when the browser source is HTTPS, I can’t connect to an insecure WebSocket.
This forces me to host the overlay without HTTPS, which will stop some users from using my browser source because they heard that HTTP is insecure. Others might open the HTTP source in their browser and see a big warning that it’s not secure and go away.

Additionally, WebSockets have full OBS control. Users don’t want that. As a developer, I also want the least privileges possible and don’t want the ability to mess with the config.

Additionally for a user who doesn’t know what a WebSocket is, they might not want to activate it or bother setting it up.

For me this feature would be huge. (I need some more functions like getting transformation information of a source. I could submit PRs if there is a chance that they will be added)

> We have previously rejected additions to the JS API as it's not really something we feel is sustainable long-term for the project. > > Is there a reason that you cannot use the websockets API for this? Heyo, There are very good reasons for implementing this: I want to provide a browser source via HTTPS to my users and read out data from OBS to ensure it’s configured correctly. Can I use WebSockets? No. Browser sources prevent mixed content: when the browser source is HTTPS, I can’t connect to an insecure WebSocket. This forces me to host the overlay without HTTPS, which will stop some users from using my browser source because they heard that HTTP is insecure. Others might open the HTTP source in their browser and see a big warning that it’s not secure and go away. Additionally, WebSockets have full OBS control. Users don’t want that. As a developer, I also want the least privileges possible and don’t want the ability to mess with the config. Additionally for a user who doesn’t know what a WebSocket is, they might not want to activate it or bother setting it up. For me this feature would be huge. (I need some more functions like getting transformation information of a source. I could submit PRs if there is a chance that they will be added)

Fenrirthviti commented

2025-08-22 22:09:57 -05:00

(Migrated from github.com)

Additionally, WebSockets have full OBS control. Users don’t want that. As a developer, I also want the least privileges possible and don’t want the ability to mess with the config.

And where do we draw the line every time someone wants more features available for their specific use case?

> Additionally, WebSockets have full OBS control. Users don’t want that. As a developer, I also want the least privileges possible and don’t want the ability to mess with the config. And where do we draw the line every time someone wants more features available for their specific use case?

deemonrider commented

2025-08-22 23:43:21 -05:00

(Migrated from github.com)

Additionally, WebSockets have full OBS control. Users don’t want that. As a developer, I also want the least privileges possible and don’t want the ability to mess with the config.

And where do we draw the line every time someone wants more features available for their specific use case?

That’s a really good question. I wonder where the current line actually is. For example, startStreaming() or any other functionality that triggers or changes something in OBS doesn’t seem like it should exist here, yet it exists. This is very specific.

However, reading out information—especially related to the browser source itself—is something that really should be added.

For example I worked on window.obsstudio.getItemTransform - something I really would love to see added soon too. (Haven't send in my pr yet.)

This is a simple but crucial feature, and I honestly don’t understand why it doesn’t already exist or why it shouldn’t be added. Being able to check where a browser source is placed, whether it’s scaled, or if it’s cropped provides huge value.

So:
Sending actions to OBS -> Websocket
Reading out basic information from OBS about the browser source itself and its settings -> Browser + Websocket

This is where I would personally draw the line.

> > Additionally, WebSockets have full OBS control. Users don’t want that. As a developer, I also want the least privileges possible and don’t want the ability to mess with the config. > > And where do we draw the line every time someone wants more features available for their specific use case? That’s a really good question. I wonder where the current line actually is. For example, startStreaming() or any other functionality that triggers or changes something in OBS doesn’t seem like it should exist here, yet it exists. This is very specific. However, reading out information—especially related to the browser source itself—is something that really should be added. For example I worked on window.obsstudio.getItemTransform - something I really would love to see added soon too. (Haven't send in my pr yet.) <img width="1737" height="692" alt="image" src="https://github.com/user-attachments/assets/4892f3b7-97da-4aac-8773-db791de532d2" /> This is a simple but crucial feature, and I honestly don’t understand why it doesn’t already exist or why it shouldn’t be added. Being able to check where a browser source is placed, whether it’s scaled, or if it’s cropped provides huge value. So: Sending actions to OBS -> Websocket Reading out basic information from OBS about the browser source itself and its settings -> Browser + Websocket This is where I would personally draw the line.

This pull request is broken due to missing fork information.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin 'fauxnik/source-visibility:fauxnik/source-visibility'

git switch 'fauxnik/source-visibility'

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch 'master'

git merge --no-ff 'fauxnik/source-visibility'

git switch 'fauxnik/source-visibility'

git rebase 'master'

git switch 'master'

git merge --ff-only 'fauxnik/source-visibility'

git switch 'fauxnik/source-visibility'

git rebase 'master'

git switch 'master'

git merge --no-ff 'fauxnik/source-visibility'

git switch 'master'

git merge --squash 'fauxnik/source-visibility'

git switch 'master'

git merge --ff-only 'fauxnik/source-visibility'

git switch 'master'

git merge 'fauxnik/source-visibility'

git push origin 'master'

Rows
Columns

Add get/set source visibility functions #495

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

Checkout

Merge