Bug 258626
Summary: | getDisplayMedia video constraints not taking effect | ||
---|---|---|---|
Product: | WebKit | Reporter: | Justin <justin.martinez> |
Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | chris.pettet, ltsg0317, webkit-bug-importer, youennf |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 17 | ||
Hardware: | Mac (Intel) | ||
OS: | macOS 13 |
Justin
When calling getDisplayMedia with the following constraints (https://jsfiddle.net/fzyg0xwm/1/):
navigator.mediaDevices.getDisplayMedia({
video: { height: {ideal: 1080} },
audio: false,
});`
I see the returned track settings in tech preview 172:
{
deviceId: "6A7F268D31CD7DDE138F809C24A624CE78A1AC9E",
displaySurface: "monitor",
frameRate: 30,
height: 480,
width: 0
}
I see the returned track settings with safari 16.5:
{
deviceId: "C5D024CDADD6B6729E82D9E447E8E9CD83916D64",
displaySurface: "monitor",
frameRate: 30,
height: 1080,
width: 0
}
Additional calls to applyConstraints work but initial getDisplayMedia call does not return the expected stream settings. I'm assuming Tech Preview should have the same track settings as seen in 16.5.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/111796599>
Justin
I also tried this with 17.0 Beta and seeing the same results.
chris.pettet
I tried this with Safari Technical Preview 180 and Safari Version 17.0 (18616.1.27.111.22, 18616) and saw the same results.
shuming
I also encountered this problem at the same time found a hard code solution, after the video rendering, you can modify the resolution by applyConstraints, but I do not think it is a good way to deal with it, I hope to deal with this bug soon!
This is the demo: https://jsfiddle.net/ltsg0317/yh5rnfa8/11/
youenn fablet
On STP, the initial getSettings() might return 480, but it should later be updated to 1080 (a configuration change event should be fired).
The reason is that the promise resolves before we are capturing the first video frame, which gives us the actual video frame size.
Once we have the size, we are correctly applying the constraints (after https://bugs.webkit.org/show_bug.cgi?id=263015 fix).
I am tentatively closing as fixed by bug 263015.
Please reopen if the initially computed getSettings cause some issues.
*** This bug has been marked as a duplicate of bug 263015 ***