Re: peerConnection constraints webidl implementer feedback

On 10/16/2013 12:02 AM, Jan-Ivar Bruaroey wrote:
> Hi all,
> Here's some feedback after cleaning up constraints for 
> createOffer/Answer in PeerConnection in Firefox. They're in 
> engineering-style bullet-points, so my apologies in advance for the 
> terseness (these are all requests for spec changes).
> These are probably more controversial than the feedback I just posted 
> for gUM in media-capture, so I'll jump right in:
>  1. About the settings passed to createOffer/Answer & addStream: These
>     are not really constraints IMHO!
>       * I see constraints as defined in gUM by their /reduction/
>         algorithm on some starting pool of similar-propertied things,
>         candidates. Applying this model to the abstract "capabilities"
>         of PeerConnection seems like a stretch that would need a lot
>         of upside to justify the complexity and confusion it adds
>         upfront (like the inverse logic, and whether these things and
>         gUM-constraints are interchangeable)
>       * Differences from gUM constraints:
>           o There is no "audio" or "video" top-layer, we jump right
>             into mandatory vs. optional.
>           o There's no pool of similar-propertied things to reduce, so
>             the reduction algorithm for optional constraints doesn't
>             fit, and the array construct serves no purpose (other than
>             that the whole category is not-mandatory)
>           o The mandatory algorithm boils down to "use these settings
>             (which you must support)". Very simple.
>           o Once unknown keys have been checked for, there's no
>             difference between mandatory and optional internally,
>             which boils down to a flat struct of settings.
Except that if you don't know if something's supported, but you'd like 
to have it if it's available, the optional part gives you that.

>           o OfferToReceiveVideo, OfferToReceiveAudio and
>             VoiceActivityDetection are effectively features you turn
>             ON in most cases, not limiters or reducers.
>               + This manifests itself as a problem in the optional
>                 case where it's not clear how to handle failures of
>                 something that is "optional", does it fire the
>                 error-callback or does it proceed without error? This
>                 doesn't come up in gUM.

VoiceActivityDetection is a good example of something that might or 
might not be present, and most applications can probably live without 
it. If it's not implemented, the call should continue without error.

>              +
>       * The last thing I said about a request being "optional" doesn't
>         even make sense, which is the next problem: In place of the
>         reduction algorithm, which doesn't fit here, we/I succumb to
>         attempts at intuiting downstream uses for the mandatory vs.
>         optional distinction, which in itself is troubling. The big
>         one is:
>           o "Otional" means "Do this if you can"
>       * But say the system runs out of ways to receive video because
>         we are receiving 50 videos already, does this setting being
>         specified as "optional" mean we fire the error callback or
>         push through silently? - Regardless of your answer, you must
>         admit you are far removed from the gUM constraints algorithm.

I don't really see the difference.

>      *
>  1. MediaStreamConstraints seems mis-named. It appears to house
>     PeerConnection-specific settings, like OfferToReceiveVideo etc.
>     not settings for MediaStreams.
> Here's what I propose we do instead for PeerConnection:
>   * Declare createOffer/Answer/addStream to take a 'Settings'
>     /dictionary/.
>       o This dictionary has /mandatory/ and /optional/ members like
>         today, except that optional is another dictionary not an array.

Doesn't allow for sequencing, which is what we use for priority. Been 
discussed many times before, no consensus to change detected.
In many cases, I think constraints at this level will be "yes or no" 
things - but still, I think there's value in having a consistent interface.

>   * Remove any mention of these being constraints (which they are
>     not), and
>       o spell out a simple "unknown mandatory settings fail (and
>         mandatory trumps optional)" algorithm.
> This would pretty much work with what we have already. Thoughts?

Sorry, been there, discussed that, ended up where we are.

> .: Jan-Ivar :.

Received on Wednesday, 16 October 2013 15:02:33 UTC