Note

• When performing a Hangouts video call between a Lenovo Yoga (Qualcomm processor device) and another random PC, the audio call is made correctly, the video is only available streamed from the secondary PC to the Yoga, but the video will be intermittently improperly displayed.

Affected versions

• Nightly v67.0a1 from 2019-03-15 aarch64 build

Affected platforms

• Windows 10 on Lenovo Yoga (Qualcomm processor device)

Steps to reproduce

1. Open hangouts.google.com
2. Log in with a google account (it MAY need to be a generic google account, not Mozilla account)
3. Perform a video call with any other machine.

Expected result

• The call is made correctly with video on only one side; video streamed from the secondary machine to the Lenovo Yoga should be properly displayed.

Actual result

• The call is made with video on only one side; video streamed from the secondary test machine to the Lenovo Yoga is improperly displayed.

Regression range

• A mozregression could not be performed on the Lenovo Yoga because the mozregression GUI app will get 32bit build versions instead of aarch64 builds and the terminal version cannot be installed due to its Qualcomm architecture: bug 1536013.

Additional notes

• Differently from the old bug 1315283, the video will intermittently be correctly displayed then again incorrectly and so on. So far, it's been fairly easily reproducible on the Nightly aarch64 build.
• This issue could also be reproduced on the 32-bit Nightly build (non-aarch64), only on the Lenovo Yoga and only for a few seconds at the start of the call with a considerably lower rate of reproduction.
• Also, it could not be reproduced on the Beta RC v66.0 aarch64 build.

A mozregression build that launches aarch64 builds was released. I have attempted to test it while trying to find the regressor that brought this issue back, but I am unable to find it because the aarch64 builds from late December 2018 will always crash when a hangouts video call is attempted (even if the video streaming from the Yoga is disabled or the integrated camera is disabled fro Device Manager).

In conclusion, this issue's regressor cannot be found through testing activities.

This might be a duplicate of bug 1535584. Once that bug lands, let's see if we can reproduce this problem.

Would it be possible to re-test this with a Nightly containing the fix from Bug 1535584? Thank you!

I have attempted to reproduce this issue on nightly v68.0a1 with the fix patched for bug 1535584. The original issue could not be reproduced.
Considering that this issue seems to be fixed by the patch of another bug, I will mark it as Worksforme. Thank you.

Updating status for Fx67 based on bug 1535584