Closed Bug 1660195 Opened 4 years ago Closed 4 years ago

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

Categories

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

Firefox 81
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: pmenzel+bugzilla.mozilla.org, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.

Summary: WebRTC decoding → WebRTC hardware accelerated decoding does not seem to work

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)
[…]
$ 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

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

Component: Untriaged → WebRTC
Product: Firefox → Core
Component: WebRTC → Audio/Video: Playback
Summary: WebRTC hardware accelerated decoding does not seem to work → [Linux] WebRTC hardware accelerated decoding does not seem to work

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.) :/

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.

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

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

[…]

Severity: -- → S3
Priority: -- → P5

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

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.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: