Window capture stride is wrong
Categories
(Core :: WebRTC: Audio/Video, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox94 | --- | unaffected |
firefox95 | --- | unaffected |
firefox96 | + | verified |
firefox97 | --- | verified |
People
(Reporter: bwc, Assigned: bwc)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(2 files)
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.
Assignee | ||
Comment 1•3 years ago
|
||
Seeing a very similar problem on windows as well, except the problem does not go away for certain window widths.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Set release status flags based on info from the regressing bug 1654112
Comment 3•3 years ago
|
||
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.
Assignee | ||
Comment 4•3 years ago
|
||
Assignee | ||
Comment 5•3 years ago
|
||
Assignee | ||
Comment 6•3 years ago
|
||
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.
Assignee | ||
Comment 7•3 years ago
|
||
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?
Assignee | ||
Comment 8•3 years ago
|
||
Comment 11•3 years ago
|
||
[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•3 years ago
|
||
(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•3 years ago
|
||
Pushed by bcampen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ee898d5997e1 Handle frames with padded width. r=pehrsons
Comment 14•3 years ago
|
||
jib, any ideas here?
Comment 15•3 years ago
|
||
bugherder |
Comment 16•3 years ago
|
||
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
Updated•3 years ago
|
Updated•3 years ago
|
Comment 17•3 years ago
|
||
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
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Description
•