W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2019

Re: [webrtc-pc] Define which constraints are applicable in WebRTC (#2188)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Fri, 26 Jul 2019 19:52:11 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-515578644-1564170730-sysbot+gh@w3.org>
> It seems too late to argue for as simpler surface—`track.width` and `track.height` anyone?

If we add something like that, we might want to expose the fact that these values are changing so that the web app could react upon. This seems late for v1.0.

I am not convinced yet constraints/capabilities/settings mechanism is the best tool for the use cases we are trying to solve here. I am not clear of which real world issue we are trying to solve either.
Given that and the fact that this mechanism is difficult to get good interop, I am kind of reluctant to further increase the use of this mechanism.

> Constraints are an interoperability cop-out: a license for browsers to act differently, as long as they state their [capabilities](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-constrainablepattern-getcapabilities)

In the long run, I hope all browsers can converge though.
Also, if two browsers express supporting the same capability values, there is the expectation to get the same result when applying the same constraint values.
In this particular case, if we add precise wording in webrtc-pc for how remote tracks constraints are supposed to work, we need two webrtc-pc implementations to show interoperability.

Looking at what Chrome is exposing, resizeMode is also potentially in scope.
Remote audio tracks should also be described somehow, Chrome seems to expose some settings and capabilities.

I am fine saying in v1 something like:
- In mediacapture-main spec: each spec defining a new type of source is expected to define the exact list of supported constrainable properties. By default, there is none inherited from mediacapture-main.
- In webrtc-pc spec: no constrainable property is mandatory for any remote source. A user agent MAY expose constrainable properties defined in media capture-main to remote sources.

> _"The user agent MUST NOT crop the captured output."_, which makes perfect sense for screen sharing, but differs from camera. So sources behave differently. A remote track could be either, so I'd say MUST NOT crop.

These seem like good default behaviours. Ultimately, this seems application dependent though.
It is also weird that screen capture is stating to support crop-and-scale but actually says that cropping is forbidden. This might call for adding a new constrainable property value, letterbox.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2188#issuecomment-515578644 using your GitHub account
Received on Friday, 26 July 2019 19:52:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:26 UTC