There is no way to release the local device (e.g. video, audio) aquired via mozGetUserMedia() through the LocalMediaStream object

RESOLVED DUPLICATE of bug 803976

Status

()

Core
WebRTC: Audio/Video
RESOLVED DUPLICATE of bug 803976
6 years ago
6 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

18 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [getUserMedia], [blocking-gum+])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Right now it's not possible to release the local device (e.g. camera) once the code below has been ran:

    navigator.mozGetUserMedia({video:true}, function (stream) {
      // Will fail because we do not return a LocalMediaStream
      stream.stop();
    }

It also applies to all other types of media.

I will attach a Mochitest which should be checked-in together with the patch in a bit.

Updated

6 years ago
Whiteboard: [getUserMedia]
(Reporter)

Updated

6 years ago
Summary: There is no way to release the camera aquired via mozGetUserMedia() → There is no way to release the local device (e.g. camera) aquired via mozGetUserMedia()
Whiteboard: [getUserMedia]

Updated

6 years ago
Whiteboard: [getUserMedia]
(Reporter)

Comment 1

6 years ago
Created attachment 668367 [details]
Possible Mochitest

This is a potential Mochitest for this specific bug. I'm not sure which interface Randell was referring to on IRC so I haven't implemented a specific check here yet.

Anant, can you please give feedback in how this bug can be solved?
(Reporter)

Updated

6 years ago
Summary: There is no way to release the local device (e.g. camera) aquired via mozGetUserMedia() → There is no way to release the local device (e.g. video, audio) aquired via mozGetUserMedia()
In your code snippet, the stream isn't actually assigned anywhere, so the camera should not turn on. Is that not the case?

In order to release the local device, just de-assign the stream from any active <video>/<audio> element. We should support stop() too, of course, but don't currently.
(Reporter)

Comment 3

6 years ago
(In reply to Anant Narayanan [:anant] from comment #2)
> In your code snippet, the stream isn't actually assigned anywhere, so the
> camera should not turn on. Is that not the case?

Right, that's what I see here. The green LED on my MBP gets green.

> In order to release the local device, just de-assign the stream from any
> active <video>/<audio> element. We should support stop() too, of course, but
> don't currently.

So probably we have two issues here?
Yes, sounds like we have 2 bugs that need to be addressed.
I recall there was already a bug open about the camera turning on early, Jason?
(In reply to Anant Narayanan [:anant] from comment #5)
> I recall there was already a bug open about the camera turning on early,
> Jason?

Bug 782191.

Updated

6 years ago
Whiteboard: [getUserMedia] → [getUserMedia], [blocking-gum+]

Updated

6 years ago
Flags: in-testsuite?
(Reporter)

Updated

6 years ago
Blocks: 773646
Updating title. It is technically possible to release the local device if you add and remove the stream from a HTMLMediaElement, although that's a different bug. The real issue here is that you can't do it through the stream object.
Summary: There is no way to release the local device (e.g. video, audio) aquired via mozGetUserMedia() → There is no way to release the local device (e.g. video, audio) aquired via mozGetUserMedia() through the MediaStream object

Updated

6 years ago
No longer blocks: 773646

Updated

6 years ago
Summary: There is no way to release the local device (e.g. video, audio) aquired via mozGetUserMedia() through the MediaStream object → There is no way to release the local device (e.g. video, audio) aquired via mozGetUserMedia() through the LocalMediaStream object
(Reporter)

Comment 8

6 years ago
Not sure why bug 803976 has been filed separately but I would suggest to keep that open for a specific mochitest. If you disagree we can also take bug 803976 for it.
Depends on: 803976
This will be fixed by bug 803976. I'm duping on that bug.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
No longer depends on: 803976
Flags: in-testsuite?
Resolution: --- → DUPLICATE
Duplicate of bug: 803976
You need to log in before you can comment on or make changes to this bug.