Add get/set source visibility functions

[fauxnik]

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 #73 (comment):

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).

[Fenrirthviti]

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]

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]

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]

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.