Re: A Big Proposal: A way to control quality/resolution/framreate/simulcast/layering with RtpSender

On 19 February 2014 16:37, Peter Thatcher <pthatcher@google.com> wrote:
> By this point, we have many separate discussions we could have:
> - Simulcast (1 RtpSender vs N RtpSenders)  (The original proposal is for 1)

I think that there's a lack of clarity here.  You can conceive of 1
track, N senders, -> N receivers, 1 track.  Or N tracks, N senders ->
N receivers, N tracks.  Or 1 track, 1 sender -> 1 receiver, 1 track.
Or even asymmetric combinations.

The 1111 option is still tempting, primarily because I think that
having some degree of parity with layered encodings is desirable and I
can't see how the others are likely to fit for layers.  That being the
case, I don't think that either option is going to be ideal for that,
since you really need smaller variants to have a hard limits, not just
preferences or biases; otherwise you might find that your simulcast is
two identical streams.  That suggests both preference and maximums.

> - Preference/Bias (3 dimensional vs. 1 dimensional)  (The original proposal
> is for 1)

The original proposal is for a choice on bias between two dimensions,
plus a number of controls that affect all three dimensions.  I think
that to say it's just 1 would bias the outcome (pun intended).

> - Minimums: for all three dimensions, none, or some?  (The original proposal
> is for 1, quality).

I'm going to say 0.  For now.

In general, I still don't see why one dimension should be treated
specially over any others at the API layer.  That doesn't mean that
browsers can choose not to support various sorts of tweaks that they
don't see a use case for ...

Received on Thursday, 20 February 2014 00:55:23 UTC