Closed
Bug 851100
Opened 12 years ago
Closed 9 years ago
Localmediastream is not stopping using stop() method when owning references not GCed
Categories
(Core :: Audio/Video: MediaStreamGraph, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1209033
People
(Reporter: vvinoth, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22
Steps to reproduce:
I am capturing the video from the webcam and displaying it in the browser. I use localMediaStream to fetch the video from the webcam device.
Actual results:
When i used play and pause method to the localMediaStream object, it works fine. But stop method is not working fine.
Expected results:
When i use stop method, the video has to be stopped.
Updated•12 years ago
|
Component: Untriaged → Video/Audio
Product: Firefox → Core
Comment 1•10 years ago
|
||
One case in which this can happen is that for whatever reason, the stop doesn't entirely take effect until all owning references are released, and, apparently, a GC has happened.
jib put together <http://jsfiddle.net/jib1/wq35njdu/>, which is a good place to play with what works and what doesn't.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Summary: Localmediastream is not stopping using stop() method → Localmediastream is not stopping using stop() method when owning references not GCed
Comment 2•10 years ago
|
||
Apologies Vinoth if we're hijacking your bug report here - you didn't provide a test case - though I'd be curious to know if video stops for you if you run the jsfiddle in comment 1?
We're chasing a slightly different symptom which is how to stop the track sufficiently to reclaim the camera resource in a subsequent gUM call with different constraints.
That fiddle was me trying to get results without waiting arbitrary amounts of time. However, after some experimenting, it looks like clearing the reference is not the issue so much as that .stop() seems to take 50-100 ms to take effect. Here's a second fiddle using wait(200) on line 24 instead to illustrate that:
http://jsfiddle.net/jib1/cydm91qc
On OSX it produces this output for me:
width = 640, height = 480
width = 1280, height = 720
If I change the wait(200) to wait(50) then it doesn't work so well:
width = 640, height = 480
Starting video failed line 0
which points to a timing issue with .stop(). I think, ideally, the JS shouldn't have to care about these timing issues, and we need to figure out a solution for that.
Comment 3•10 years ago
|
||
(The fiddles use the newer promises-API and only work in Nightly BTW.)
Comment 4•10 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] from comment #2)
> Here's a second fiddle using wait(200) on line 24 instead to illustrate that:
Line 20 after a refactor.
Comment 5•10 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] from comment #2)
> If I change the wait(200) to wait(50) then it doesn't work so well:
>
> width = 640, height = 480
> Starting video failed line 0
Interestingly, if I add a line to zero out the stream after stop:
video.mozSrcObject.stop();
+ video.mozSrcObject = null;
then it fares better:
width = 640, height = 480
width = 640, height = 480
but is still incorrect since I got the same resolution twice instead of 1280x720 the second time (so there may be two bugs here).
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Comment 6•9 years ago
|
||
In 43 I still see the symptoms, but not in 44. Closing as dup of bug 1209033.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•