Spreed: Webcam hardware light is on during audio call

[b2cbd]

Steps to reproduce

1. Login
2. Make a Video Call
3. Turn off Camera/Video

Expected behaviour

Webcam Hardware light should be off

Actual behaviour

Webcam Hardware light is on during audio call

Talk app

Talk app version: 9.0.3

Custom Signaling server configured: yes with the latest codebase

Custom TURN server configured: yes

Custom STUN server configured: yes

Browser

Microphone available: yes

Camera available: yes

Operating system: Windows 10

Browser name: Chrome

Browser version: latest

[nickvergessen]

Well something for later. The icon lights up because we grab the permissions for the camera as well, so we don't have to prompt users everytime we toggle on and off the camera.

[PVince81]

This scared me as well. Often times when I see it on when in another time I wonder whether I properly disabled it.

I'm a bit surprised that it's just a permission thing. Wondering if the hardware is still grabbed and blocked for other applications, maybe the video is streamed to /dev/null.

Anyway, nice to fix when there's time

[PVince81]

I can confirm that this blocks the camera so it cannot be grabbed by another browser.

[Tachi107]

This is a really strange behavior, that really annoys me and everyone that ever used Talk with me.
How can other apps like Talk (Google Meet, Discord...) completely turn off video access when they don't need it?

[PVince81]

I had a quick look and it's not a trivial change: here is where the video stream gets paused https://github.com/nextcloud/spreed/blob/master/src/utils/webrtc/simplewebrtc/localmedia.js#L612 by toggling the enabled flag of the video track.

According to https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack setting that flag (muting) should disable the camera light. However this is not what we are observing.

I tried adding some code to stop the track completely with track.stop() and it indeed stops the camera but also has no way to be resumed. So the challenge will be to reenable it, will likely need to re-call getUserMedia() which would likely re-grab the audio as well. Maybe we'll need to first split the video and audio code paths somehow.

So this is not a simple fix, might need to reorganize some code around the idea that a track is stopped and destroyed, and need to be able to reset it up from scratch when re-enabling. Needs further research.