- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Nov 2017 23:51:56 +0000
- To: public-media-capture-logs@w3.org
> width:100, height:100 should ideally scale down to height 100 and then crop the width to 100 More than "how", the spec doesn't mandate downscaling, so this won't work across browsers. The sole mention of downscaling in the entire spec appears in this paragraph about concurrent use: *"Multiple tracks can be attached to the same source. User Agent processing, such as downsampling, **MAY** be used to ensure that all tracks have appropriate media."* We're [implementing](https://bugzilla.mozilla.org/show_bug.cgi?id=1388219) that paragraph in Firefox, to abstract away knowledge of other tabs, which is good for privacy. However, this is separate from boosting the fitness distance pool. We're open to figuring out how to interpret rescale intent from constraints, as you can see in https://github.com/w3c/mediacapture-main/issues/472. > thumbnails are to be shown (at a remote end point) The only spec way to do that today is to [downscale in the encoder](https://blog.mozilla.org/webrtc/fiddle-week-downscale-video-peerconnection/), using [scaleResolutionDownBy](http://w3c.github.io/webrtc-pc/#dom-rtcrtpencodingparameters-scaleresolutiondownby). An implementation would have to be careful to avoid rescaling twice. How sure are we we want the `track` to be the control surface for the encoder? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/495#issuecomment-341591631 using your GitHub account
Received on Thursday, 2 November 2017 23:51:58 UTC