Closed Bug 1752493 Opened 3 years ago Closed 3 years ago

When RDD with VA-API crashes, restart it without HW acceleration

Categories

(Core :: Audio/Video: Playback, defect, P3)

defect

Tracking

()

RESOLVED FIXED
99 Branch
Tracking Status
firefox99 --- fixed

People

(Reporter: stransky, Assigned: stransky)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

When RDD with VA-API crashes we should restart it without HW acceleration to prevent additional crashes (see Bug 1746232).

Alastor, do you have any idea how to disable VA-API outside of RDD process? I.e. start RDD with explicitly disabled HW acceleration?

Flags: needinfo?(alwu)

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.

Flags: needinfo?(alwu)
Severity: -- → S3
Priority: -- → P3

(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.

(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.

Blocks: RDD

I think this is a combination of Bug 1695718 and Bug 1691197.

Assignee: nobody → stransky
Status: NEW → ASSIGNED

I see that Windows uses direct access to gfxVars::CanUseHardwareVideoDecoding():
https://searchfox.org/mozilla-central/rev/072f9e6b7f10a00e12d0a02ac713431d0a7ee368/dom/media/ipc/RDDParent.cpp#163

Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/9d0331b23ab4 Disable HW decoding in RDD process if we're asked so r=alwu
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch

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?

Flags: needinfo?(alwu)

Sounds good to me! Thanks!

Flags: needinfo?(alwu)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: