webRTC broken as of recent update?

Description of the issue: Acquiring a video feed from a webrtc client fails using Brave.

How can this issue be reproduced?

  1. Go to a webRTC test site, e.g. https://test.webrtc.org
  2. [If necessary, select a valid camera and grant permission for the page to access the camera.]
  3. Run a test.

Expected result: Test succeeds; Brave is able to acquire video stream.

Brave Version( check About Brave): Version 1.19.88 Chromium: 88.0.4324.96 (Official Build) (x86_64)

Additional Information: I use browser-based WebRTC applications on a daily basis, and have been using Brave as my primary browser with no problems for >6 months. This problem started within the last week, and was present in at least one version prior to the current version. (Sorry, not sure which - I updated to the latest right after noticing. I think it was the version immediately before the current.)

I’m on macos 10.14.6. Behavior observed with both built-in macbook pro camera and external USB camera.

Note that the exact same config (including camera permissions) works without trouble on desktop Chrome based on the same chromium version.

I verified that Brave isn’t blocking anything, and that the same problem is seen regardless of whether Brave’s shields are “up” or “down”.

1 Like

The test.webrtc.org site referenced in my original problem report has the option to create debug reports showing details of test behavior. Comparing the debug report written from Chrome (88.0.4324.96), which works, and Brave (1.19.88 Chromium: 88.0.4324.96) shows the following difference in the Brave report:

{"ts":1612115674211,"name":"test-run","id":4,"args":{"success":"Captured video using expected resolution."}},
{"ts":1612115674211,"name":"test-run","id":4,"args":{"error":"Camera delivering lots of black frames."}},
{"ts":1612115674211,"name":"test-run","id":4,"args":{"error":"Camera delivering lots of frozen frames."}},
{"ts":1612115674212,"name":"test-run","id":4,"args":{"status":"failure"}},

The corresponding lines from Chrome look like:

{"ts":1612115212160,"name":"test-run","id":4,"args":{"success":"Captured video using expected resolution."}},
{"ts":1612115212160,"name":"test-run","id":4,"args":{"status":"success"}},

(I’d attach the files, but as a new user cannot. Happy to send them some other way if they’re useful, though I suspect this will be straightforward to reproduce.)

Here’s a different scenario that demonstrates the same issue:

Steps:

  1. Go to https://www.webcasts.com/webrtc/
  2. Grant browser permission to access camear
  3. Select appropriate video source

Expected results: see image from camera
Actual results: see black rectangle
Additional info: Following these same steps with the same hardware and chrome works as expected (i.e. image is seen).

Same issue noticed Friday Jan 29th, 2021
MacOS High Sierra 10.13.6
Brave Version 1.19.88 Chromium: 88.0.4324.96 (Official Build) (x86_64)

Chrome and Firefox work on same Google Meet. Also tested Jitsi Meet, Brave fails to show video. I see my video and all camera access is selected and valid, shields down.

Allowing Fingerprinting on https://www.webcasts.com/webrtc/ should help here @jrheling

Thanks for the suggestion, @fanboynz .

I only see a global option controlling fingerprinting. It was set to “standard” - changing it to “disabled” and reloading https://www.webcasts.com/webrtc/ did not cause video to start working.

Interestingly, though, I noticed (quite by accident) that opening that URL by following a link (vs. by typing it in the address bar) does cause video to work. Meaning if I a) click that link from your message to open it in a different page, and b) (in a separate brave window) type that URL in the location bar, I will see working video on (a) and a blank screen on (b).

So that seems like a hint, but not a solution.

However, that difference of behavior seen when clicking a link vs. typing a URL does not seem to generalize: when I navigate (via links) to other WebRTC-using pages that worked in Brave until last week, they still do not work.

This appears to have been fixed as of
Version 1.19.90 Chromium: 88.0.4324.146 (Official Build) (x86_64)

2 Likes

I just came to ask if this issue was resolved after the update to 1.19.90 – thank you for confirming @jrheling.
Please let us know if the issue returns.

1 Like