User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

1. Open YouTube video
2. Click play button

Actual results:

Video did not play and instead threw an error message

Expected results:

Video should play normally

Should be noted that the crash happened in latest Firefox Nightly (91.0a1, 2021-06-15), but I sent this bug report with Firefox 89

Is this behavior consistent? And does it occur with release (currently 89) and beta, or just Nightly?

If it is consistent, and just Nightly, could you try using mozregression to pinpoint when this behavior changed?

Yup, it happened on Nightly (no problem with release and beta), here the mozregression result:

12:10.11 INFO: No more integration revisions, bisection finished.
12:10.11 INFO: Last good revision: 5e5c1c7e7db0d6e996ccbf56a9aa8e445bc099eb
12:10.11 INFO: First bad revision: 97fb4c742d684da863aa27a32ae9d1daa8d67928
12:10.11 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e5c1c7e7db0d6e996ccbf56a9aa8e445bc099eb&tochange=97fb4c742d684da863aa27a32ae9d1daa8d67928```

Modified about:config preferences (to enable VAAPI acceleration):

media.ffmpeg.vaapi.enabled set to true
media.ffvpx.enabled set to false
media.rdd-vpx.enabled set to false
security.sandbox.content.level set to 0
gfx.x11-egl.force-enabled set to true

It looks like https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e5c1c7e7db0d6e996ccbf56a9aa8e445bc099eb&tochange=97fb4c742d684da863aa27a32ae9d1daa8d67928 was your change, Alastor. Can you take a look?

The current workaround is to set media.ffmpeg.vaapi.enabled=false.

H264 is a bit tricky here as it needs extra frames for reorder. We already allocate extra frames for it but it's not a problem to increase the extra frames number. As you see there's 24 h264 frames allocated on the start and it depends how fast the rendering pipeline can release it.

We also can release the frames early and re-use them more agressivelly.

(In reply to Anan Laks from comment #3)

Yup, it happened on Nightly (no problem with release and beta), here the mozregression result:

12:10.11 INFO: No more integration revisions, bisection finished.
12:10.11 INFO: Last good revision: 5e5c1c7e7db0d6e996ccbf56a9aa8e445bc099eb
12:10.11 INFO: First bad revision: 97fb4c742d684da863aa27a32ae9d1daa8d67928
12:10.11 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e5c1c7e7db0d6e996ccbf56a9aa8e445bc099eb&tochange=97fb4c742d684da863aa27a32ae9d1daa8d67928

Same regression range as bug 1716689.

Set release status flags based on info from the regressing bug 1692881

Err, sorry, wrong bug.

Looks like it is fixed by bug 1717119

We still want to increase the amount of frames that ffmpeg stores for h264, like what comment9 said.

As the same failure also happens on vp8, I decided to fix this issue in bug 1718309 by not storing frames aggressively if HW decoding is enabled.