Re: [webrtc-pc] Need to specify which members of the encodings in "sendEncodings" are actually used

Yes, it was our intention originally to allow the sender to specify some
things along with the RIDs, such as the resolution scale, and perhaps the
priority or max bitrate.

But you have a good point that we would need to make clear what things are
allowed there and what things are not (codecs, for example, are, I think,
clearly not), and what interaction there would be between
setRemoteDescription and the parameters passed in there.

The tradeoff is between complexity of the spec and convenience of the
application.  Allowing the app to set a lot of those things is easier, but
then there's more to worry about with the interaction between
setRemoteDescription and the encodings set here.  Allowing the app nothing
but rids is easy to specify, but it requires more work from the app
(addTransceiver; setRemoteDescription; getParameters; setParameters).

I'm hoping there is a simple rule that allow us to get most of the benefit
for the app for little of the cost in complexity in the spec.  But
whichever we choose, I agree we need to give is some thought and it is
worthy of agenda time as an interim topic.

On Tue, Mar 28, 2017 at 7:53 PM Taylor Brandstetter <> wrote:

> I ran into something again. The simulcast example is currently:
> pc.addTransceiver(track, {
>   direction: "sendrecv"
>   encodings: [
>     {
>       rid: "f"
>     },
>     {
>       rid: "h",
>       scaleDownResolutionBy: 2.0
>     },
>     {
>       rid: "q",
>       scaleDownResolutionBy: 4.0
>     }
>   ]
> });
> So clearly, at some point the intention was that you could specify some of
> the encoding parameters at addTransceiver time. Maybe the [[send
> encodings]] slot was going to be used to specify this logic.
> Do we still want to do this? If not, the example would need to change to
> do a getParameters/setParameters after setRemoteDescription. Maybe this
> would be a good interim topic.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <>, or mute
> the thread
> <>
> .

GitHub Notification of comment by pthatcherg
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 29 March 2017 17:20:21 UTC