Closed
Bug 988884
Opened 11 years ago
Closed 11 years ago
Media Encoderthreads are not ended by the end of xpcom-shutdown-threads
Categories
(Core :: Audio/Video: Recording, defect)
Core
Audio/Video: Recording
Tracking
()
RESOLVED
FIXED
mozilla31
People
(Reporter: jesup, Assigned: rlin)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
|
1.55 KB,
patch
|
Details | Diff | Splinter Review |
With the patch from bug 988464, we see Media Encoder threads in M1 still active after xpcom-shutdown-threads (which is after xpcom-shutdown). One run with an earlier version of the patch:
https://tbpl.mozilla.org/?tree=Try&rev=8ac1c136a95f
See https://wiki.mozilla.org/XPCOM_Shutdown
xpcom-shutdown-threads: "Any non-main-thread event queues should be finished by the module which owns them. All threads running XPCOM code should be joined. Any special services that might be required for component loader shutdown should be obtained and cached by the end of this notification. Initial garbage collection should be performed at this stage."
| Assignee | ||
Comment 1•11 years ago
|
||
Hi Karl,
We use that to shutdown encoder if the media stream didn't fire the TRACK_EVENT_ENDED event.
i.e Record a AudioContext and close browser directly. We found we didn't receive this evnet ID and encoder thread keep waiting for this event.
Flags: needinfo?(karlt)
Comment 2•11 years ago
|
||
Does the Media Encoder only wait for TRACK_EVENT_ENDED, or does it also wait for another event?
If another event, which event? xpcom-shutdown?
I don't know whether TRACK_EVENT_ENDED is dispatched when the MSG is force shutdown.
Flags: needinfo?(karlt)
| Assignee | ||
Comment 3•11 years ago
|
||
The media stream still keep alive on this case, so right now we use the xpcom shutdown to avoid the close-browser -hang problem. If media stream can end on this case first, the encoder thread can be ended by itself.
| Assignee | ||
Comment 4•11 years ago
|
||
Hi Roc,
When we try to record media stream from audio context, we hit the shutdown issue.
the media strema log is
==
1135867712[7fa442658260]: MediaStreamGraph 7fa40bc2ab80 ForceShutdown
90175232[7fa40be488e0]: Resuming after timeout; at 5.887897, elapsed=0.001081
90175232[7fa40be488e0]: Updating current time to 5.066008 (real 5.887967, mStateComputedTime 5.096758)
90175232[7fa40be488e0]: MediaStream 7fa41016a560 bufferStartTime=0.000001 blockedTime=0.000000
...
90175232[7fa40be488e0]: Media graph 7fa40bc2ab80 computing blocking for time 5.096758
90175232[7fa40be488e0]: Media graph 7fa40bc2ab80 computed blocking for interval 5.096758 to 5.096758
90175232[7fa40be488e0]: MediaStreamGraph 7fa40bc2ab80 waiting for main thread cleanup
1135867712[7fa442658260]: Stopping threads for MediaStreamGraph 7fa40bc2ab80
==
Encoder thread would keep waiting for the TRACK_EVENT_ENDED.
Flags: needinfo?(roc)
I think MediaRecorder should add its own shutdown observer and shut down its thread from there.
Flags: needinfo?(roc)
| Assignee | ||
Comment 6•11 years ago
|
||
Attachment #8399368 -
Flags: review?(roc)
Attachment #8399368 -
Flags: review?(roc) → review+
| Assignee | ||
Comment 7•11 years ago
|
||
check-in patch, carry reviewer.
| Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Updated•11 years ago
|
Attachment #8399368 -
Attachment is obsolete: true
Comment 8•11 years ago
|
||
Assignee: nobody → rlin
Keywords: checkin-needed
Comment 9•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Comment 10•11 years ago
|
||
The following changeset is now in Firefox Nightly:
> e5c3355706bd Bug 988884 - Properly shutdown mediaencoder threads. r=roc
Nightly Build Information:
ID: 20140402030201
Changeset: 4941a2ac0786109b08856738019b016a6c5a66a6
Version: 31.0a1
TBPL: https://tbpl.mozilla.org/?rev=4941a2ac0786
URL: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central
Download Links:
> Linux x86: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central/firefox-31.0a1.en-US.linux-i686.tar.bz2
> Linux x86_64: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central/firefox-31.0a1.en-US.linux-x86_64.tar.bz2
> Linux x86_64 ASAN: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central/firefox-31.0a1.en-US.linux-x86_64-asan.tar.bz2
> Mac: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central/firefox-31.0a1.en-US.mac.dmg
> Win32: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central/firefox-31.0a1.en-US.win32.installer.exe
> Win64: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-02-03-02-01-mozilla-central/firefox-31.0a1.en-US.win64-x86_64.installer.exe
Previous Nightly Build Information:
ID: 20140401030203
Changeset: 1417d180a1d8665b1a91b897d1cc4cc31e7980d4
Version: 31.0a1
TBPL: https://tbpl.mozilla.org/?rev=1417d180a1d8
URL: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/04/2014-04-01-03-02-03-mozilla-central
| Reporter | ||
Updated•9 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•