- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Jan 2025 20:17:56 +0000
- To: public-webrtc-logs@w3.org
Our [model](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-capabilities) says _"Source capabilities are effectively constant. Applications should be able to depend on a specific source having the same capabilities for any browsing session."_ However, that text may be a bit outdated: As @alvestrand mentions, the adjacent `getDisplayMedia` (following the same model) says of e.g. [width](https://w3c.github.io/mediacapture-screen-share/#dfn-width) _"As a capability, max MUST reflect the [display surface](https://w3c.github.io/mediacapture-screen-share/#dfn-display-surface)'s width"_ which in practical terms when capturing a window in Safari [updates live in response to the user resizing the captured window](https://jsfiddle.net/jib1/rs16kgqd/) (though not Chrome). In the example you give, I'd say once a user locks their virtual device to 1080x1920 output, I think a case can be made that getCapabilities() from then on should read (0, 1080) for width, not (0, 65536). _"Media MUST NOT be upscaled"_. But if this requires page reload to take effect, that seems fine to me. After all, this API was designed for cameras; virtual cameras pretend to be cameras, which means adhering to certain camera abstractions and limitations. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1027#issuecomment-2599124287 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 17 January 2025 20:17:57 UTC