Re: [mediacapture-main] resizeMode: "none" should imply native frame rates (#762)

> resizeMode, by its name and its values (crop-and-scale) is clearly meant to resolution, not frame rate.

I agree about the name, but that seems superficial compared to its intended use and history.

`resizeMode` was introduced as a compromise between Firefox's spec-intent-driven _discovery_ model of discrete modes (`"none"`) and Chrome's _opaque_ yet admittedly more useful auto-adapt interpretation (`"crop-and-scale"`). We couldn't agree on a default between the two browsers, so we didn't, and defined a new constraint instead, so apps could pick.

But I think we failed to recognize that the difference between those models (discovery vs opaque) runs deeper, affecting the triumvirate of tradeoffs that traditionally make up "modes" in the first place in cameras: `width`, `height` and `frameRate`.

This is evident in two ways:
 1. It's possible today to discover/polyfill native presets for width, height and frameRate in Firefox but only width and height in Chrome.
 2. Apps can pick native width, height and frameRate using `advanced` in Firefox, but not Chrome:
    await getUserMedia({video: {width: 640, height: 480, advanced: [
      {resizeMode: "none"},
      {width: 1280, height: 768, frameRate: 5},
      {width: 1280, height: 768, frameRate: 15},
      {width: 640, height: 480, frameRate: 60},
With my Logitech, this might yield 1280x1024x15 native in Firefox, but 1280x758x5 decimated in Chrome.
With my built-in cam, this might yield 640x480x60 native in Firefox, but 1280x768x5 decimated in Chrome.

Adding a new constraint would not solve this. Assuming usage of `advanced` in combination with `resizeMode: "none"` is low (which I think it is), I'd rather we fix this in the algorithm to be cross-browser compatible while we can.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 21 December 2020 22:10:36 UTC