Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Insufficient flexibility in test options #131

Open
xolkin opened this issue Mar 4, 2020 · 0 comments
Open

Insufficient flexibility in test options #131

xolkin opened this issue Mar 4, 2020 · 0 comments

Comments

@xolkin
Copy link

xolkin commented Mar 4, 2020

In our use case (which I'm sure is common), we need to establish before the test whether the user is going to publish audio at all, and/or video at all, and if so show which device to use (front/rear camera, say). A user may be connecting just to observe the meeting without publishing anything.

In other words OT.getDevice is performed first by the calling application.

So imo the interface needs options testAudio, testVideo, audioDeviceId (use if testAudio) and videoDeviceId (use if testVideo).

It also needs to report to the calling application the open/close permission dialog events as well as the approve/deny events, so that the calling application can manage the UI appropriately.

I don't see a way to get the required user experience with the classes as presently defined. That's unfortunate, because I really don't think it should be a developer's business to fork and refactor them, but that seems to be the only option for us here.

Also the momentum towards the constraint-based mediaDevices.getUserMedia means that code relying on enumerating and selecting devices is obsolescent; at least as I understand the rather confusing portfolio of specifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant