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

On Wed, Feb 19, 2014 at 4:54 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> 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.
>
>
​I think the optimal is to make the "1111" variant work well.​  And I don't
see a strong reason why we can't.  I don't think you'll ever end up with
two identical streams if you use the "scale" field on the different layers.



> > - 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).
>

​Perhaps I should have said "3 preference knobs vs. (1 preference knobs​ +
3 limit knobs)".



>
> > - 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 ...
>

​For the use case of "turn things off rather than going below the min", yes
the JS could always just do that by watching the feedback.  But for the
case of "change how low the bias will go", I think the "minQuality" is very
valuable.  For example, in the sign language use case, you want to say
"bias toward framerate, but only down to a certain quality".  I don't see
that kind of need for framerate.​
​​