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

Steps to reproduce:

Play this video: https://vimeo.com/channels/360vr/277503248

Actual results:

The playback is very laggy, on both Firefox 114 and a recent Firefox nightly (20230620094433).

Expected results:

The playback should be smooth.

This seems to be related to bug 1809026, however the video in that issue still plays back fine, without lag, so there's clearly something different with this video that's breaking the previous fix.

I've uploaded a profile of the issue on Firefox nightly: https://share.firefox.dev/3qMlGFR

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

btw. Looks like https://phabricator.services.mozilla.com/D167240 is broken somehow so we don't use fast path for dmabuf surfaces.

This doesn't look like a regression - https://www.youtube.com/watch?v=FWYzdJJVpIQ works as before.
Looks like this particular video ( https://vimeo.com/channels/360vr/277503248 ) is somehow broken SW rendering path is taken.

Looks like we're missing dmabuf upload path in ClientWebGLContext::TexImage().

It fails in BlitPreventReason() with format is not RGBA error.
Looks like a general error which is not VA-API specific, pi.format is LOCAL_GL_RGB.

It's not VA-API specific, I think it affects all other HW decode backends.

It fallbacks here:
https://searchfox.org/mozilla-central/rev/b6b8ff043e944a5e32ea63208d3ba7cb6b16191d/dom/canvas/TexUnpackBlob.cpp#695

https://phabricator.services.mozilla.com/D167159 fixes this one for me. But Bug 1769747 has more general approach.