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

Steps to reproduce:

Archlinux. Wayland. Intel CPU 9900K. vaapi, driver i965.
File USER.JS has:
user_pref("widget.wayland-dmabuf-vaapi.enabled", true); user_pref("media.ffvpx.enabled", false);

MOZ_WEBRENDER=1 var is set.

Actual results:

After last update video is stuttering. Switching to software acceleration helps - video is getting smooth.

I see that too. I can reproduce it with VP9 format, h264 decodes ok. Looks like we don't release the frames properly and we're running out of free HW surfaces.

Because this crash would only happen when enabling vaapi, I would add S4 on it to remove it from untriaged queue.

On Windows current Google Chrome, when you type chrome://gpu with a intel hd 5500 gpu (latest drivers) you get the following:
VPx decoding is too slow on Intel Broadwell, Skylake, and CherryTrail: 616318
Applied Workarounds: disable_accelerated_vpx_decode
Accelerated VPx decoding is hanging on some videos.: 654111
Applied Workarounds: disable_accelerated_vpx_decode

Bugs linked are:
https://bugs.chromium.org/p/chromium/issues/detail?id=616318
https://bugs.chromium.org/p/chromium/issues/detail?id=654111

These doesn't appear on Google Chrome/Linux which most of people have access to so I thought I better share.

VAAPI HW surfaces are released at ReleaseUnusedVAAPIFrames() and we use DMABufSurface::IsUsed() flag
to detect unused surfaces. Then we call GetUnusedDMABufSurfaceWrapper() to get unused surfaces to
re-use them for decoding.

Because DMABufSurface::IsUsed() flag is updated asynchronously it may change
between ReleaseUnusedVAAPIFrames() and GetUnusedDMABufSurfaceWrapper() calls.

In that case GetUnusedDMABufSurfaceWrapper() may return unused but also unreleased surface
as it was marked as used in time of ReleaseUnusedVAAPIFrames() call.

In this patch explicitly release VAAPI data of any surface before we re-use it.
Also fail when we try to upload data to already used DMABufSurfaceYUV surface.

https://hg.mozilla.org/mozilla-central/rev/1ff4754fc874

It seems this bug has been successfully fixed in Nightly. I haven't noticed any problems so far. Much thanks!!
Can this be uplifted into the first VAAPI-on-X11 release? (Release is in two weeks)

80.0b6 with MOZ_X11_EGL=1, gfx.webrender.all=true, media.ffmpeg.vaapi.enabled=true, media.ffvpx.enabled=false:
At the moment, YouTube playback just stops after a few seconds with this error message:

An error occurred. Please try again later. (Playback ID: 9fFE0BPtdRSa9pqe)

Comment on attachment 9167853 [details]
Bug 1656436 [Linux/VAAPI] Release VAAPI surface data before we re-use them, r?jya

Beta/Release Uplift Approval Request

• User impact if declined: Broken va-api playback on Linux.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• 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): Clears/releases dmabuf surface before we use it again.
• String changes made/needed:

The bug mentions many prefs/env vars needing to be set to non-default values for this to happen. What's the actual status of this work at the moment, and the need to get it into 80?

I have no idea what I would have to write to convince you. So I just give it a try, sorry. :D

This is Linux, every Linux user already needs to change prefs (bug 1614523) so that Firefox doesn't perform bad by default (bug 1420712).
You've let slip through so many bugs release by release to convince me to help testing at some point a few years ago.
https://wiki.archlinux.org/index.php/Firefox#Hardware_video_acceleration

• They need WebRender: gfx.webrender.all=true. WebRender replaces previous OpenGL compositor (layers.acceleration.force-enabled). Shipping WebRender by default is blocked by a non-WebRender Gtk bug that can also occur with Basic (default), but more likely with OpenGL (bug 1656211/bug 1502519). Organic growth and more testing would be good.
• They need to launch Firefox with with MOZ_X11_EGL=1 env var. It will become default in the future (bug 788319). (In comparison, Wayland already uses EGL by default, but the Wayland backend itself is only default in Fedora's Firefox, but not yet in official Firefox (MOZ_ENABLE_WAYLAND=1 is required until bug 1543600).)
• media.ffmpeg.vaapi.enabled=true enables hardware video decoding.
• Optional: media.ffvpx.enabled=false means "use system ffmpeg". It allows to use hw video decoding for VP8/9 as well, otherwise it's just H264.

With it you can play back videos that you couldn't play before and, most importantly, save battery power.

Please focus on actual user need. (For example, also on bug 568384, and not on aspects of Pocket that users want to disable. ;) )
This has been a long requested killer feature: bug 1210726 (85 votes) + bug 1210727 (72 votes)
A 380 USD bounty was paid: https://www.bountysource.com/issues/55506502-meta-add-va-api-hardware-decoding-support-on-linux

It can bring some users back because it's so easy to enable VAAPI on Firefox. In comparison, Chromium requires manual patching.
Firefox 80 news coverage and community expectation:
https://www.reddit.com/r/linux/comments/hkyrxe/bug_1619523_implement_ffmpegvaapi_video_playback/ 221 votes
https://www.reddit.com/r/firefox/comments/hkz44q/linux_related_bug_x11_implement_ffmpegvaapi_video/
https://www.reddit.com/r/archlinux/comments/i0ireu/firefox_developer_edition_hardware_video/fzpojad/ 112 votes
https://twitter.com/phoronix/status/1279221927744344064 85 likes
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-80-VA-API-X11
https://news.ycombinator.com/item?id=23731262
https://www.golem.de/news/va-api-firefox-bringt-linux-hardwarebeschleunigung-auch-fuer-x11-2007-149476.html
https://www.edivaldobrito.com.br/firefox-80-tera-aceleracao-de-decodificacao-de-video-via-va-api-no-x11/
https://sempreupdate.com.br/firefox-80-tera-suporte-a-va-api-acceleration-no-x11/
https://ubunlog.com/firefox-80-contara-con-la-aceleracion-de-decodificacion-de-video-a-traves-de-va-api-en-x11/
https://www.root.cz/clanky/firefox-80-bude-podporovat-va-api-i-pro-x11-fujifilm-hovori-o-384tb-lto-paskach/
https://forum.manjaro.org/t/browsers-that-use-hardware-acceleration-for-videos/157177/16
https://twitter.com/AdamHalperin/status/1256826269360160768
https://twitter.com/damnromulans/status/1291231347000868868
https://twitter.com/mezz0_xx/status/1290062606795853825
https://twitter.com/michael__lass/status/1268268608502796288
https://twitter.com/aquasp1/status/1288217681414500353
https://twitter.com/AaronToponce/status/1288120342318206977

It would become somewhat awkward if Firefox 80 could not deliver this expectation and had bad product quality.
You have uplifted bug 1645671 comment 30 and have been informed beforehand (bug 1645671 comment 26) that this bug (bug 1645672) would need an uplift to Beta as well to become reliable and to prevent disappointment.

(In reply to Julien Cristau [:jcristau] from comment #14)

The bug mentions many prefs/env vars needing to be set to non-default values for this to happen. What's the actual status of this work at the moment, and the need to get it into 80?

This feature is widely used although it's not enabled by default due to Bug 1619585. If you don't take the patch we'd need to patch it on distros level which is extra maintenance and leaves mozilla binaries broken. Also the patch is pretty small and straightforward so I think it should be uplifted.

Update:
The issue at stable 79 ver still exists.

Tried firefox-nightly 81.0a1 64-bit with:
user_pref("gfx.webrender.all", true);
user_pref("widget.wayland-dmabuf-vaapi.enabled", true);
user_pref("media.ffvpx.enabled", false);

Result:
1440p_60fps (and lower) youtube video playing smoothly. But switching it to 2160p quality leads to stuttering.

Just in case to remind: Stable ver 78 was fine for 100% with 2160p.

Please don't reopen this bug unless you're still seeing it in an up-to-date nightly build.

As I said previously, I still see the stuttering of 2160p in up-to-date nightly build.
And I don't see it at 78.1 esr build.
What should I do?

(In reply to bulratee from comment #19)

As I said previously, I still see the stuttering of 2160p in up-to-date nightly build.
And I don't see it at 78.1 esr build.
What should I do?

79 is not nightly - it's stable :) And stable will not receive fixes for unstable features - and VAAPI support is still unstable. You will have to wait for 80/81 or use nightly or ask you distribution maintainers to backport fixes.

(In reply to bulratee from comment #17)

Tried firefox-nightly 81.0a1 64-bit with:

Oh sorry, didn't read that. If this was nightly from today or yesterday - then please reopen.

(In reply to bulratee from comment #17)

user_pref("widget.wayland-dmabuf-vaapi.enabled", true);

Mind that in FF 80 (IIRC) this changed to media.ffmpeg.vaapi.enabled. And I think you also need media.ffmpeg.dmabuf-textures.enabled now, not sure.

Mind that in FF 80 (IIRC) this changed to media.ffmpeg.vaapi.enabled. And I think you also need media.ffmpeg.dmabuf-textures.enabled now, not sure.

Works now!
Sorry for bothering you!

(In reply to bulratee from comment #17)

user_pref("widget.wayland-dmabuf-vaapi.enabled", true);

bug 1649120 renamed this pref to media.ffmpeg.vaapi.enabled.
It also enables media.ffmpeg.dmabuf-textures.enabled under the hood for improved upload of software-decoded video.

With nightly I am no longer seeing this bug, but it is still happening on beta (80.0b7). I think this is the only blocker to enabling VA-API on X11 on my system on beta, as the experience on nightly is very smooth now.

(In reply to Martin Stránský [:stransky] from comment #16)

(In reply to Julien Cristau [:jcristau] from comment #14)

The bug mentions many prefs/env vars needing to be set to non-default values for this to happen. What's the actual status of this work at the moment, and the need to get it into 80?

This feature is widely used although it's not enabled by default due to Bug 1619585. If you don't take the patch we'd need to patch it on distros level which is extra maintenance and leaves mozilla binaries broken. Also the patch is pretty small and straightforward so I think it should be uplifted.

Mozilla binaries don't enable this so I wouldn't call them broken. I'd rather avoid more churn for 80.

(In reply to Julien Cristau [:jcristau] from comment #26)

Mozilla binaries don't enable this so I wouldn't call them broken. I'd rather avoid more churn for 80.

Julien,

given the articles flying around:

https://www.phoronix.com/scan.php?page=news_item&px=Firefox-80-VA-API-X11
https://www.reddit.com/r/firefox/comments/i1w40h/vaapi_on_firefox_80_beta_for_x_not_wayland/

it would be a kind of footgun if Mozilla ships the broken binaries, especially when the patch is so small.
Please reconsider that.
Thanks.

I noticed a problem with 60fps youtube:
Firefox-81.0b6-1, Archlinux, i965 & iHD (I know iHD is not supported at the moment), Intel N4100 (Gemini lake) UHD Graphics 605
user_pref("gfx.webrender.all", true)
user_pref("media.ffvpx.enabled", false)
user_pref("media.ffmpeg.vaapi.enabled", true)

with 30fps up to 1080p (didn't try anything higher) it seems to work fine with the nightly, but as soon as I switch to 60fps according to the info panel of the youtube player the dropped frames just start rising and it crashes after a few seconds.

I can't tell if this was ever working before with this setup, didn't try before firefox-80

I'm still seeing subjectively similar stuttering and stream failures with VAAPI enabled under X11 on FF81 on Haswell desktop hardware. With VAAPI enabled, some Youtube h264 streams drop to black (with the Youtube spinning 'buffering' animation) irregularly before resuming, but they can also fail unpredictably with a generic Youtube 'something went wrong' error. The only way to recover from a failure is to reload the Youtube page.

This https://www.youtube.com/watch?v=DbEtuqqgWLA video reliably crashes within the first five minutes.

This problem does not manifest on Broadwell hardware. I don't have any bare-metal Linux installs on anything more modern to test against.

I'm unsure of the appropriate Bugzilla etiquette; should this bug be reopened or should I file a new one?

(In reply to ch-bugzilla from comment #32)

I'm still seeing subjectively similar stuttering and stream failures with VAAPI enabled under X11 on FF81 on Haswell desktop hardware. With VAAPI enabled, some Youtube h264 streams drop to black (with the Youtube spinning 'buffering' animation) irregularly before resuming, but they can also fail unpredictably with a generic Youtube 'something went wrong' error. The only way to recover from a failure is to reload the Youtube page.

This https://www.youtube.com/watch?v=DbEtuqqgWLA video reliably crashes within the first five minutes.

This problem does not manifest on Broadwell hardware. I don't have any bare-metal Linux installs on anything more modern to test against.

I'm unsure of the appropriate Bugzilla etiquette; should this bug be reopened or should I file a new one?

Please file a new one. What you describe looks like a problem with your particular va-api setup.
Thanks.

(In reply to tobias from comment #31)

I noticed a problem with 60fps youtube:
Firefox-81.0b6-1, Archlinux, i965 & iHD (I know iHD is not supported at the moment), Intel N4100 (Gemini lake) UHD Graphics 605
user_pref("gfx.webrender.all", true)
user_pref("media.ffvpx.enabled", false)
user_pref("media.ffmpeg.vaapi.enabled", true)

with 30fps up to 1080p (didn't try anything higher) it seems to work fine with the nightly, but as soon as I switch to 60fps according to the info panel of the youtube player the dropped frames just start rising and it crashes after a few seconds.

I can't tell if this was ever working before with this setup, didn't try before firefox-80

Please file a new va-api related bug for it.
Thanks.