Perfherder has detected a talos performance regression from push 84872badd1c1cb0aefeccfa995074f4b902359ab. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

https://searchfox.org/mozilla-central/source/testing/talos/talos/tests/webgl/benchmarks/video/video_upload.html

video.src = "../../../video/clips/testsrc.1080p.60fps.mp4";

This test only tests H264.

• bug 1744037 moved H264 FFMPEG into the RDD process by enabling media.rdd-ffmpeg.enabled.
• VP8+VP9 FFMPEG is already in the RDD process (media.rdd-ffvpx.enabled: Nightly=bug 1595994, Stable=bug 1681228).
  A VP9 video is also available in the folder, but it's only tested by another test: https://searchfox.org/mozilla-central/source/testing/talos/talos/tests/video/video_playback.html
• Therefore, comment 0 seems to have revealed an existing regression already affecting VP8+VP9.

HW WebRender (not llvmpipe HW WR) should profit from Dmabuf WebGL and media.ffmpeg.dmabuf-textures once the CI's Mesa version qualifies for MOZ_X11_EGL: bug 1725245, bug 1744060

bug 1595994 (VP8+VP9) and bug 1744037 (H264) are

• desired for security (bug 1678233) and
• required for VAAPI hardware video decoding, which is still experimental, disabled and not tested by CI, but increasingly becoming mature.

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

Kelsey, this appears to affect video in WebGL/a test from you. Do you happen to have an idea why decoding in RDD is so much slower for this use case? Do we make an additional copy now?