Use fake UI for media stream #143

Closed
hunterpollpeter wants to merge 1 commit from use-fake-ui-flag into master
hunterpollpeter commented 2019-01-07 16:09:48 -06:00 (Migrated from github.com)

Use fake UI for media stream avoids the need to grant camera/microphone permissions.

Fixes #146

Use fake UI for media stream avoids the need to grant camera/microphone permissions. Fixes #146
hunterpollpeter commented 2019-01-17 10:25:41 -06:00 (Migrated from github.com)

Any word on getting this merged? @DDRBoxman @jp9000

Any word on getting this merged? @DDRBoxman @jp9000
dodgepong commented 2019-01-25 15:57:43 -06:00 (Migrated from github.com)

While I don't necessarily disagree with this feature being enabled, can you describe your use case for this?

While I don't necessarily disagree with this feature being enabled, can you describe your use case for this?
mphacker commented 2019-01-27 13:29:06 -06:00 (Migrated from github.com)

I need this so I can use a microphone audio source and render a visualizer. Similar to what you see here:
https://codepen.io/zapplebee/pen/gbNbZE

@hunterpollpeter Do you happen to have a compiled version of this so I can give it a try? I don't have everything setup to compile all of this yet. @dodgepong is there other options for passing in command line switches instead of having to change the source every time something like this comes up?

I need this so I can use a microphone audio source and render a visualizer. Similar to what you see here: https://codepen.io/zapplebee/pen/gbNbZE @hunterpollpeter Do you happen to have a compiled version of this so I can give it a try? I don't have everything setup to compile all of this yet. @dodgepong is there other options for passing in command line switches instead of having to change the source every time something like this comes up?
mphacker commented 2019-01-28 18:33:45 -06:00 (Migrated from github.com)

Just realized that the command lines from OBS are passed in to the browser source. So although this would be a good addition I see it being more safe to pass in the parameter. Having it built in could allow a rogue page to listen in to a user's input device with out them being aware.

Just realized that the command lines from OBS are passed in to the browser source. So although this would be a good addition I see it being more safe to pass in the parameter. Having it built in could allow a rogue page to listen in to a user's input device with out them being aware.
WizardCM commented 2019-01-28 18:48:50 -06:00 (Migrated from github.com)

I agree this should be opt-in rather than the norm. As OBS passes flags to the browser source, this particular change shouldn't be merged.

I agree this should be opt-in rather than the norm. As OBS passes flags to the browser source, this particular change shouldn't be merged.
hunterpollpeter commented 2019-01-29 12:18:59 -06:00 (Migrated from github.com)

My use case is creating overlays that use the webcam from the browser source itself. The idea is to make it easier for less technically inclined people to have an overlay with populated data.

My use case is creating overlays that use the webcam from the browser source itself. The idea is to make it easier for less technically inclined people to have an overlay with populated data.
hunterpollpeter commented 2019-01-29 17:11:08 -06:00 (Migrated from github.com)

I do see how this can be exploited and maybe hardcoding the flag isn't the best option. Would it be a better solution to make this an option on the browser-source configuration window? Or maybe even a preference within the application? Thanks for the discussion!

I do see how this can be exploited and maybe hardcoding the flag isn't the best option. Would it be a better solution to make this an option on the browser-source configuration window? Or maybe even a preference within the application? Thanks for the discussion!
WizardCM commented 2019-12-28 19:24:42 -06:00 (Migrated from github.com)

I agree this would be best as an option in each source. "Allow this page to access audio/video devices, and my display"

I agree this would be best as an option in each source. "Allow this page to access audio/video devices, and my display"
mnill commented 2020-01-27 08:57:58 -06:00 (Migrated from github.com)

I need this feature to make face masks plugin with browser, not with separate dll which is hard to install.

I need this feature to make face masks plugin with browser, not with separate dll which is hard to install.
eliasthompson commented 2021-04-14 00:03:56 -05:00 (Migrated from github.com)

Been having issues with arguments like --enable-media-stream and --use-fake-ui-for-media-stream not working for browser sources when passed in v26. Has there been any traction on this PR in the past year or so? And if the option lies in each browser source properties, how would we be able to enable this for browser docks?

Been having issues with arguments like `--enable-media-stream` and `--use-fake-ui-for-media-stream` not working for browser sources when passed in v26. Has there been any traction on this PR in the past year or so? And if the option lies in each browser source properties, how would we be able to enable this for browser docks?
RytoEX commented 2021-04-14 01:37:15 -05:00 (Migrated from github.com)

Been having issues with arguments like --enable-media-stream and --use-fake-ui-for-media-stream not working for browser sources when passed in v26.

@eliasthompson
Can you provide a reproducible test case? What specific platform/OS and what specific version of OBS? What exactly are you trying to do, what is happening, and what do you expect to happen? Though, this conversation should probably start in one of our support channels and be filed as its own issue if the flags are somehow not working as intended. I'd rather this PR discussion stay focused on the merits of whether this PR should be merged or not.

Has there been any traction on this PR in the past year or so?

No, there has been no movement on this PR. Per @WizardCM 's comment above:

I agree this should be opt-in rather than the norm. As OBS passes flags to the browser source, this particular change shouldn't be merged.

And his other comment:

I agree this would be best as an option in each source. "Allow this page to access audio/video devices, and my display"

We pass all user-specified flags to CEF. I agree that we should not enable this flag by default for all users.

And if the option lies in each browser source properties, how would we be able to enable this for browser docks?

You wouldn't, as far as I know. Switches passed to CEF affect the process/application from startup to close. I don't think they can be selectively applied to different tabs/windows (browser sources or browser panels, in our case).

Between the fact that we don't want to universally allow browser sources to automatically capture a user's audio or video without permission and the fact that a user can already pass any flag to CEF via an application shortcut, I'm in favor of closing this.

> Been having issues with arguments like `--enable-media-stream` and `--use-fake-ui-for-media-stream` not working for browser sources when passed in v26. @eliasthompson Can you provide a reproducible test case? What specific platform/OS and what specific version of OBS? What exactly are you trying to do, what is happening, and what do you expect to happen? Though, this conversation should probably start in one of our support channels and be filed as its own issue if the flags are somehow not working as intended. I'd rather this PR discussion stay focused on the merits of whether this PR should be merged or not. > Has there been any traction on this PR in the past year or so? No, there has been no movement on this PR. Per @WizardCM 's [comment above](https://github.com/obsproject/obs-browser/pull/143#issuecomment-458362077): > I agree this should be opt-in rather than the norm. As OBS passes flags to the browser source, this particular change shouldn't be merged. And his [other comment](https://github.com/obsproject/obs-browser/pull/143#issuecomment-569465234): > I agree this would be best as an option in each source. "Allow this page to access audio/video devices, and my display" We pass all user-specified flags to CEF. I agree that we should not enable this flag by default for all users. > And if the option lies in each browser source properties, how would we be able to enable this for browser docks? You wouldn't, as far as I know. Switches passed to CEF affect the process/application from startup to close. I don't think they can be selectively applied to different tabs/windows (browser sources or browser panels, in our case). Between the fact that we don't want to universally allow browser sources to automatically capture a user's audio or video without permission and the fact that a user can already pass any flag to CEF via an application shortcut, I'm in favor of closing this.
eliasthompson commented 2021-04-14 03:51:53 -05:00 (Migrated from github.com)

Yeah I didn't mean to derail the discussion with my own issues, I'll post those in the appropriate channels if they persist.

In terms of the PR, yeah, if the only way it works is by global enabling it for the during that the program is run, then not enabling it by default is the right call imo and the PR should be closed. But if there is any way that it can be set/manipulated while the program is running, I'd be highly in favor of some sort of GUI solution.

Yeah I didn't mean to derail the discussion with my own issues, I'll post those in the appropriate channels if they persist. In terms of the PR, yeah, if the only way it works is by global enabling it for the during that the program is run, then not enabling it by default is the right call imo and the PR should be closed. But if there is any way that it can be set/manipulated while the program is running, I'd be highly in favor of some sort of GUI solution.
RytoEX commented 2021-04-14 04:16:37 -05:00 (Migrated from github.com)

In terms of the PR, yeah, if the only way it works is by global enabling it for the during that the program is run, then not enabling it by default is the right call imo and the PR should be closed. But if there is any way that it can be set/manipulated while the program is running, I'd be highly in favor of some sort of GUI solution.

As far as I know, all CEF switches/flags are global. There are some, like hardware acceleration, that we can check the value of and then do other things like create UI elements. This, however, is a flag that bypasses a user permission dialog and prevents it from being displayed and automatically uses default audio and video devices for media streams. I don't know of a way we could intercept the functionality and change it on a per source basis.

> In terms of the PR, yeah, if the only way it works is by global enabling it for the during that the program is run, then not enabling it by default is the right call imo and the PR should be closed. But if there is any way that it can be set/manipulated while the program is running, I'd be highly in favor of some sort of GUI solution. As far as I know, all CEF switches/flags are global. There are some, like hardware acceleration, that we can check the value of and then do other things like create UI elements. This, however, is a flag that bypasses a user permission dialog and prevents it from being displayed and automatically uses default audio and video devices for media streams. I don't know of a way we could intercept the functionality and change it on a per source basis.
RytoEX commented 2021-04-15 01:22:44 -05:00 (Migrated from github.com)

Per conversation with @WizardCM about unaddressed concerns, I'm going to close this PR.

Per conversation with @WizardCM about unaddressed concerns, I'm going to close this PR.

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-obsproject/obs-browser!143
No description provided.