@henbos Yes, that's what I expected, and complies with my "more modes" reading of the [spec](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediatrackcapabilities-resizemode): *"The user agent MAY use cropping and downscaling to offer* ***more resolution choices than this camera naturally produces***. *The reported sequence MUST list all the means the UA may employ to* ***derive resolution choices for this camera."*** In other words, the purpose is to simulate camera modes. Since I've never seen a camera naturally emit a track containing black bars, I would not expect that output. I was even going to say that I thought black bars go against the "don't invent pixels" rule we have, but then I couldn't find such a rule. Turns out we only have it in [WebRTC](http://w3c.github.io/webrtc-pc/#rtp-media-api): *"The media MUST NOT be upscaled to create fake data that did not occur in the input source"*. An oversight? I kinda think that's implied. Do we want to add language to make this clearer? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/584#issuecomment-489705348 using your GitHub accountReceived on Monday, 6 May 2019 17:32:01 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:47 UTC