Debian Testing, Gnome Wayland, Macbook Pro
iHD: intel-media-va-driver-non-free:amd64 22.4.0+ds1-1
Mesa: 21.3.8-1

$ vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.4.0 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileNone                   :	VAEntrypointStats
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointFEI
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointFEI
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointFEI
      VAProfileVP8Version0_3          :	VAEntrypointVLD

Running sudo intel_gpu_top in parallel to confirm that VAAPI is used:

MOZ_ENABLE_WAYLAND=1 MOZ_DISABLE_RDD_SANDBOX=1 mozregression --good 2022-01-01 --bad c1ef18d0a27e --pref media.ffmpeg.vaapi.enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605

10:58.84 INFO: Last good revision: 1b7f9123f9c3385e7b7257db60a72eeeab565989
10:58.84 INFO: First bad revision: c1ef18d0a27ec4c2736cbb2c8ae8b061bd728f2e
10:58.84 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1b7f9123f9c3385e7b7257db60a72eeeab565989&tochange=c1ef18d0a27ec4c2736cbb2c8ae8b061bd728f2e

c1ef18d0a27ec4c2736cbb2c8ae8b061bd728f2e stransky — Bug 1769499 [Linux/EGL] Create GBM based surface for headless GL context r=jgilbert

Screencast:
MOZ_ENABLE_WAYLAND=1 MOZ_DISABLE_RDD_SANDBOX=1 mozregression --launch c1ef18d0a27e --pref media.ffmpeg.vaapi.enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -a about:support

MOZ_LOG="Dmabuf:5,PlatformDecoderModule:5" MOZ_ENABLE_WAYLAND=1 MOZ_DISABLE_RDD_SANDBOX=1 mozregression --launch c1ef18d0a27e --pref media.ffmpeg.vaapi.enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -P stdout > bug1770407.txt

$ dpkg -l | grep libavcodec
ii libavcodec-extra58:amd64 7:4.4.2-1

Mesa Intel(R) Iris(R) Graphics 6100

That's pretty new one, right? I'll test on my XPS 15 with HD 630.

MacBook Pro (Retina, 13-inch, Early 2015) according to https://checkcoverage.apple.com/us/en/
It supports VP8 + H264.

(In reply to Darkspirit from comment #5)

MacBook Pro (Retina, 13-inch, Early 2015) according to https://checkcoverage.apple.com/us/en/
It supports VP8 + H264.

Oh sure, I misread VAProfileVC1Main as AV1 :-)

Yes, I can reproduce that on Intel too.

I have this with VP9 on an XPS 15 with Mesa Intel(R) UHD Graphics (CML GT2).

As a wild guess, it looks like the GPU is decoding truncated frames, so it might be there's some missing fencing/synchronization and the GPU tries to read the encoded frames before they're properly transferred, or missing cache invalidation.

Have same issue on Tigerlake IrisXE, X11. The glitches disappear if i recompile mozilla-central with D146555 (https://phabricator.services.mozilla.com/D146555) reverted.

There seem to be some video on YouTube with no artifacts. No idea what information from the debug information (right click in the YouTube player) shows the format.

That goes the same direction as Bug 1699433, i.e. multi-thread access to libdri.

Looks like a variant of Bug 1721617.

With Bug 1769499 we create GBM GL headless backend on RDD process. There's no point to create EGLImage/texture
over it as we use a different GL backend for image frames rendering.

Visually same glitches happening on Intel HD Graphics 530 (rev 06) with "vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 2.4.1" driver (with intel hybrid codec driver for vp9 vaapi support) for h264 and for vp9.
Sometimes a crash like https://crash-stats.mozilla.org/report/index/f1a36db3-c380-427c-94f2-4e0ec0220525 happens and the glitches disappear, probably because it switches to software decoding in that moment.

Compiled without abandoned patch D147154 - glitches are back again. Applied patch back - no glitches.

https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/94 indicates that EGL_PLATFORM_SURFACELESS_MESA will definitely not work on Nvidia.
At least they support Gbm since 495, but we should test nvidia-vaapi-driver with that, too.

MESA_platform_surfaceless provides better alternative to GBM GL backend so let's use that instead of GBM.

Depends on D147420

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=574cfad0a033974dff516fe8eff6af90691d83fe

(In reply to Darkspirit from comment #17)

https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/94 indicates that EGL_PLATFORM_SURFACELESS_MESA will definitely not work on Nvidia.
At least they support Gbm since 495, but we should test nvidia-vaapi-driver with that, too.

On the other hand, it might motivate Nvidia to support VAAPI properly via Mesa which would serve users best.
At the moment, CUDA forces a higher power state, hw decoding apparently needs more power than software decoding:
https://github.com/elFarto/nvidia-vaapi-driver/issues/74#issuecomment-1100918826

mesa/d3d12 in WSL2 supports EGL_MESA_platform_surfaceless and H264 VAAPI:
https://bug1770538.bmoattachments.org/attachment.cgi?id=9277868
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16286

(In reply to Darkspirit from comment #21)

(In reply to Darkspirit from comment #17)

https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/94 indicates that EGL_PLATFORM_SURFACELESS_MESA will definitely not work on Nvidia.
At least they support Gbm since 495, but we should test nvidia-vaapi-driver with that, too.

I think that's something different and unrelated. For instance I see EGL_MESA_platform_surfaceless extension available on my NVIDIA laptop with binary drivers.

The issue above is about sharing dmabuf between different devices (Intel & NVIDIA) but Firefox doesn't do that or we can exclude such scenario by EGL_MESA_image_dma_buf_export extension (i.e. don't create dmabuf memory directly by GBM but import it from GL).

For instance we may use the same device to decode va-api video and take a snapshot of it (if va-api is even supported on NVIDIA).

https://hg.mozilla.org/mozilla-central/rev/31e79de8266b
https://hg.mozilla.org/mozilla-central/rev/23a716a8b079

Glitches are gone and MOZ_DISABLE_RDD_SANDBOX=1 is no longer needed. Thanks!

https://www.reddit.com/r/firefox/comments/v0esaq/comment/iakwkez/

Seems to work, but now the DRI_PRIME flag seems to be broken. Two steps forward, one backwards.

might be
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3987

DRI_PRIME env var on EGL Surfaceless platform is ineffective

(In reply to Darkspirit from comment #26)

https://www.reddit.com/r/firefox/comments/v0esaq/comment/iakwkez/

Seems to work, but now the DRI_PRIME flag seems to be broken. Two steps forward, one backwards.

might be
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3987

DRI_PRIME env var on EGL Surfaceless platform is ineffective

Please file a new bug for it. I don't understand how it affects Firefox - EGL Surfaceless platform is used to show va-api decoded pictures in snapshots so I don't understand how it matters here.

https://www.reddit.com/r/firefox/comments/v0esaq/comment/iakwkez/

I filed a but for it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1771861