1520200 - web.ciscospark.com sometimes displays a zoomed-in upper-left corner of the video feed

Status: VERIFIED FIXED

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

Description

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Note

• Must have two accounts on the http://web.ciscospark.com/.
• This issue has occured on Ubuntu 16.04 LTS.
• The affected OS's have the following GPU: Intel(R) HD Graphics 5500

Affected versions

• Fx 65.0b10
• Fx 66.0a1

Affected platforms

• Fx 65.0b10 and Fx 66.0a1(web app) Ubuntu 16.04 LTS (affected) and Fx 64.0.2 macOS 10.14
• Fx 65.0b10 and Fx 66.0a1(web app) Windows 7 x64 (affected) and native app Windows 10 x64.
• Fx 65.0b10 and Fx 66.0a1(web app) Windows 7 x64 (affected) and native app macOS 10.14 (it occurred for a few seconds).
• Fx 65.0b10 and Fx 66.0a1(web app) Windows 7 x64 (affected) and web app macOS 10.14 (it occurred for a few seconds).

Steps to reproduce

1. Launch Firefox.
2. Go to http://web.ciscospark.com/ and log in.
3. Initiate a call.

Expected result

• The call has no audio/video issues.

Actual result

• As soon as the call is initiated, the native app notices a flicker in the video then the video displayed is a zoom in in the upper-left corner.

Regression range

• Will investigate as soon as possible.

Additional notes

• Image with the zoomed in video feed: https://imgur.com/a/OffUNjY

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks Cristian, does it work in 64? If not, what makes you suspect a browser bug?

You mention "native app", does this only happen on calls between firefox and a native app? Is the abnormal video observed on the Firefox side or the native app side? Does it work better using Chrome?

A regression range would help of course.

Comment 2

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

We managed to reproduce it again using:

• Ubutu 18.04 LTS - Fx 65.0b11 (affected) and native app Windows 10 x64

However we did not reproduce it on Fx 64.0.2, nor using Chrome.
We will return with the regression range as soon as possible (it does not reproduce every time).

Comment 3

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I managed to narrow it down using a Windows 7 x64. Here is the pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=785032241b2fe327aa833267416b3eb8d846cb4f&tochange=8b245cc1086f912f84b54a6af13f015404af8e14

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks Cristan! That seems to point to bug 1505284.

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Paul can you look at this since you reviewed bug 1505284 and we haven't had a response yet from jya?

Comment 6

[Paul Adenot (:padenot)]

In this range, we have two things: preffing on MediaDataDecoder for vp8 and vp9, and also for h264. This is a change in API and also potentially in decoding backend (this depends on the CPU, GPU, OS and OS version). The vp8 and vp9 changes are nightly only, so I think this is h264, because we can repro on 65, that was being built as a beta.

If we feel that not regressing this is important (it's too late considering we've regressed 65 already and we've shipped that), let's pref off and try to repro without the pref to get a solution as fast as possible.

The pref to flip is:

media.navigator.mediadatadecoder_h264_enabled

It must be set to false to try to repro. If we can't repro with this set to false, then we have a culprit and we can discuss about shipping this pref flip.

Now, about the bug. We're displaying the top-left quarter of the video received, and we think the problem is on the decoding side. This means that some coordinates or sizes are off. The prose isn't too precise, but a flicker can be thought of as a resolution change, especially if it happens some seconds after the beginning of the call.

It can be that after starting the call for a bit, the link is deemed good enough to start using higher-resolution video, that is four times bigger, and something is not updated: either the dimension of a texture: we only composite one quarter, the dimensions reported in js (and the web app crops it), that kind of thing. If this is the case, we should be able to reproduce a bit more easily by using network link conditioning techniques (tc or whatever).

Cristian, if possible, I'd like to have:

• Precise instruction on how to reproduce this: for example, I don't know what the Native App is (I can't find a way to download it on the web). I have all OSes on multiple machines here, so I hope I'll be able to reproduce.
• Infos on whether this pref flip fixes this regression

I seem to recall that jya told me something about resolution changes on some codec that wasn't supported, but my memory on the topic is fuzzy, I'll try to ping him.

Comment 7

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Hello Paul,

I used a Windows 7 x64 (about:support can be found here: https://pastebin.com/cNwxs2Ex ) and logged in here: http://web.ciscospark.com/. I initiated a call with a Widows 10 x64 having this app: https://www.webex.com/downloads.html (Cisco Webex Teams). After a few seconds the video feed on the Windows 7 x64 was zoomed in.

Flipping media.navigator.mediadatadecoder_h264_enabled pref code fixes the issue.

Best regards,
Cristian Comorasu.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

(for follow-up from comment #7)

Comment 9

[Paul Adenot (:padenot)]

Cool. So in release and beta and such, we can ship a pref flip. jya is having a look at the real issue.

Comment 10

[Paul Adenot (:padenot)]

Attachment: Bug 1520200 - Disable MediaDataDecoder for WebRTC when using h264. r?jya

Comment 11

[Jean-Yves Avenard [:jya]]

Now the question is should we uplift the fix in bug 1525230 which is the proper fix
or uplift this one which only turns off the pref.

The advantage of bug 1525230 fix is that it allows us to not use OpenH264 which currently gives issue when another peer is using Safari.

Comment 12

[Jean-Yves Avenard [:jya]]

Comment on attachment 9041835 [details]
Bug 1520200 - Disable MediaDataDecoder for WebRTC when using h264. r?jya

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1505284

User impact if declined

People will see cropped face during a video call

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

No

Needs manual test from QE?

No

If yes, steps to reproduce

Steps are provided in bug 1521530

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

Pref off code that made it to 65, reverting back to Firefox 64 code path

String changes made/needed

Comment 13

[Ryan VanderMeulen [:RyanVM]]

This should be fixed via bug 1525230 for 66/67.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9041835 [details]
Bug 1520200 - Disable MediaDataDecoder for WebRTC when using h264. r?jya

[Triage Comment]
Reverts us back to Fx64 behavior for Fx65, approved for 65.0.1.

Comment 15

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I could still reproduce this issue using Fx 66.0b6, I will return when Fx 66.0b7 is live.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/8016ccca3704

Comment 17

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I can confirm this issue is fixed, I verified using Fx 65.0.1, Fx 66.0b7 and Fx 67.0a1 on the same environment as in the description.

Comment 18

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

Attachment: jitsi.png

We managed to reproduce this issue again using: https://jitsi.org
Windows 10 x64 - Firefox nightly 76.0a1 (2020.03.11) and macOS 10.15 - Firefox Release 74.0.
While on Windows as soon as the call is initiated, I see the person from macOS side for a second, then notices a flicker in the video and the video displayed the following: see attachment jitsi.png. The call has no audio issue and on macOS side their are no audio or video issue.
Should I reopen this bug or file a new one?

Comment 19

[Paul Adenot (:padenot)]

John, do you now if hardware decoders for webrtc have been reenabled ?

Comment 20

[John Lin [:jhlin][:jolin]]

(In reply to Paul Adenot (:padenot) from comment #19)

John, do you now if hardware decoders for webrtc have been reenabled ?

The current prefs [1]: VPX is enabled only in nightly, and H.264 is disabled for Windows on ARM only.

[1] https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#6803