We can disable the camera for aarch64 windows builds rather than disabling webrtc entirely.

This disables the camera for win64-aarch64 for Windows versions below
19H1. These versions have problems with the DirectShow implementation
which prevent the camera from working properly.

https://hg.mozilla.org/mozilla-central/rev/da83e69c7331

I am testing the behavior of WebRTC on Lenovo Yoga C630 (qualcomm laptop) and these are my results:

Facebook:

• Nightly (fx67): A video call will request access to your microphone, but not the camera. The call will work with audio only.
• Beta (fx66): A video call will request access to your microphone and camera. It provides a hardware Access Error. Call impossible.

Tokbox:

• Nightly (fx67): Only request to allow microphone is shown. Video camera is not recognized. An audio call is made correctly.
• Beta (fx66): Requests to allow camera and microphone access; The call is impossible.

Cisco Spark web client:

• Nightly (fx67): Only microphone access request displayed. Error displayed: "Could not acquire local media. Please check your settings."; Not video, nor audio calls could be performed.
• Beta (fx66): Both the camera and microphone access request were displayed. Same error displayed: "Could not acquire local media. Please check your settings." Not video, nor audio calls could be performed.
  THIS MAY BE LESS THEN EXPECTED.

Talky:

• Nightly (fx67): Only request to allow microphone is shown. Camera not detected. Audio call with video on only one side is working properly.
• Beta (fx66): Both the camera and microphone access request were displayed. Audio call with video on only one side is working properly.
  THIS MAY BE MORE THAN EXPECTED.

Appear in:

• Nightly (fv67): Only request to allow microphone is shown. Audio call with video on only one side is working properly.
• Beta (fx66): Both the camera and microphone access request were displayed. The call is made, but it is useless because the camera AND the microphone are improperly recognised. Audio/video communication is impossible.

jitsi.org:

• Nightly (fv67): Only request to allow microphone is shown. Error displayed: "Failed to access your camera."; Audio call with video on only one side is working properly.
• Beta (fx66): Both the camera and microphone access request were displayed. Audio call with video on only one side is working properly.
  THIS MAY BE MORE THAN EXPECTED.

appr.tc:

• Nightly (fv67): Only request to allow microphone is shown. Error displayed: "Failed to access your camera."; Audio call with video on only one side is working properly.
• Beta (fx66): Both the camera and microphone access request were displayed. Error displayed: "Failed to get access to local media. Error name was NotReadableError. Continuing without sending a stream."; Audio video could only be received, not streamed.

Hangouts:

• Nightly (fv67): Only request to allow microphone is shown. Audio call with video on only one side is working properly.
• Beta (fx66): Both the camera and microphone access request were displayed. Audio call with video on only one side is working properly.
  THIS MAY BE MORE THAN EXPECTED.

getUserMedia Test Page: https://mozilla.github.io/webrtc-landing/gum_test.html
Click on "Audio + Video":

• Nightly (fx67): Camera/Microphone access request NOT displayed; Error displayed: "NotFoundError: The object can not be found here."
• Beta (fx66): Both the camera and microphone access requeste are displayed; Error displayed: "NotReadableError: Failed to allocate videosource"

Conclusion: With the latest patch, most of the popular WebRTC applications are working properly without video sharing, only with audio sharing; possibli receiving video, but not being able to stream.
The behavior on Beta for each scenario can show that this fix was very helpfull, however, it appears that the Cisco Spark web client also fails an audio call on Nightly, not only on Beta.

I expect this can be considered a valid fix. Please confirm it.

Furthermore, should the issue with the Cisco app be addressed sepparately? Should I log a new bug?

Thank you!

Lgtm. The cisco spark web client behavior suggests it requires both camera and microphone to work, in spite of the error message: "Not video, nor audio calls could be performed".

I would compare it to running cisco spark web client on a non-aarch64 system that has a mic but lacks a camera. If the behavior is the same then this is a web site issue not a Firefox bug.

FWIW I briefly tested https://teams.webex.com/spaces on Mojave which lets me turn off camera in System Preferences / Security & Privacy, and got the same behavior—even though I did run into bug 1502967—so I think we're fine. We might want to give cisco a heads up though.

• I have tested the situation requested above, Nightly 64bit non-aarch64 build on desktop PC with webcam removed:
  I have removed my physical webcam from my desktop workstation (with Windows 10) and called another test machine; only the request for microphone access was displayed and the call was made correctly with audio on both sides and video on only one side.
  All good here.

...Then I have continued similar scenarios to be sure that the next decision is taken correctly:

• Nightly 32bit non-aarch64 build on Lenovo Yoga:
  I have also tested the scenario where I try to run a video call between the Lenovo Yoga, but from the 32bit, non-aarch64 Nightly build: in this situation, the call was made correctly with audio/video on both sides.
  All good here.

• Nightly 32bit non-aarch64 build on Lenovo Yoga with internal webcam disabled from the Device Manager:
  I've disabled Yoga's internal webcam from Device Manager, opened the 32bit non-aarch64 Nightly build and attempted the video call: only the request for microphone access was displayed and the call was made correctly with audio on both sides and video on only one side.
  All good here.

• Nightly 64bit aarch64 build on Lenovo Yoga with webcam disabled from Device Manager:
  I left the webcam disabled, opened the 64bit aarch64 Nightly build and attempted the video call: the call could not be performed. The same error was displayed: "Could not acquire local media. please check yourt settings."
  Considering that the camera is disabled from the OS AND from the browser, the call should be made correctly with video on only one side. This sounds like an aarch64 build issue.

• Beta 64bit aarch64 build on Lenovo Yoga with webcam disabled from Device Manager:
  I left the webcam disabled, opened the 64bit aarch64 Nightly build and attempted the video call: the call could not be performed. The same error was displayed: "Could not acquire local media. please check yourt settings."
  Considering that the camera is disabled from the OS and not from the browser (but it shouldn't matter), the call should be made correctly with video on only one side. This sounds like an aarch64 build issue.

All these tests were performed with the Cisco Spark web client: https://teams.webex.com/spaces/

Considering all the tests above, I have to disagree with you and say that this might be an issue of Firefox.
I request feedback. Thanks.

If we're only seeing problems with Cisco Spark, I think it makes sense to file a separate bug to track those down. Thank you for your work testing this!

Comment 8 makes sense to me.

Can you request uplift to mozilla-release? Thanks.

Note, we need this in 66 for bug 1529383.

I have logged an issue for the remaining inconvenience, the impossibility of performing at least an audio call with Cisco Spark web client on aarch64 builds: bug 1534933.
Also, I will not mark the bug's status as verified, since it appears that it's being planned to uplift it to Beta. It will be marked accordingly when the uplift is verified as well.
Thanks.

Comment on attachment 9046848 [details]
Bug 1530488 - Disable camera for aarch64 windows builds; r=pehrsons

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: None
• User impact if declined: Unable to make audio only WebRTC calls.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Already tested by QE.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is low risk, it just disables the camera, and has already been tested on a number of services. The alternative is completely broken WebRTC.
• String changes made/needed: None.

Comment on attachment 9046848 [details]
Bug 1530488 - Disable camera for aarch64 windows builds; r=pehrsons

Needed for WebRTC to work on aarch64 windows builds.

https://hg.mozilla.org/releases/mozilla-release/rev/38edbc4fa662

Lenovo Yoga C630 (qualcomm laptop) on try build for RC: 66.0 20190313232343

Facebook:

• required/granted mic access
• video device not found - call only audio connects

Talky:

• required/granted mic access
• video none - call only audio connects

Cisco Spark web client:

• still affected by bug 1534933

Appear in:

• required/granted mic access
• video device not found - call only audio connects

jitsi.org:

• required/granted mic access
• video device not found - call only audio connects

appr.tc:

• required/granted mic access
• video device not found - call only audio connects

Hangouts:

• required/granted mic access
• video device not found - call only audio connects

getUserMedia Test Page: https://mozilla.github.io/webrtc-landing/gum_test.html
*Click on "Audio + Video":
Camera/Microphone access request NOT displayed; Error displayed: "NotFoundError: The object can not be found here."

Based on the above, marking the FX66 verified as well for Aarch 64