Re: Proposed Change to RTCRtpSender "doohickey" proposal

To be honest, I read this email a few times, and it looks like you
know what you want.  I'm not sure that I know what you want.

I think that we need to back up a little.  Maybe a lot.

1. Is this proposal going to aid layering, simulcast, both, or
neither?  I think that the answer is both, but I'd like to confirm
that first.

2. What is an encoding in this context?  I don't see this in the
avtext taxonomy draft, so I'm left guessing.

3. What is the model that we are operating under here?  You know that
I like imperative API design, but RTCPeerConnection is an API founded
on negotiation.  What I think that you are doing is - at least at some
levels - biasing the design toward imperative.  That is, an
application dictates to the browser what encodings exist.

We haven't discussed this yet in any great depth and somehow continue
to avoid doing so repeatedly, so I really want to get to these high
level questions first.

As far as it goes, I can see some very clear alternatives to what you
are suggesting that might get what you want (if I'm inferring this all
correctly, that is).  For instance, you could say to the browser:
layeringTypesAllowed: ["temporal", "spatial", "quality"] (or some
subset thereof) and gain some advantage.  You could say to the browser
maxLayerDepth: 2 and gain some advantage.  You could say
maxAdditionalLayers: 3 and gain some advantage.  You could use the
layering profiles that the UCI forum defined and identify which of
those you support.  All of which are more closely analogous to the
sorts of control surfaces we currently have.

For the RTCRtpReceiver, an imperative API probably doesn't suit in a
situation where the source material is potentially not known.  Maybe
it differs for an answerer that has an offer on hand, but that seems
like a recipe for more complexity than we can manage.

As far as it goes, I am somewhat biased toward something that is much
closer to what I think you are suggesting, but without answering the
questions above, I think that a more concrete proposal is premature.

--Martin

On 30 April 2014 13:53, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
> So this is probably the most important email I am sending on this thread … A small change that would make me like this doohickey proposal much more …
>
> First would be a way to add a new encoding to a Sender or tell the sender to create another encoding or something like that.
>
> On Apr 28, 2014, at 9:58 AM, Justin Uberti <juberti@google.com> wrote:
>
>> // used with RTCRtpSender
>> interface RTCRtpEncodingParams {
>>     double               priority = 1.0;  // relative priority of this encoding
>>     unsigned int       maxBitrate = null;  // maximum bits to use for this encoding
>>     boolean             active;  // sending or "paused/onhold"
>> };
>
> The second would be a way to update constraints at the encoding level, this would allow us to set things like resolutions, aspect ratios, and frame rates at the encoding level.  That is one one of the use cases driving doohickeys.
>
> The third would be a have RTCRtpReceiver also have a set of RTCRtpEncodingParams.
>
> I think we will need something like this to make this proposal work because what is sent over the wire is not solely selected by the sender but is a negotiation between the sender and receiver.
>
> I’m fine with priority, maxBitrate, and active remains roughly as they are in this proposal because those are unilaterally set per sender and are not bilaterally impacted by the remote side or by other senders on the same side.
>
>
>
>
>
>
>

Received on Wednesday, 30 April 2014 21:18:55 UTC