- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 19 Feb 2014 16:54:56 -0800
- To: Peter Thatcher <pthatcher@google.com>
- Cc: Chris Wendt <chris-w3c@chriswendt.net>, "public-orca@w3.org" <public-orca@w3.org>
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