1738946 - Window capture stride is wrong

Status: VERIFIED FIXED

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[Byron Campen [:bwc]]

Attachment: screenshare_distortion.pdf

Depends on the width of the window being captured; most widths do not work properly, but some do. Observed on OS X (intel), but may happen on other platforms.

Comment 1

[Byron Campen [:bwc]]

Seeing a very similar problem on windows as well, except the problem does not go away for certain window widths.

Comment 2

[Release mgmt bot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1654112

Comment 3

[Paul Adenot (:padenot)]

I'm seeing something like this in a Meet call today also on macOS (11.0, no external screen): was sharing a maximized Firefox window showing something to the other participants, and I used the three finger swipe up gesture to move to another Firefox window, and I briefly saw something like Byron describes. I can repro 100% of the time.

Comment 4

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d8019c15f7c7f1d802126d4af8bd48893383e33

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1ff17e9420b6713d2c00be320b25318fb6aaa3ca

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8298c15cf7c8a7512c6a70f4393b2496b8cb1502

Comment 5

[Byron Campen [:bwc]]

Attachment: Bug 1738946: Handle frames with padded width. r?pehrsons

Comment 6

[Byron Campen [:bwc]]

Binaries from the try pushes seem to fix the problem on OS X and Windows. It would be nice to have an automated test-case though. Maybe it would not be too difficult to add some pixel testing to test_getUserMedia_basicWindowshare.html (similar to test_getUserMedia_basicScreenshare.html). That would have detected this problem on Windows I think, but maybe not OS X.

Comment 7

[Byron Campen [:bwc]]

Try as I might, I cannot get test_getUserMedia_basicWindowshare (or test_peerConnection_basicWindowshare) to select the specific window I want, it just selects the "first" window in the list of options, even when I supply a browserWindow in the constraints. I've verified that my selection is making it at least as far as MediaManager::GetUserMedia, and that it is a valid browser window, but it simply seems to have no effect. Looking in searchfox, I don't see mBrowserWindow being used in any meaningful way from c++. Then again, tab capture does seem to be capturing a firefox tab, and not some random window. Maybe this happens not because of the value of mBrowserWindow, but for some other reason?

jib, any ideas here?

Comment 8

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dbbacb9f603fc61e59507d2805b4b3bfa9d4b8e3

Comment 11

[Andreas Pehrson [:pehrsons]]

[Tracking Requested - why for this release]: Moved from https://bugzilla.mozilla.org/show_bug.cgi?id=1738628#c2:

This is a bad regression in Firefox 96 from libwebrtc update bug 1654112.

I have only tested on Windows 11.

Comment 12

[Andreas Pehrson [:pehrsons]]

(In reply to Byron Campen [:bwc] from comment #7)

Try as I might, I cannot get test_getUserMedia_basicWindowshare (or test_peerConnection_basicWindowshare) to select the specific window I want, it just selects the "first" window in the list of options, even when I supply a browserWindow in the constraints. I've verified that my selection is making it at least as far as MediaManager::GetUserMedia, and that it is a valid browser window, but it simply seems to have no effect. Looking in searchfox, I don't see mBrowserWindow being used in any meaningful way from c++. Then again, tab capture does seem to be capturing a firefox tab, and not some random window. Maybe this happens not because of the value of mBrowserWindow, but for some other reason?

I believe mBrowserWindow is for selecting the tab for tab capture, and that is a whole other backend than window capture.

To select window for window capture you'd have to

• Restore "media.navigator.permission.disabled" and interact with the prompt, or
• Make sure you have only one window, or
• Rely on the ordering of the windows.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ee898d5997e1
Handle frames with padded width. r=pehrsons

Comment 14

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

jib, any ideas here?

See bug 1740020 comment 2.

Comment 15

[Cristina Cozmuta (:CrissCozmuta)]

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

Comment 16

[Henrik Mitsch [:hmitsch]]

The fix works like a charm in the latest Nightly build. Thanks for fixing this so quickly. Back to Google Meet screen sharing on Nightly (see Bug 1739962).

-Henrik

Comment 17

[Bodea Daniel [:danibodea]]

I have reproduced this issue by sharing windows (not entire screens) to other video call participants on Mac OS 11.6.2 and Windows 10 in Nightly v96.0a1 from 2021-11-02 and confirmed fix in Nightly v97.0a1 from 2021-12-22 and Beta v96.0b8