- From: Anthony Minessale via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 May 2021 15:34:41 +0000
- To: public-webrtc-logs@w3.org
How about "scale-to-aspect" as a separate param as well? The browser already downscales, preserving the aspect when it detects a network issue, so clearly, this is already implemented. There simply needs to be a way to do it on purpose so you have full control of the resolution you want to capture and send. Never going backward should not be an overarching rule. The reality is that cameras often have very few native resolutions and browsers have plenty of power to resize images more than they have network resources for oversized images. There should be at least one strategy to pick the best native resolution matching the requested native aspectRatio and scale it as desired up or down. Forcing an aspectRatio by zooming a mismatched aspectRatio causes nearly unusable circumstances because it zooms so much. Regarding screen share. The black bars rule needs to have an exception for screen share since the window could have any resolution and just zooming the screen share makes no sense. If you apply no constraints it does letterbox of the entire window at its native resolution but as soon as you apply constraints it does the same undesired zooming. If I am sharing my window on a 4k monitor and I know it's going to be sent to people on a 1080p monitor it makes more sense to use constraints to lower the size of the image before I send it over the internet. -- GitHub Notification of comment by anthmFS Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/584#issuecomment-847126094 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 May 2021 15:34:43 UTC