1659054 - [Intel] WebRTC video decoding accelerated with VAAPI progressively turns green

Status: RESOLVED WORKSFORME

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

Description

[Francois Guerraz]

Attachment: vaapi-webrtc.png

On Google Meet at least, with VAAPI, the image starts normal and then progressively turns greener and greener until an i-frame comes in and the video resets to a fresh state.
It doesn't happen to all video streams...

Comment 1

[Francois Guerraz]

It only seems to happen with people on Chrome/Linux

Comment 2

[Martin Stránský [:stransky] (ni? me)]

(In reply to Francois Guerraz from comment #1)

It only seems to happen with people on Chrome/Linux

What do you mean Chrome? Isn't this bug about Firefox?

Comment 3

[Francois Guerraz]

I am talking about the third party whose video is turning green on my FF.

Comment 4

[Vincent Chernin]

I wonder if this issue has a similar root cause as bug #1671673.

Since they both seem to turn the to same colour (albeit via different causes). One difference is that bug #1671673 seems to be about turning solid green, and this issue is about getting a green hue.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Green color means uninitialized/unset dmabuf frame / pixels.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Can you still reproduce it?
Thanks.

Comment 7

[Francois Guerraz]

@stransky, as it has been a while, just to make sure I'm testing everything, what prefs need to be changed to enable vaapi on webrtc?

Comment 8

[Darkspirit]

Just media.ffmpeg.vaapi.enabled:true is enough for Mesa 21 (when not using blocklisted Intel DDX driver):
MOZ_LOG="PlatformDecoderModule:5" mozregression --launch 2021-12-07 --pref media.ffmpeg.vaapi.enabled:true -a https://meet.jit.si/ -P stdout

 3:14.78 INFO: b'[RDD 20949: MediaPDecoder #1]: D/PlatformDecoderModule VA-API Got one frame output with pts=12748981dts=158965000 duration=0 opaque=-9223372036854775808'
 3:14.78 INFO: b'[RDD 20949: MediaPDecoder #1]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: VAAPI releasing dmabuf surface UID = 50'
 3:14.78 INFO: b'[RDD 20949: MediaPDecoder #1]: D/PlatformDecoderModule Reusing VA-API DMABufSurface UID = 50'
 3:14.78 INFO: b'[RDD 20949: MediaPDecoder #1]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: VAAPI locking dmabuf surface UID = 50'
 3:14.78 INFO: b'[RDD 20949: MediaPDecoder #1]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: VAAPI releasing dmabuf surface UID = 52'
 3:16.92 INFO: b'[vp8 @ 0x7f9485c0e100] Param buffer (type 0, 112 bytes) is 0x13fb.'
 3:16.93 INFO: b'[vp8 @ 0x7f9485c0e100] Param buffer (type 13, 1072 bytes) is 0x13fc.'
 3:16.93 INFO: b'[vp8 @ 0x7f9485c0e100] Param buffer (type 1, 64 bytes) is 0x13fd.'
 3:16.93 INFO: b'[vp8 @ 0x7f9485c0e100] Slice 0 param buffer (72 bytes) is 0x13fe.'
 3:16.93 INFO: b'[vp8 @ 0x7f9485c0e100] Slice 0 data buffer (939 bytes) is 0x13ff.'
 3:16.93 INFO: b'[vp8 @ 0x7f9485c0e100] Decode to surface 0x9.'
 3:16.93 INFO: b'[RDD 20949: MediaPDecoder #2]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: VAAPI releasing dmabuf surface UID = 51'
 3:16.93 INFO: b'[RDD 20949: MediaPDecoder #2]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: VAAPI releasing dmabuf surface UID = 52'
 3:16.93 INFO: b'[RDD 20949: MediaPDecoder #2]: D/PlatformDecoderModule VA-API Got one frame output with pts=12942391dts=161112000 duration=0 opaque=-9223372036854775808'

For older Mesa:
MOZ_LOG="PlatformDecoderModule:5" mozregression --launch 2021-12-07 --pref gfx.x11-egl.force-enabled:true gfx.webrender.all:true media.ffmpeg.vaapi.enabled:true -a https://meet.jit.si/ -P stdout

Comment 9

[Martin Stránský [:stransky] (ni? me)]

You need to set media.navigator.mediadatadecoder_vpx_enabled and media.ffmpeg.vaapi.enabled .

Comment 10

[Francois Guerraz]

Attachment: Screenshot from 2021-12-10 08-15-52.png

I almost declared victory yesterday after one day of testing, but this morning, I've been able to reproduce it again.

The situation seems to be improved somehow; this time it only happened once in one video call, then it fixed itself. Previously it would keep on happening.

Comment 11

[Darkspirit]

When looking at the log (MOZ_LOG="PlatformDecoderModule:5"), Is Nightly still using VAAPI in this case or is it using the software decoder with dmabuf textures?

Comment 12

[Francois Guerraz]

I didn't run it with the logs (will do next week) but checking with intel_gpu_top, the GPU video decoder was used, therefore it was using VAAPI.

Comment 13

[Francois Guerraz]

I think I found a way to reproduce the issue reliably. All you need is contention for CPU resources, like starting a significant compile job on all cores.

Comment 14

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Can you please try again?
Thanks.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2100658

Comment 17

[Martin Stránský [:stransky] (ni? me)]

From my experience WebRTC uses VP8 codec so may be a bug there.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

We may block VP8 / Intel but I need more info here.

Comment 19

[Francois Guerraz]

I cannot reproduce the issue any longer.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Downstream bugs has some reproducers.

Comment 21

[Martin Stránský [:stransky] (ni? me)]

Closing per comment 19.