1858904 - Video is green when decoding vp9 with spatial layers with hw codec through VAAPI

Status: NEW

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

Description

[LaurentS]

Attachment: 2023-10-06_10-33.png

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

Steps to reproduce:

Using https://meet.jit.si:

1. Start a call with firefox (it does not seem to matter whether it's started here or not)
2. Join the same call with chrome/chromium and share video (not screen, just the webcam). So far, so good.
3. Join the same call as a third participant (I used my android phone)
4. See the green faces in firefox for the participant that use chrome/chromium
5. Participants using other clients seem to work fine (tested with firefox 118 and android jitsi app 23.4.0, both work fine)
6. If android participant drops out, the video reverts to normal colours after a few seconds.
7. if android participant joins in again, chromium user becomes green again almost immediately

The video codec reported by jitsi is VP9.
The bug only happens with media.hardware-video-decoding.enabled=true.

See original bug report with screenshot here: https://github.com/jitsi/jitsi-meet/issues/13918 where developers suggested I file a bug here.

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

This is FF 118 running on debian/sid (debian package). The same bug has been observed with FF 117 as well.

Actual results:

Video streams received in FF appear green (see screenshot attached. The blue rectangles are later additions for privacy)

Expected results:

Video streams should look "normal"

Comment 1

[Andreas Pehrson [:pehrsons]]

I have seen several reports of this related to jitsi (which probably one of the only services doing vp9 right now). Note this is webrtc but it's using a MediaDataDecoder to do hw decoding on linux, so I presume it's a FFmpegVideoDecoder with VAAPI.

Could be related to bug 1832276, but I'm not sure whether SVC is used here.

Comment 2

[jaya.allamsetty]

What happens in the step 6 above is that when there are only 2 participants in the call, the clients switch over to the direct p2p media connection and Chrome is forced to start encoding in VP8 instead of VP9. Therefore the issue doesn't reproduce anymore.
Only when there are 3 participants in the call, the media is routed through the Jitsi bridge and the client forces the Chromium endpoints to encode video in VP9 K-SVC mode.

Comment 3

[Andreas Pehrson [:pehrsons]]

By default we'll now use libvpx which should decode SVC fine, but we can keep this for tracking hw decode via VAAPI.