web.ciscospark.com sometimes displays a zoomed-in upper-left corner of the video feed
Categories
(Core :: WebRTC: Audio/Video, defect, P1)
Tracking
()
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)
1.10 MB,
image/png
|
Details |
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
- Launch Firefox.
- Go to http://web.ciscospark.com/ and log in.
- 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•6 years ago
|
||
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.
Reporter | ||
Comment 2•6 years ago
|
||
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).
Updated•6 years ago
|
Reporter | ||
Comment 3•6 years ago
|
||
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•6 years ago
|
||
Thanks Cristan! That seems to point to bug 1505284.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Paul can you look at this since you reviewed bug 1505284 and we haven't had a response yet from jya?
Assignee | ||
Comment 6•6 years ago
|
||
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.
Reporter | ||
Comment 7•6 years ago
|
||
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.
Assignee | ||
Comment 9•6 years ago
|
||
Cool. So in release and beta and such, we can ship a pref flip. jya is having a look at the real issue.
Assignee | ||
Comment 10•6 years ago
|
||
Comment 11•6 years ago
|
||
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.
Updated•6 years ago
|
Comment 12•6 years ago
|
||
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
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
Updated•6 years ago
|
Updated•6 years ago
|
Comment 13•6 years ago
|
||
This should be fixed via bug 1525230 for 66/67.
Updated•6 years ago
|
Comment 14•6 years ago
|
||
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.
Reporter | ||
Comment 15•6 years ago
|
||
I could still reproduce this issue using Fx 66.0b6, I will return when Fx 66.0b7 is live.
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 16•6 years ago
|
||
bugherder uplift |
Updated•6 years ago
|
Reporter | ||
Comment 17•6 years ago
|
||
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.
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 18•5 years ago
|
||
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?
Assignee | ||
Comment 19•5 years ago
|
||
John, do you now if hardware decoders for webrtc have been reenabled ?
Comment 20•5 years ago
|
||
(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
Description
•