Closed Bug 1520200 Opened 2 years ago Closed 2 years ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla67
Tracking Status
relnote-firefox --- 65+
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 + verified
firefox66 + verified
firefox67 + verified

People

(Reporter: ccomorasu, Assigned: padenot)

References

Details

(Keywords: cisco-spark, regression)

Attachments

(1 file, 1 obsolete file)

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

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.

Flags: needinfo?(cristian.comorasu)

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

Has Regression Range: --- → no
Has Regression Range: no → yes
Has STR: --- → yes
Flags: needinfo?(cristian.comorasu)

Thanks Cristan! That seems to point to bug 1505284.

Blocks: 1505284
Flags: needinfo?(jyavenard)
Keywords: regression

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

Flags: needinfo?(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.

Flags: needinfo?(padenot) → needinfo?(cristian.comorasu)

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.

Flags: needinfo?(cristian.comorasu)

(for follow-up from comment #7)

Flags: needinfo?(padenot)

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

Flags: needinfo?(padenot)
Blocks: 1519860

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.

Flags: needinfo?(jyavenard)
See Also: → 1525230
No longer blocks: 1519860

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

Attachment #9041835 - Flags: approval-mozilla-release?
Priority: -- → P1
Assignee: nobody → padenot

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

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: qe-verify+
Flags: needinfo?(cristian.comorasu)
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

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.

Attachment #9041835 - Flags: approval-mozilla-release? → approval-mozilla-release+

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

Flags: needinfo?(cristian.comorasu)
Flags: needinfo?(cristian.comorasu)
Whiteboard: [qa-triaged]

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.

Flags: qe-verify+
Flags: needinfo?(cristian.comorasu)
Status: RESOLVED → VERIFIED
Attachment #9041835 - Attachment is obsolete: true
QA Whiteboard: [qa-triaged]
Whiteboard: [qa-triaged]
Attached image 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?

Flags: needinfo?(padenot)

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

Flags: needinfo?(padenot) → needinfo?(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

Flags: needinfo?(jolin)
You need to log in before you can comment on or make changes to this bug.