- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 26 Jul 2019 23:14:15 +0000
- To: public-webrtc-logs@w3.org
> I think we merely need to omit mentioning any constraints here. Then we can leave it to an extension spec to define them, maybe? An extension spec looks good to me here. This would allow a much better description than what we might end up doing now and some time to define precisely what we are trying to enable here. > > Looking at what Chrome is exposing, resizeMode is also potentially in scope. > > This is a good example of something that would require specification. Presumable `"none"` might mean the RTPeerConnection has some indication or reason to believe the video has not downscaled for bandwidth reasons (but how can it know? Is it in the SDP?) 'none' to me means no post-processing past the video decoder and the video decoder decoding at max possible resolution. resizeMode would then apply in principle a post-processing based on these highest resolution frames. Implementations would be free to use whatever means to achieve better performances of scaling/cropping for instance with scalable contents. In that context, the web application might want to decide whether cropping or not, potentially based on whether content is screen-sharing vs. camera. Of course, the cropping/scaling would best be done at sender side... -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2188#issuecomment-515625820 using your GitHub account
Received on Friday, 26 July 2019 23:14:17 UTC