- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Sun, 06 Aug 2017 12:12:10 +0000
- To: public-media-capture-logs@w3.org
Your example just shows that a "native" constraint where true means native and false means non-native would not be very useful. If instead we have a "rescaling" or "rescalingAllowed" constraint, meaning that rescaling is allowed (but not required) when true would not have that problem. Having the constraint equal to exact false would have the effect of removing the candidate dictionaries with nonnative resolutions. Having the constraint as ideal false would result in native modes preferred over non-native modes, while allowing the possibility to switch to non-native in certain cases (e.g., concurrent access). We can also make the constraint non-boolean if we need more than two values. Changing the spec to redefine min/max/exact/ideal to mean native-only sounds like a bad idea to me. First, it introduces semantics that have no relation with what those words represent. It would seem counterintuitive to me that an application saying the ideal height is "638" means that 638 is forbidden. Second, it is overly restrictive. It would mean that the only tracks that can be rescaled are unconstrained ones. I don't see why an application that specifies a range between 1-1000 should be forbidden from having a rescaled track in that range. Finally, what happens if min/max/exact is specified in some advanced set that is initially ignored, but becomes satisfiable because another track was closed? Does this mean that rescaling was initially allowed, but forbidden afterwards? This might require nontrivial changes to the spec to cover for various corner cases, or it would lead to many incompatible implementations. Another spec change that is needed is that naked values become a completely new category of value, distinct from ideal (in basic sets) and exact (in advanced sets). The constraints-based solution I proposed seems a lot more straightforward to me. It allows the application to explicitly express intent. The only change required in the spec is to add a new entry to the list of supported constraints, not unlike the recent addition of processing constraints for audio. Also, it opens the possibility to other processing techniques (e.g., some users have requested video mirroring, which is useful for many applications and currently requires a lot of boilerplate to implement, see issue #452). -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/472#issuecomment-320503146 using your GitHub account
Received on Sunday, 6 August 2017 12:12:11 UTC