Bug 1520200
| Summary: | web.ciscospark.com sometimes displays a zoomed-in upper-left corner of the video feed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Components] Core | Reporter: | Cristian Comorasu [:ccomorasu], Release Desktop QA <cristian.comorasu> | ||||
| Component: | WebRTC: Audio/Video | Assignee: | Paul Adenot (:padenot) <padenot> | ||||
| Status: | VERIFIED FIXED | QA Contact: | Cristian Comorasu [:ccomorasu], Release Desktop QA <cristian.comorasu> | ||||
| Severity: | normal | ||||||
| Priority: | P1 | CC: | bogdan.maris, cornel.ionce, cristian.fogel, jaws, jcristau, jib, jyavenard, karlt, padenot, ryanvm | ||||
| Version: | Trunk | Keywords: | cisco-spark, regression | ||||
| Target Milestone: | mozilla67 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| See Also: | https://bugzilla.mozilla.org/show_bug.cgi?id=1525230 | ||||||
| Whiteboard: | |||||||
| relnote-firefox: | 65+ | tracking-thunderbird_esr60: | --- | ||||
| status-thunderbird_esr60: | --- | Crash Signature: | |||||
| Last Resolved: | 2019-02-11 13:03:53 | User Story: | |||||
| QA Whiteboard: | [qa-triaged] | Iteration: | --- | ||||
| Points: | --- | Rank: | |||||
| Has Regression Range: | yes | Has STR: | yes | ||||
| tracking-geckoview66: | --- | status-geckoview66: | --- | ||||
| tracking-firefox-esr60: | --- | status-firefox-esr60: | unaffected | ||||
| status-firefox64: | unaffected | tracking-firefox65: | + | ||||
| status-firefox65: | verified | tracking-firefox66: | + | ||||
| status-firefox66: | verified | tracking-firefox67: | + | ||||
| status-firefox67: | verified | tracking-firefox68: | --- | ||||
| status-firefox68: | --- | Fission Milestone: | --- | ||||
| Bug Depends on: | |||||||
| Bug Blocks: | 1505284 | ||||||
| Attachments: |
|
||||||
|
Description
Cristian Comorasu [:ccomorasu], Release Desktop QA
2019-01-15 08:13:24 PST
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. 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). 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 Thanks Cristan! That seems to point to bug 1505284.
Comment 5
(behind on reviews and needinfos) Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me)
2019-01-30 05:48:28 PST
Paul can you look at this since you reviewed bug 1505284 and we haven't had a response yet from jya? 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.
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
(behind on reviews and needinfos) Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me)
2019-02-06 07:56:40 PST
(for follow-up from comment #7) Cool. So in release and beta and such, we can ship a pref flip. jya is having a look at the real issue. Created attachment 9041835 [details] Bug 1520200 - Disable MediaDataDecoder for WebRTC when using h264. r?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 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 This should be fixed via bug 1525230 for 66/67. 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. I could still reproduce this issue using Fx 66.0b6, I will return when Fx 66.0b7 is live. 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. |
