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

Status: RESOLVED FIXED

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

Description

[Martin Stránský [:stransky] (ni? me)]

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

Comment 1

[Martin Stránský [:stransky] (ni? me)]

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

[Alastor Wu [: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.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

(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

[Robert Mader [:rmader]]

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

Comment 5

[Martin Stránský [:stransky] (ni? me)]

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

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Also Bug 1670817.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1752493 Disable HW decoding in RDD process if we're asked so r?alwu

Comment 8

[Martin Stránský [:stransky] (ni? me)]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9d0331b23ab4
Disable HW decoding in RDD process if we're asked so r=alwu

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/9d0331b23ab4

Comment 11

[Martin Stránský [:stransky] (ni? me)]

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?

Comment 12

[Alastor Wu [:alwu]]

Sounds good to me! Thanks!