1929491 - Follow up for High volume of startup errors for the external state machine
Closed Bug 1929491 Opened 18 days ago Closed 17 days ago

Follow up for High volume of startup errors for the external state machine

Categories

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

defect

Tracking

()

RESOLVED FIXED
134 Branch
Tracking Status
firefox132 + fixed
firefox133 + fixed
firefox134 + fixed

People

(Reporter: alwu, Assigned: alwu)

References

Details

Attachments

(2 files)

By checking our dashboard, we can see that the NS_ERROR_DOM_MEDIA_FATAL_ERR drops, and NS_ERROR_DOM_MEDIA_MEDIA_ENGINE_INITIALIZATION_ERR raise, which is expected by landing bug 1928798.

However, the error rate is still high, and didn't drop as low as our expectation. That means we still have another place raising the error. By debugging bug 1929251, I found another possibility, and we should land another fix to see if it helps mitigate the error further more.

If an error occurs during media engine initialization, we should attempt
to use another state machine for playback. However, if the key system
is already set, it indicates that playback can only be initiated via the
media engine. In this case, we should propagate the error and refrain
from trying another state machine.

Pushed by alwu@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/86a45643d789 try another state machine if any error happens during the engine initialization phase. r=media-playback-reviewers,aosmond

Comment on attachment 9435775 [details]
Bug 1929491 - try another state machine if any error happens during the engine initialization phase.

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: Widevine L3 playback might be failed for some Windows users, due to their device capabilities
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): No new feature added or big structure change, we just prevent propagating an error which will abort the whole playback. Instead, we would re-try playback by another media pipeline.
  • String changes made/needed:
  • Is Android affected?: No
Attachment #9435775 - Flags: approval-mozilla-release?
Attachment #9435775 - Flags: approval-mozilla-beta?
Severity: -- → S2
Status: NEW → RESOLVED
Closed: 17 days ago
Resolution: --- → FIXED
Target Milestone: --- → 134 Branch

Comment on attachment 9435775 [details]
Bug 1929491 - try another state machine if any error happens during the engine initialization phase.

Approved for 133.0b6

Attachment #9435775 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9435775 [details]
Bug 1929491 - try another state machine if any error happens during the engine initialization phase.

Approved for 132.0.2.

Attachment #9435775 - Flags: approval-mozilla-release? → approval-mozilla-release+

Should we cover this with manual verification? Would it be sufficient to do a spot check on Netflix on different OS-es, like we did for bug 1928798?

Flags: needinfo?(alwu)

As we don't have a specific way to verify the fix, doing testing like what you did before for bug 1928798 should be enough, 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: