When RDD with VA-API crashes, restart it without HW acceleration
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: stransky, Assigned: stransky)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
When RDD with VA-API crashes we should restart it without HW acceleration to prevent additional crashes (see Bug 1746232).
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Alastor, do you have any idea how to disable VA-API outside of RDD process? I.e. start RDD with explicitly disabled HW acceleration?
Comment 2•3 years ago
|
||
A quick idea is that, we use PRDD for the communication between the chrome process and RDD process. If we could detect the RDD restart is due to the HW acceleration crash before, then we should be able to use PRDD to set a flag on RDDParent (in RDD process), and then use that flag to explicitly disable hardware decoder creation later.
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
(In reply to Alastor Wu [:alwu] from comment #2)
A quick idea is that, we use PRDD for the communication between the chrome process and RDD process. If we could detect the RDD restart is due to the HW acceleration crash before, then we should be able to use PRDD to set a flag on RDDParent (in RDD process), and then use that flag to explicitly disable hardware decoder creation later.
Thanks!
I'd say if there's any crash on the media let's try disable HW acceleration for the same media when RDD is restarted no matter if the crash is caused by HW acceleration or not.
In the worst care the playback won't be accelerated but I think we can live with that.
Comment 4•3 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)
I'd say if there's any crash on the media let's try disable HW acceleration for the same media when RDD is restarted no matter if the crash is caused by HW acceleration or not.
In the worst care the playback won't be accelerated but I think we can live with that.
Fully agree - we can always try to get smarter about recovery.
Assignee | ||
Comment 5•3 years ago
|
||
I think this is a combination of Bug 1695718 and Bug 1691197.
Assignee | ||
Comment 6•3 years ago
|
||
Also Bug 1670817.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 8•3 years ago
|
||
I see that Windows uses direct access to gfxVars::CanUseHardwareVideoDecoding():
https://searchfox.org/mozilla-central/rev/072f9e6b7f10a00e12d0a02ac713431d0a7ee368/dom/media/ipc/RDDParent.cpp#163
Comment 10•3 years ago
|
||
bugherder |
Assignee | ||
Comment 11•3 years ago
|
||
Alastor,
I think we should revert this one. It disables HW decoding in RDD process after first RDD crash and does not enable it again for any other video until Firefox is restarted. Also it disables that on all platforms (Win/MacOS) and the HW decoding is not logged anywhere so HW decoding silently suppressed.
I think the solution in https://phabricator.services.mozilla.com/D138271 is enough and we should no be so strict here.
What do you think?
Description
•