1660195 - [Linux] WebRTC hardware accelerated decoding does not seem to work

Status: RESOLVED INVALID

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

Description

[Paul Menzel]

Attachment: nightly-webrtc-moz_platformdecodermodule_5.txt

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

Steps to reproduce:

[Maybe related to https://bugzilla.mozilla.org/show_bug.cgi?id=969395]

Using Nightly from today, I started it with

MOZ_X11_EGL=1 MOZ_WEBRENDER=1 MOZ_LOG=PlatformDecoderModule:5 nightly

and set media.ffmpeg.low-latency.enabled to true.

Then I joined a BigBlueButton conference with seven participants.

Actual results:

The fan started spinning, and it looks like the VP8 videos are not decoded using the Intel IGD.

Expected results:

The fan shouldn’t spin, when hardware acceleration for VP8 decoding is used.

Comment 1

[Paul Menzel]

Maybe also related to https://bugzilla.mozilla.org/show_bug.cgi?id=1646329.

Comment 2

[Paul Menzel]

The system is an Intel Broadwell Dell Latitude E7250 with the devices below:

$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)
00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09)
00:04.0 Signal processing controller [1180]: Intel Corporation Broadwell-U Processor Thermal Subsystem [8086:1603] (rev 09)
[…]

Comment 3

[Paul Menzel]

$ vainfo
libva info: VA-API version 1.8.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.8 (libva 2.8.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 20.2.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

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[Robert Mader [:rmader]]

You can check if hardware video decoding is used by running intel_gpu_top - that being said, there can be other areas that are very cpu intensive, like video encoding (not hardware accelerated yet) or generally webrender not yet being very efficient in that case (frame build etc.) :/

Comment 6

[Darkspirit]

Just to be sure: The following preferences are set, right?
media.ffmpeg.vaapi.enabled=true
media.ffvpx.enabled=false

Firefox/79.0

Have you tested this with 79 (outdated Nightly)? It was implemented with Nightly 81.

Comment 7

[Paul Menzel]

(In reply to Darkspirit, Servo QA from comment #6)

Just to be sure: The following preferences are set, right?
media.ffmpeg.vaapi.enabled=true

That is set.

media.ffvpx.enabled=false

No, I have it on true. :/ Sorry for missing that in Martin’s post.

Firefox/79.0

Have you tested this with 79 (outdated Nightly)? It was implemented with Nightly 81.

My Bugzilla credentials are stored in “Debian’s Firefox”, which I used to report the bug. I did test with Nightly.

Comment 8

[Paul Menzel]

(In reply to Paul Menzel from comment #7)

(In reply to Darkspirit, Servo QA from comment #6)

Just to be sure: The following preferences are set, right?
media.ffmpeg.vaapi.enabled=true

That is set.

media.ffvpx.enabled=false

No, I have it on true. :/ Sorry for missing that in Martin’s post.

I created bug #1660336, that Firefox’ libvpx supports the VA-API decode path for VP8/VP9.

[…]

Comment 9

[Darkspirit]

(In reply to Paul Menzel from comment #8)

media.ffvpx.enabled=false

No, I have it on true. :/ Sorry for missing that in [Martin’s post][1].

Easy to miss, thanks for filing bug 1660336! Can you confirm that WebRTC VAAPI decoding works with that pref set to false? (Can this bug be closed as invalid?)

Comment 10

[Paul Menzel]

I was able to verify that it worked today with media.ffvpx.enabled=false. (The fan still spun though with 8 WebRTC streams in BigBlueButton, but that is expected on an Intel Broadwell system i7-5600U.