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

It only seems to happen with people on Chrome/Linux

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

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

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.

Green color means uninitialized/unset dmabuf frame / pixels.

Can you still reproduce it?
Thanks.

@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?

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

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

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.

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?

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.

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.

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

Can you please try again?
Thanks.

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

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

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

I cannot reproduce the issue any longer.

Downstream bugs has some reproducers.

Closing per comment 19.