Closed Bug 1770407 Opened 4 months ago Closed 4 months ago

VAAPI: Massive glitches with iHD

Categories

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

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
102 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox100 --- unaffected
firefox101 --- unaffected
firefox102 --- fixed

People

(Reporter: jan, Assigned: stransky)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: correctness, nightly-community, regression)

Attachments

(5 files, 1 obsolete file)

Attached video 2022-05-20_14-05-46.mp4

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

Flags: needinfo?(stransky)
Attached file aboutsupport.txt
Has Regression Range: --- → yes
Attached file bug1770407.txt

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.

Assignee: nobody → stransky
Flags: needinfo?(stransky)

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.

Duplicate of this bug: 1770554

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.

Depends on: 1770560
Summary: VAAPI: Massive H264 glitches with iHD on Macbook Pro → VAAPI: Massive glitches with iHD

Looks like a variant of Bug 1721617.

Priority: -- → P1
See Also: → 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.

Attachment #9277907 - Attachment is obsolete: true

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.

(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).

Pushed by stransky@redhat.com:
https://hg.mozilla.org/integration/autoland/rev/31e79de8266b
[Linux] Use MESA_platform_surfaceless GL backed on Linux instead of GBM one r=jgilbert
https://hg.mozilla.org/integration/autoland/rev/23a716a8b079
[Linux] Remove GBM GL backend r=jgilbert
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
Blocks: 1770520

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

Status: RESOLVED → VERIFIED
Blocks: 1751363

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.

Regressions: 1771861
Regressions: 1771898
Regressions: 1773377
See Also: → 1776563
See Also: → 1729233
You need to log in before you can comment on or make changes to this bug.