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

Steps to reproduce:

Try to use hardware accelerated WebRTC VP8 decode.

Actual results:

The fan started spinning (bug #1660195).

Expected results:

It’d be great if libvpx shipped by Firefox supported VA-API decode path.

From Martin’s article:

Mozilla binaries perform VP8/VP9 decoding by bundled libvpx library which is missing VA-API decode path. If your hardware supports it and you want to use VA-API for VP8/VP9 decoding, you need to disable bundled libvpx and force external ffmpeg. Go to about:config and set media.ffvpx.enabled to false. Fedora sets that by default when VA-API is enabled.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

AFAI understand libvpx is a pure software decoder and it doesn't make sense to "add VA-API" to it. What we actually want is for Firefox to try the external FFmpeg's hardware decoding first, then the internal libvpx (if enabled) and then the external FFmpeg's software decoding.

(In reply to Jan Alexander Steffens [:heftig] from comment #2)

AFAI understand libvpx is a pure software decoder and it doesn't make sense to "add VA-API" to it. What we actually want is for Firefox to try the external FFmpeg's hardware decoding first, then the internal libvpx (if enabled) and then the external FFmpeg's software decoding.

Only how it's used for video playback.
We have multiple copies unfortunately (one for webrtc, one for video playback (unused) and one for webp).

The one shipping with webrtc is used for encoding.

We're trying to remove the need for libvpx altogether

In any case, I will close this as won't fix.
With webrtc today, libvpx is used for encoding, ffvp8 is used for decoding and it can already be hardware decoded.

I think the confusion may come from the original blog entry that incorrectly refers to libvpx.

It's incorrect, we use ffvpx.

I do see an interest in shipping VA-API aware code with our own version of ffvpx on linux.

• Update in-tree ffvpx library with VP8/VP9 VAAPI HW decode code from FFmpeg 4.2.
• Enable VP8/VP9 VAAPI HW decode on MOZ_WAYLAND target.

Implemented DMABufSurfaceWrapper and VAAPIDisplayHolder as a versioned class templates
as they are going to be used by both system ffmpeg and bundled ffvpx decoders.

Depends on D90554

Depends on D90555

Depends on D90556

• Ship libva headers to allow build ffvpx with VA-API support
• Link libva runtime by library wrapper

Updated the patches with libva headers and run-time libva linker. It allows to build/run on systems without system libva library.
I know about the gfxPlatformGtk::GetPlaform() / RDD issue and I'd like to address that in a separate patch for both ffmpeg/ffvpx.
Thanks.

When https://phabricator.services.mozilla.com/D94650 is checked in we can remove runtime va* functions loading from FFmpegLibWrapper which may also help to address an issue with gfxPlatform in RDD process.

Backed out for causing build bustages in vaapi

Backout link: https://hg.mozilla.org/integration/autoland/rev/6af9cd7b395cde46d062ccf76713b74e8cf08038

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel%2Crunning%2Cpending%2Crunnable&revision=f53408903b5e1e6fb34bc6ac96bc239a3484bb82

Failure log: https://treeherder.mozilla.org/logviewer?job_id=320800064&repo=autoland&lineNumber=26061

"WARNING - /builds/worker/checkouts/gecko/media/ffvpx/config_unix64.h:235:9: warning: 'HAVE_VALGRIND_VALGRIND_H' macro redefined [-Wmacro-redefined]
[task 2020-11-05T08:13:40.759Z] 08:13:40 INFO - #define HAVE_VALGRIND_VALGRIND_H 0
[task 2020-11-05T08:13:40.759Z] 08:13:40 INFO - ^
[task 2020-11-05T08:13:40.759Z] 08:13:40 INFO - /builds/worker/workspace/obj-build/mozilla-config.h:106:9: note: previous definition is here
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - #define HAVE_VALGRIND_VALGRIND_H 1
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - ^
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - In file included from /builds/worker/checkouts/gecko/media/ffvpx/libavutil/hwcontext_vaapi.c:49:
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - /builds/worker/checkouts/gecko/media/ffvpx/libavutil/hwcontext_vaapi.h:22:10: fatal error: 'va/va.h' file not found
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - #include <va/va.h>
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - ^~~~~~~~~
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - 2 warnings and 1 error generated.
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - /builds/worker/checkouts/gecko/config/rules.mk:596: recipe for target 'hwcontext_vaapi.o' failed
[task 2020-11-05T08:13:40.760Z] 08:13:40 ERROR - make[4]: *** [hwcontext_vaapi.o] Error 1
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - make[4]: Leaving directory '/builds/worker/workspace/obj-build/media/ffvpx/libavutil'
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - make[4]: *** Waiting for unfinished jobs....
[task 2020-11-05T08:13:40.760Z] 08:13:40 INFO - make[4]: Entering directory '/builds/worker/workspace/obj-build/modules/libmar/tool'"

Thanks. We need libva 2.0 headers in build roots. Re-opened Bug 1665639 for it.

Backed out for bustages on hwcontext_vaapi.h.

Backout link: https://hg.mozilla.org/integration/autoland/rev/76ded4b3a6e09566992f314d430af03031ce0953

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&searchStr=linux%2Cx64%2Ctsan%2Cbuild-linux64-tsan%2Fopt%2Cbo&revision=1e094ee6647feb49a8912066373abd8f54e64a51&selectedTaskRun=ECfOeo9NTzOLSBDniCw2PA.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=320928723&repo=autoland&lineNumber=25438

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

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6c971de60382248e0eb497dbbfa9492e0d04940f

Wouldn't it be easier to swap order in which ffvpx- and ffmpeg-based decoders are registered? That will make Firefox prefer OS-provided ffmpeg for everything, including VP9.

(In reply to Rinat from comment #24)

Wouldn't it be easier to swap order in which ffvpx- and ffmpeg-based decoders are registered? That will make Firefox prefer OS-provided ffmpeg for everything, including VP9.

We still want to have bundled ffvpx with va-api support, especially for webrtc and distros without default system ffmpeg (fedora/suse...).

Backed out for media related failures

backout: https://hg.mozilla.org/integration/autoland/rev/0ecc51ff0cddf5ba357038b51d2cce52c2267972

push:

• https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=1aa6c9d65403b441c567ebda260f6b528060b492&selectedTaskRun=GxHjooWqRWyVocuTAFDCkw.0
• due to the failures only appearing on ^ after backfills, they were firstly spotted on https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=66841ce77403a398abccad8698b2ed352ffc3694

failure logs:

• TEST-UNEXPECTED-TIMEOUT | /webaudio/the-audio-api/the-mediastreamaudiosourcenode-interface/mediastreamaudiosourcenode-routing.html | MediaStreamAudioSourceNode captures the right track. - Test timed out
• TEST-UNEXPECTED-FAIL | dom/media/webaudio/test/test_audioContextParams_sampleRate.html | Error executing test: Error: Audio analysis timed out waitForAnalysisSuccess@http://mochi.test:8888/tests/dom/media/webaudio/test/head.js:203:26 ... @http://mochi.test:8888/tests/dom/media/webaudio/test/test_audioContextParams_sampleRate.html:32:20 ... runTestWhenReady/<@http://mochi.test:8888/tests/dom/media/webaudio/test/head.js:473:30 ...
• etc

Interesting. I did local builds on Ubuntu 18.04 and I don't see such errors there...will look at it.

Backed out for perma failures.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=3fe77cc9a39c046c0040a70b4f40f54295e44c01&failure_classification_id=2

Logs:
https://treeherder.mozilla.org/logviewer?job_id=322944552&repo=autoland&lineNumber=3655
https://treeherder.mozilla.org/logviewer?job_id=322944594&repo=autoland&lineNumber=27294
https://treeherder.mozilla.org/logviewer?job_id=322944616&repo=autoland&lineNumber=2047
https://treeherder.mozilla.org/logviewer?job_id=322944576&repo=autoland&lineNumber=19802
https://treeherder.mozilla.org/logviewer?job_id=322943165&repo=autoland&lineNumber=3376
https://treeherder.mozilla.org/logviewer?job_id=322944737&repo=autoland&lineNumber=3074
https://treeherder.mozilla.org/logviewer?job_id=322944746&repo=autoland&lineNumber=4410
https://treeherder.mozilla.org/logviewer?job_id=322944648&repo=autoland&lineNumber=2542
https://treeherder.mozilla.org/logviewer?job_id=322943385&repo=autoland&lineNumber=23888

Backout: https://hg.mozilla.org/integration/autoland/rev/c92eaf9c3f4692378e4782eb9a909715d50582b2

I was checking why some recent landings of patches broke try-comm-central task job, and saw this post by chance.

I have been using the following patch to avoid the macro redefinition error in my local build of C-C TB
for the last few years.

# HG changeset patch
# User ISHIKAWA, Chiaki <ishikawa@yk.rim.or.jp>
# Parent  270e38bde0892e4b8eff0afc3ffe07ed96a7a72f
Avoid conflict of HAVE_VALGRIND_VALGRIND_H definition with upper-level definition.

diff --git a/media/ffvpx/config_unix64.h b/media/ffvpx/config_unix64.h
--- a/media/ffvpx/config_unix64.h
+++ b/media/ffvpx/config_unix64.h
@@ -237,17 +237,17 @@
 #define HAVE_SYS_SELECT_H 1
 #define HAVE_SYS_SOUNDCARD_H 1
 #define HAVE_SYS_TIME_H 1
 #define HAVE_SYS_UN_H 1
 #define HAVE_SYS_VIDEOIO_H 0
 #define HAVE_TERMIOS_H 1
 #define HAVE_UDPLITE_H 0
 #define HAVE_UNISTD_H 1
-#define HAVE_VALGRIND_VALGRIND_H 0
+// avoid conflict: #define HAVE_VALGRIND_VALGRIND_H 0
 #define HAVE_WINDOWS_H 0
 #define HAVE_WINSOCK2_H 0
 #define HAVE_INTRINSICS_NEON 0
 #define HAVE_ATANF 1
 #define HAVE_ATAN2F 1
 #define HAVE_CBRT 1
 #define HAVE_CBRTF 1
 #define HAVE_COPYSIGN 1

(I enforce the "treat warning as errors" for local build and hit upon the redefinition error some years ago.)

Just FYI.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=77c04d96838092fe890499d8cc25473e1a355b23

https://hg.mozilla.org/mozilla-central/rev/708c5d069936
https://hg.mozilla.org/mozilla-central/rev/9d4893cc2f99

Reopened as three patches are missing:

D90554 Bug 1660336 Add VP8/VP9 VAAPI HW decode code to bundled ffvpx and build it with MOZ_WAYLAND target
D90556 Bug 1660336 Implement FFmpegLibWrapper::LinkVAAPILibs() to link VAAPI libraries
D90557 Bug 1660336 Build ffvpx FFmpegVideoDecoder module with VAAPI support, r?jya

Patches failed to land with message:
"Revisions: D90554 diff 373469 ← D90555 diff 372311 ← D90556 diff 372312 ← D90557 diff 373470

            Details: We're sorry, Lando could not rebase your commits for you automatically. Please manually rebase your commits and try again.

hg error in cmd: hg import --no-commit -s 95 /tmp/tmpagy1zcb1: applying /tmp/tmpagy1zcb1

patching file media/ffvpx/libavutil/moz.build
Hunk #2 FAILED at 62
1 out of 2 hunks FAILED -- saving rejects to file media/ffvpx/libavutil/moz.build.rej
patching file media/ffvpx/config_common.h
Hunk #1 FAILED at 18
1 out of 1 hunks FAILED -- saving rejects to file media/ffvpx/config_common.h.rej
abort: patch failed to apply"

Martin, please re-add the check-in needed tag after rebase.

I see, Thanks.

Backed out for causing build bustage on libmozavcodec.so

Backout link: https://hg.mozilla.org/integration/autoland/rev/ce9943ea7091d45f1cd835e8710dac2f437d1b7e

Push with failure; https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=13936ff79b4ca5d7b6cdb6dfa32e406952022c14&searchStr=linux%2Cx64%2Cdebug%2Cbuild-linux64-base-toolchains-clang%2Fdebug%2Cbbc&selectedTaskRun=TFV1LEzISbmuO7kEehwoTg.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=323553211&repo=autoland&lineNumber=80850

Hm, the error is on opt/debug Linux x64 build-linux64-base-toolchains-clang Bbc (seems to be clang 5?) which I'm not able to reproduce. The error is:

/builds/worker/fetches/clang/bin/ld.lld: error: can't create dynamic relocation R_X86_64_PC32 against symbol: ff_cos_32 in readonly segment
[task 2020-12-05T21:52:13.384Z] 21:52:13 INFO - >>> defined in fft_float.o
[task 2020-12-05T21:52:13.384Z] 21:52:13 INFO - >>> referenced by fft.asm:394 (/builds/worker/checkouts/gecko/media/ffvpx/libavcodec/x86/fft.asm:394)

Mike, can you help me understand what's going on and how I can reproduce it? Which distro is that? Can I reproduce it locally somehow?
Thanks.

My try also shows that bug

https://treeherder.mozilla.org/jobs?repo=try&revision=fb090bb90faf810dd0b080db50c20c5b716bf6f2&selectedTaskRun=HHpVhUIIQ2aaseOEHdopTQ.0

although I don't understand how is that related to this bug.

Looks like it's caused by c++/c code linking together, when I move mozva.cpp to mozva.c the test passes.

Try with the mozva.c :
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8bfec4c88726edff93149a4e9ebc493165fad684
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6caec43d0c9b781db14cfd99a8976859e6d56c22

Depends on D90555

https://hg.mozilla.org/mozilla-central/rev/321cbfd8cbb8
https://hg.mozilla.org/mozilla-central/rev/84ea73688876
https://hg.mozilla.org/mozilla-central/rev/c5097975c9c6
https://hg.mozilla.org/mozilla-central/rev/adbd3858fa50

Hi,
Does that fix also fixes VAAPI HW decode for Flatpak Firefox ?
Thanks

(In reply to antistress from comment #49)

Hi,
Does that fix also fixes VAAPI HW decode for Flatpak Firefox ?
Thanks

It may fix VP8/9 VA-API playback in Flatpak if you have libva and other libraries (intel/amd drivers) installed.

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

Thanks !