Closed Bug 1676115 Opened 4 years ago Closed 3 years ago

Fan starts spinning doing a BigBlueButton video conference

Categories

(Core :: Audio/Video, defect, P3)

Product:
Core
Component:
Audio/Video
Version:
Firefox 84
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

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

References

(Blocks 1 open bug)

Details

(Keywords: power)

Attachments

(1 file)

Output of `about:support`
29.95 KB, text/plain
Details

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

Steps to reproduce:

On an Intel Broadwell laptop Dell Latitude E7250 with Debian Sid/unstable with GNOME 3.38.1 with X.Org X Server (not Wayland) and VA-API enabled (MOZ_X11_EGL=1 MOZ_LOG="PlatformDecoderModule:1" nightly), doing a video conference using BigBlueButton with ten people, where six (including myself) have their camera enabled.

$ lspci -nn -s 00:02
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)

Actual results:

The fan starts spinning pretty quicky, and about:performance shows, that the tab with BigBlueButton uses a lot of resources.

VP8 is the codec, which the Intel GPU in this laptop supports.

sudo intel_gpu_top shows that Render/3D/0 is 80 to 90 % used.

Media profile: https://share.firefox.dev/32nJFfy

(During profiling at the beginning the other video streams were frozen and in the end my own stream (and camera) was disabled (maybe by BBB).

Expected results:

Due to hardware acceleration being used, the fan should not start spinning.

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

Component: Untriaged → Audio/Video
Product: Firefox → Core

It seems it's a VA-API issue. Martin, would you mind having a look?

Blocks: egl-linux-vaapi
Severity: -- → S4
Flags: needinfo?(stransky)
Priority: -- → P3
See Also: → 1668735

"Render/3D/0" is WebRender.
"Video/0" is VAAPI: Is it used at all? Does additionally setting media.rdd-vpx.enabled to false help? Then it's a duplicate of bug 1673184.

Keywords: power
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

You are right, Video/0 is 0, and setting media.rdd-vpx.enabled to false does not change it.

Testing a YouTube video with h264ify it works as expected (also according to MOZ_LOG="PlatformDecoderModule:5"), and Video/0 is around 1.5 %.

For BigBlueButton with log level five (MOZ_LOG="PlatformDecoderModule:5") and setting media.rdd-vpx.enabled = true Nightly logs:

[Child 51379: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[Child 51379: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type
[Child 51379: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[Child 51379: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type
[Child 51379, MediaDecoderStateMachine #1] WARNING: Decoder=7f744965f000 state=DECODING_METADATA Decode metadata failed, shutting down decoder: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:376
[Child 51379, MediaDecoderStateMachine #1] WARNING: Decoder=7f744965f000 Decode error: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006): file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:3471
[Child 51379: MediaPDecoder #1]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[RDD 51846: MediaSupervisor #1]: D/PlatformDecoderModule Agnostic decoder supports requested type
[RDD 51846: MediaSupervisor #1]: D/PlatformDecoderModule Agnostic decoder supports requested type

and with with setting media.rdd-vpx.enabled = false Nightly logs:

[Child 50435: MediaPDecoder #1]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[RDD 50837: MediaSupervisor #1]: D/PlatformDecoderModule Agnostic decoder supports requested type
[RDD 50837: MediaSupervisor #1]: D/PlatformDecoderModule Agnostic decoder supports requested type

In about:webrtc Lokales SDP (Offerte) shows:

[…]
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=ssrc:2463089004 cname:{3593d16d-5998-4eb5-889d-c2bd61123e15}

No idea, how I can check, what codec is actually used.

Oh, I mixed something up, that YouTube and h264ify of course uses H264 and not VP8. Please ignore that part.

The fan starts spinning pretty quicky, and about:performance shows, that the tab with BigBlueButton uses a lot of resources.

I expect main resource usage is encoding to VP8 which is not supported by va-api implementation in Firefox yet. We support only vp8 decoding/playback which is a minor load during the videocall.

Flags: needinfo?(stransky)

For instance on my laptop (dell xps 15 with 6 cores) non-accelerated video playback uses 6% cpu but video chat / encoding eats 20% cpu.

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

The fan starts spinning pretty quicky, and about:performance shows, that the tab with BigBlueButton uses a lot of resources.

I expect main resource usage is encoding to VP8 which is not supported by va-api implementation in Firefox yet. We support only vp8 decoding/playback which is a minor load during the videocall.

I can test that theory today, by not enabling my camera.

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

For instance on my laptop (dell xps 15 with 6 cores) non-accelerated video playback uses 6% cpu but video chat / encoding eats 20% cpu.

But that load shouldn’t cause the fan to start spinning, right? Please note, that I receive six VP8 encoded video streams.

Martin, maybe not the reason for the spinning fan, but shouldn’t at least sudo intel_gpu_top show that the GPU is used for VP8 decoding?

Also, I noticed something else:

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

But playing the VP8 encoded test file 1 neither Nightly nor mpv 2 use the GPU for that (checked with sudo intel_gpu_top).

Nightly log:

[Child 9835: MediaSupervisor #7]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[RDD 10202: MediaSupervisor #2]: D/PlatformDecoderModule Agnostic decoder supports requested type
[RDD 10202: MediaSupervisor #2]: D/PlatformDecoderModule Agnostic decoder supports requested type

Output of mpv:

$ mpv --vo=gpu --hwdec=vaapi VP8_low_bitrate_test_ToS.webm 
 (+) Video --vid=1 (*) (vp8 960x400 25.000fps)
VO: [gpu] 960x400 yuv420p
V: 00:00:22 / 00:00:33 (66%)

(In reply to Paul Menzel from comment #10)

But that load shouldn’t cause the fan to start spinning, right? Please note, that I receive six VP8 encoded video streams.

You receive only one stream as the video is composed/encoded on server side.

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

(In reply to Paul Menzel from comment #10)

But that load shouldn’t cause the fan to start spinning, right? Please note, that I receive six VP8 encoded video streams.

You receive only one stream as the video is composed/encoded on server side.

To my knowledge, BigBlueButton uses a Stream Forwarding Unit (SFU), so nothing is composed/encoded on the server side.

Indeed VP8 encoding seems to have a big influence. The fan only started spinning when profiling (https://share.firefox.dev/3pHmWFb). Though the conference wasn’t very long this time.

Should I create a separate bug for the VP8 issue?

Note: if you want to va-api for WebRTC video decoding you need to set media.navigator.mediadatadecoder_vpx_enabled to true at about:config.

Note: if you want to va-api for WebRTC video decoding you need to set media.navigator.mediadatadecoder_vpx_enabled to true at about:config.

Yes, that is set (and the default).

Since some versions (at least with 98.0a1 (20220122214838)) VP8 video decoding uses the GPU over VA-API just fine. (Unfortunately, no VP8 encoding is supported by Intel Corporation HD Graphics 5500 [8086:1616] (rev 09), but H264 is, so that might be the better default to support more devices, so they can be used longer (also battery), so more sustainable and environment friendly.)

I close the issue as WORKSFORME.

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

Attachment

General

Creator:
Created:
Updated:
Size: